Newsgroup: it.comp.os.linux.sys
Titolo: Postfix e Insufficient system storage

 Mar 13 10:18:12 nomeserver postfix/smtpd[13548]: disconnect from unknown[IP privato]
Questo è di oggi, è stato ripetuto più volte circa fra le 10:00 e le 
10:20. Il mittente stava cercando di spedire un messaggio di circa 350 
kB a due destinatari; non si è accorto di niente, perché alla fine il 
messaggio è partito.
Su /var ho liberi 4,5 GB.
Nel 
main.cf
 il limite è 30MB (message_size_limit = 30000000).
Curiosamente, zgreppando nei vecchi log ho visto che questa cosa accade 
sempre intorno alle 10 del mattino, ma non in modo meccanico: qualche 
volta un po' prima, qualche volta un po' dopo...
[poco dopo]
Uhm, nei pochi casi che ho potuto verificare, questo problema si è 
verificato - e risolto da solo - subito prima del riavvio di syslogd, 
che avviene appunto ogni giorno in un momento variabile circa fra le 
10:00 e le 10:30, ad opera di anacrontab.
Qualcuno ha idea di quale possa essere la causa?
-- 
Ciao,
   Marco.

 Qualcuno ha idea di quale possa essere la causa?
Numero di inode a disposizione sul filesystem che giunge a saturazione, 
plausibilmente.
Suggerisco l'installazione di munin+munin-node per monitoraggio, chè 
'ste cose saltan all'occhio....

 'ste cose saltan all'occhio....
Ok grazie, non conoscevo e sto installando.
-- 
Ciao,
   Marco.

 pochissimo.
Eh ok, ma dipende anche da quanto vicino al limite sei adesso...
Prova a vedere cosa dicono i grafici di munin la prima volta che ricàpita.

 Eh ok, ma dipende anche da quanto vicino al limite sei adesso...
Ah, ovviamente: un "df -i" che riporta?

 Ah, ovviamente: un "df -i" che riporta?
#>df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/md1              611648   18389  593259    4% /
tmpfs                 224349      10  224339    1% /lib/init/rw
udev                  224349     743  223606    1% /dev
tmpfs                 224349       1  224348    1% /dev/shm
/dev/md0               48192      37   48155    1% /boot
/dev/md6             12222464  126107 12096357    2% /home
/dev/md4              611648      30  611618    1% /tmp
/dev/md2             1221600  113993 1107607   10% /usr
/dev/md3             1221600   22599 1199001    2% /var
Non mi sembra di essere molto vicino al limite... :)
-- 
Ciao,
   Marco.

 tutti gli altri?
Non ho deciso io quell'orario, e infatti prima mi stavo chiedendo perché 
syslogd si riavviasse a quell'ora, dato che l'unica causa del suo 
riavvio mi sembra possa essere cron.daily che è schedulato alle 6:25 
come da default Debian. Poi mi sono reso conto che cron.daily viene 
gestito da anacron, che non usa impostazioni di orario "esatto", e 
quindi lo lancia in un momento tipo "entro 5 minuti se l'ultima 
esecuzione è stata almeno un giorno fa", ma anche in questo caso sono 
impostazioni predefinite di Etch, io non le ho toccate.
-- 
Ciao,
   Marco.

 
qualcosa ti satura /var finchè non si riavvia syslogd?

 qualcosa ti satura /var finchè non si riavvia syslogd?
Uhm, e cosa potrebbe riempire oltre 4 GB e poi sparire nel nulla?
Io ho uno script che mi avvisa se qualche disco si riempie oltre l'80%, 
ma è programmato solo per il primo pomeriggio.
Tuttavia, credo che se /var fosse piena dovrei trovare un bel po' di 
errori di ogni genere nei log, no?
-- 
Ciao,
   Marco.

 Non mi sembra di essere molto vicino al limite... :)
Già... :-\

 server...
sei *sicuro* che il controller RAID funzioni a dovere?
in certi casi, un controller /parzialmente/ rotto può dare errori del genere
(in generale, controlla *bene* l'hw prima di impazzire)

 (in generale, controlla *bene* l'hw prima di impazzire)
Stavo per scrivere "buono a sapersi" ma non so se sia l'espressione 
giusta in questo caso ;). Controllerò, ma spero proprio di no... 
Comunque il RAID è software, e mdstat non riporta errori. L'unica cosa 
da fare credo sia vedere se il controller ha una auto-diagnostica di 
qualche genere.
-- 
Ciao,
   Marco.


Uh... e invece in base ai grafici di munin sembra proprio che ci sia 
qualcosa che tutti i giorni alle 7:30 circa inizia a riempire /var fino 
alle 10:30 circa, quando questo qualcosa ripulisce /var e syslogd si 
riavvia. Eppure nei log non vedo niente di particolare in quel periodo 
di tempo. Vedo solo che intorno alle 7:30 parte anacron, ma poi nessun 
messaggio di errore o avvisi o altro.
Domattina controllerò.
-- 
Ciao,
   Marco.

 perche' Anacron e non il semplice-ma-sempre-buono cron?
Veramente i miei script periodici li avvio dal classico /etc/crontab, 
non ricordo di aver consapevolmente fatto uso di anacron. Potrebbe 
essere stato installato come dipendenza di qualcos'altro? O possibile 
che la sua installazione venga effettuata di default in Debian Etch? Da 
approfondire anche qui.
-- 
Ciao,
   Marco.

 che la sua installazione venga effettuata di default in Debian Etch?
Questo te lo posso escludere categoricamente, Anacron viene installato
solo se richiesto
Enrico

 solo se richiesto
Strano però, visto che io non ho mai avuto interesse nell'installarlo, 
anche perché la macchina è accesa 24/7 e quindi non mi serve.
Comunque ora l'ho disinstallato senza alcun problema. Ma penso che il 
problema sia dovuto non ad anacron in sé, ma a un job che sarà comunque 
eseguito da cron.
Infatti, nel frattempo ho visto che la dir che viene riempita è 
/var/tmp. Si riempie di file il cui nome inizia con "sort", tipo 
"sortkSmlzi", di circa 23 MB ciascuno. Sono file binari che contengono 
una sorta di elenco dei file presenti sul filesystem, e credo siano 
generati da updatedb, che viene lanciato da /etc/cron.daily/find.
Qualcuno sa come mai può dare problemi come il mio?
Al momento non vedo altro modo per bloccarlo se non disabilitare 
l'esecuzione di questo job...
-- 
Ciao,
   Marco.

 generati da updatedb, che viene lanciato da /etc/cron.daily/find.
Credo di aver risolto il problema escludendo, in updatedb.conf, le due 
directory in cui sono contenuti tutti i dati. Forse updatedb impazziva 
per il grande numero di file, o per gli hard link presenti in alcune 
sottodir, non so.
-- 
Ciao,
   Marco.