Ieri sono intervenuto su un server che aveva un load average parecchio alto e passava il 90% del tempo in modalità kernel. Usando il comando top ho visto che i processi in cima alla classifica erano dei server oracle ed exim. I processi oracle possono stare lì per parecchio tempo perché vi possono essere delle query particolarmente impegnative, ma il comando exim mi ha un po’ insospettito.

Ho quindi verificato che un certo job veniva lanciato dal cron ogni minuto e inviava un email con degli errori di sintassi. Exim avrebbe dovuto occuparsi della consegna dell’email, ma a causa di un errore nella configurazione del DNS, non vi riusciva e si riproponeva di riprovare più tardi, lasciando quindi quell’email in coda.

Tutti i messaggi della coda di Exim stanno nella directory /var/spool/exim/input. In questa directory c’erano circa 177000 file. I file di per sè sono tanti, ma rimangono gestibili. Visto che tutti quanti erano eguali e riportavano gli stessi errori, ho pensato di rimuoverli con piccolo ciclo shell che richiamasse il comando exim -Mrm NOMEFILE. Dopo circa mezz’ora erano stati cancellati solo 6000 file e il load average era raddoppiato. Allora ho fatto il tutto in maniera forse poco ortodossa, cancellando con il comando rm tutto il contenuto della directory.

Il load average è sceso, ma i nuovi messaggi generati dal cron (per il job in questione e per altri job) facevano comunque sì che il processo exim restasse in cima alla classifica. E soprattutto, la maggior parte del tempo CPU era sempre passata in modalità kernel anziché utente.

Ho allora verificato quanto fosse grande la directory /var/spool/exim/input:

# ls -ld /var/spool/exim/input
drwxr-x--- 2 Debian-exim Debian-exim 4643078144 dic 12 17:39 /var/spool/exim/input

che fa circa 4Gb per la sola directory. Ho quindi «clonato» la directory e tutto si è magicamente sistemato:

# mkdir /var/spool/exim/input2
# chown --reference /var/spool/exim/input{,2}
# chmod --reference /var/spool/exim/input{,2}
# mv /var/spool/exim/input{,.bak} && mv /var/spool/exim/input{2,}
# invoke-rc.d exim restart

Kernel 3.2.0 della Debian unstable. Oggi ci sono stati quattro kernel panic in serie. Forse sono legati al problema relativo all’ACPI per il quale è stato subito rilasciato un nuovo kernel stabile. Ma poiché ieri ci sono stati tre rilasci di kernel stabili nel giro di dodici ore forse è il caso di attendere qualche giorno prima di provare un aggiornamento

Di norma chi si occupa dell’IT di un’azienda si preoccupa anche di avere un backup funzionante. A volte si tratta di semplici copie su nastro, altre di varie copie in parallelo su vari sistemi. Altre ancora di macchine intere che vengono replicate tramite snapshot del sistema di virtualizzazione.

In ogni caso, una volta che il tutto viene configurato e controllato per qualche giorno, la cosa passa per funzionante e nessuno la guarda più. Finché ovviamente non capita il disastro.

Questa volta, dopo che sono stato chiamato proprio a causa di un disastro, e dopo aver ripristinato il sistema (Solaris 10 su SunFire 880 con BaanIV e Oracle 10), mi è stato chiesto di controllare la procedura di backup.

Tra le varie operazioni svolte, c’è quella di copiare interamente le directory con i datafile di oracle tramite il comando tar. Il tutto avveniva tramite un job lanciato di notte dal cron di sistema, che mandava poi l’esito all’utente root del quale ovviamente nessuno controllava la casella di posta sul server.

Orbene, il comando tar copiava tutti i file eccetto uno (fortunatamente contenente solo indici), e dava questo messaggio d’errore

tar: /disc2/oradata/BAAN/indx700.dbf too large to archive. Use E function modifier.

che è un messaggio del tar di Solaris dovuto al file indx700.dbf che supera gli 8Gb e non è quindi archiviabile. Il tar di Solaris ha una opzione apposita per cambiare formato e gestire file molto grossi, oppure si può utilizzare gtar (GNU tar) che è già presente in Solaris 10.

Ma la cosa più importante è che le operazioni vanno sempre monitorate costantemente. Quindi la casella email di root va letta tutti i giorni, oppure si può inviare l’output del job ad un altro indirizzo email, magari apposito. Ed è molto importante che questi messaggi siano inviati ogni giorno, e non solo in caso di problemi. Perché il fatto che ogni giorno arrivi l’email vuol dire che la procedura di backup è stata eseguita. Se invece l’email non venisse inviata non si avrebbe la certezza dell’avvenuta esecuzione (con successo o meno) del backup.

So, I didn’t know about the call_module option of pam_unix2.so pam module. I spent one day trying to figure out why a pam stack would call pam_winbind without haveing “pam_winbind” in any file in /etc/pam.d and finally discovered that pam_unix2 was calling it because it was configured this way in /etc/security/pam_unix2.conf.
I learnt about pam_unix2 and I wish to know why anyone would use call_module instead of configuring PAM for calling the right module before pam_unix2.
Is there any advantage in letting pam_unix2 managing its own module stack instead of configuring pam files?

Thanks,
Giuseppe