This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

root partition is filling after update to 7.3

Hey everybody,

after i updated to version 7.3 my root partition is filling up till 100%. And then my astaro does not work very well, with a root partition that is full.

does somebody have a solution for this issue?


thanks
redmalte


This thread was automatically locked due to age.
Parents
  • Hi,

    Hey everybody,

    after i updated to version 7.3 my root partition is filling up till 100%. And then my astaro does not work very well, with a root partition that is full.

    does somebody have a solution for this issue?

    thanks
    redmalte


    Could you login as root to your ASG and run the following command:

    find -xdev /|sort -nr >sizes

    This will print the sizes of all files/directories to the sizes file. Please copy that file of the ASG, and send it to sschnelle@astaro.com.

    You can also send a login, so i could take a look.

    Thanks!

    Sven.
  • Hi Sven,

    when i run the command i get an error "paths must precede expression". I´m not an linux expert, sorry for that.

    Thanks,
    Malte
  • hi,

    i know, it´s off-topic, but i feel with Andreas. Beeing not payed for good forum work is very hardly to understand, even there are often the solutions for the problems.

    I´m a end-user with gold-Support, but this level does´nt allow me to contact astaro directly, since i´ve bought my solution through a partner. 
    But sometimes, this is time delay is too big, for a really fast solution.
    And i don´t want to pay for platinum, even i have to do this in double for a cluster solution.

    But anyway. Andreas is right. For qualified questions, you´ll get qualified answers. And netiquette should be the base for it.

    Cu
    Thomas
  • Andreas is there anything I can do to help troubleshoot the issue? System is as follows:

    Firmware version: 7.304
    Pattern version: 8589

    # CPU: VIA C7 nano BGA2 1GHz
    # Front Side Bus: 400/533MHz
    # MB Chipset: VIA CN700 + VIA VT8237R Plus
    # Graphics: Integrated with VIA CN700, Shared memory up to 64MB, Resolution up to 1600x1200
    # Memory: 1 x DDR2 SDRAM 533/400 up to 1GB
    # IDE: Ultra-DMA-133/100/66 transfer protocols, 1 x 40pin Connector, 1 x 44pin connector, 1 x Compact Flash Slot
    # LAN: 3 x Realtek 10/100 

    HDD is a Seagate Momentus 5400.3 80GB SATA 8MB Cache - ST980811AS

    Memory is Kingston 1GB 533MHz DDR2
    PartNo: KVR533D2N4/1G

    Just had to delete the PostgreSQL core dumps from the same place.
  • I´m a end-user with gold-Support, but this level does´nt allow me to contact astaro directly, since i´ve bought my solution through a partner.

    Thomas, in the USA, everyone buys through resellers.  End-users with Gold support can submit problems directly to Astaro Support.  In Germany, can you not access MyAstaro to submit a trouble ticket?
    https://www.astaro.de/user/login

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Biffa, If you got to 7.304 by loading from a 7.302 ISO, I suggest you download the new 7.304 ISO and load from that.  The 7.302 seems to have caused problems for some people.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hey Bob [[:)]]

    No I don't think I did, I think I used an earlier iso but I can check I think [[:)]]
  • Andreas is there anything I can do to help troubleshoot the issue? 
    Just had to delete the PostgreSQL core dumps from the same place.


    Please check at least the system.log and logging.log logfiles for postgres errors. It is unlikely that it dies without leaving anything except for the core dump.

    Cheers,
     andreas
  • Hi Andreas, did you see the ones I posted on page 4? System log full of postgre errors.
  • Ok wierd, no cores for ages but then on the 1st Nov they started occuring again.

    I now have 253 core.postgres.* files in /var/storage/cores totalling just over 11GB

    asl:/var/storage/cores # ls -1R | wc -l
    253
    mail:/var/storage/cores # du -h
    11G

    Nothing in logging.log but system log is full of this specific group of error lines every few seconds

    2008:11:04-10:47:55 (none) postgres[10955]: [1019-1] ERROR:  could not open relation 24981/16519/16525: No such file or directory
    2008:11:04-10:47:55 (none) postgres[10955]: [1019-2] STATEMENT:  INSERT INTO public.accounting
    2008:11:04-10:47:55 (none) postgres[10955]: [1019-3]  (ip_saddr,ip_daddr,ip_protocol,l4_dport,raw_in_pktlen,raw_in_pktcount,raw_out_pktlen,raw_out_pktcount,flow_start_day,flow_start
    2008:11:04-10:47:55 (none) postgres[10955]: [1019-4] _sec,flow_duration) VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11);
    2008:11:04-10:47:55 (none) ulogd[2646]: pg1: ERROR:  could not open relation 24981/16519/16525: No such file or directory 
    2008:11:04-10:47:55 (none) ulogd[2646]: pg1: commit failed
    2008:11:04-10:48:00 (none) ulogd[2646]: input key `flow.start.sec' already has source
    2008:11:04-10:48:00 (none) ulogd[2646]: stack_fsm_timer_cb: error

    Then today at 00:13 I got my first Postgres PANIC

    2008:11:04-00:13:53 (none) postgres[4673]: [879-1] PANIC:  right sibling's left-link doesn't match: block 73 links to 74 instead of expected 1 in index "result_l"
    2008:11:04-00:13:53 (none) postgres[4673]: [879-2] STATEMENT:  INSERT INTO l VALUES (0, 'efd0da3a5522fa34', 'eanna@gmn.com', 'kefxjhtkydiz@xjhtky.com', 'rejected', 1225757633,
    2008:11:04-00:13:53 (none) postgres[4673]: [879-3]  'rbl', 'sbl-xbl.spamhaus.org', '', 1225757633, '', 0, '67.8.140.32', 0) 
    2008:11:04-00:13:54 (none) postgres[3052]: [879-1] LOG:  server process (PID 4673) was terminated by signal 6: Aborted
    2008:11:04-00:13:54 (none) postgres[3052]: [880-1] LOG:  terminating any other active server processes
    2008:11:04-00:13:54 (none) postgres[4281]: [879-1] WARNING:  terminating connection because of crash of another server process
    2008:11:04-00:13:54 (none) postgres[3106]: [879-1] WARNING:  terminating connection because of crash of another server process
    2008:11:04-00:13:54 (none) postgres[4281]: [879-2] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server
    2008:11:04-00:13:54 (none) postgres[4281]: [879-3]  process exited abnormally and possibly corrupted shared memory.
    2008:11:04-00:13:54 (none) postgres[4281]: [879-4] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
    2008:11:04-00:13:54 (none) postgres[3106]: [879-2] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server
    2008:11:04-00:13:54 (none) postgres[3106]: [879-3]  process exited abnormally and possibly corrupted shared memory.
    2008:11:04-00:13:54 (none) postgres[3106]: [879-4] HINT:  In a moment you should be able to reconnect to the database and repeat your command.

    Then lots more PANICs every few minutes all day [:(]

    Do you want me to zip up the system.log and send it to you?
  • Hi,
    no need for more logs, this is sufficient. There are currently issues regarding database corruption. Usually, if a table is corrupted, it just stops to work correctly, and some reports are blank. If the  database is corrupted BADLY, it even panics and drops cores.  There is a way to re-initialize the database, so things will start to work again (and it will stop dropping cores), but this means losing reporting data which is stored in the databases:
    Please see the following thread for further information:
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/t/32246

    In your case, it looks like the corruption in the reporting tables did also influence the email backend, but there's probably only the index missing. You can easily re-create the indexes:
     # psql -Upostgres -c"reindex database smtp;" smtp
     # psql -Upostgres -c"reindex database pop3;" pop3
     # psql -Ureporting -c"reindex database reporting;" reporting
     # psql -Upostgres -c"vacuum;" smtp
     # psql -Upostgres -c"vacuum;" pop3
     # psql -Ureporting -c"vacuum;" reporting

    Cheers,
     andreas
  • Heh I would except the damn database is in recovery mode [:P]

    Thanks for all the support Andreas. [:D]

    [edit]
    Deleted more cores, rebooted and ran commands, as advised. Status log looks clean so far will keep an eye on it.
    [/edit]
Reply
  • Heh I would except the damn database is in recovery mode [:P]

    Thanks for all the support Andreas. [:D]

    [edit]
    Deleted more cores, rebooted and ran commands, as advised. Status log looks clean so far will keep an eye on it.
    [/edit]
Children
No Data