root partition is filling after update to 7.3

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

I use Astaro secure gateway 320
Why don't I see any reply of Astaro's staff in this forum?
Is it "gold" support?

Actually, it's the other way around. If you have maintenance, you have the option to use  the official support mechanisms. This forum (which is called the 'Astaro User Bulletin Board') was primarily intended to offer user-to-user help. We (as in 'the Astaro employees') were always using it as a way to directly get in contact with a much broader user base and to receive problem reports and feedback faster and more directly. Over the years, this grew into a community with many members with vast experience and knowledge about our products. Yet, as far as I know, Astaro does not pay anyone to answer anything here (not me, anyway [:P]), so if we decide to read/answer here, we do so in our spare time, often during breaks or outside business hours.

Generally, if you want to receive good answers, you have to ask good questions. This is even more true when people do their work voluntarily. This comprises showing good manners (like saying hi and bye, using common flowers of speech) as well as the obvious technical prerequisites ('I am using ASG/AMG/AWG Appliance/Software Version X.YZZ', 'I am having the following problem ...', 'I tried ....'). You probably know it, but the good old How to ask questions the smart way by Eric S. Raymond is still the definitive guidebook on that matter.

Cheers,
 andreas

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

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

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

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]