Troubleshooting di processi

L'opera di debugging di un processo non è generalmente argomento proponibile ad un sistemista non esperto, anche perchè spesso riguardano problemi sul lato applicativo che vanno affrontati direttamente dallo sviluppatore.

In ogni caso, nella vita di ogni sysadm capita sistematicamente che dei servizi non partano o dei programmi non facciano quello che dovrebbero fare (non inchiodarsi, innanzitutto), oppure, più subdolamente, abbiano comportamenti erratici o problemi di prestazioni o di sopportazione di alti carichi.
Senza volersi addentrare in problematiche di debugging avanzato, si possono elencare alcuni strumenti a disposizione del sistemista per diagnosticare simili problemi:

Log
I log sono sempre la prima cosa da guardare perchè di solito contengono abbastanza informazioni da farci capire dove intervenire. Eventualmente analizzare syslog.conf o le istruzioni e le configurazioni del singolo programma per capire dove vengono loggati i suoi messaggi e poi leggere i messaggi di errore sui log che ci interessano.

Debug
Quasi sempre è possibile lanciare un programma con diversi livelli di debug: aumentando la verbosità del debug (di solito registrato sul file di log) si aumenta la possibilità di capire cosa non funziona. Tipicamente il livello di debug può essere impostato come opzione da command line o nel file di configurazione.

Comandi di diagnostica
Unix mette a disposizione vari comandi utili per capire cosa fa un processo e come si comporta il sistema. SU Linux si possono comunemente trovare i seguenti tool:
strace Traccia le chiamate di sistema e i segnali del programma specificato mentre lo esegue. Ovviamente va utilizzato solo per fini diagnostici, rallentando particolarmente la velocità di esecuzione. Spesso non è nemmeno necessario capire l'output di strace (invero piuttosto verboso e per molti incomprensibile), basta cercare righe dove si parla di errori e vengono indicati path o funzioni specifiche. Spesso un programma non funziona perchè non trova certi file (librerie ecc) o non ha i permessi adeguati sugli stessi, un grep ENOENT sullo stdout di strace può evidenziare tutte le volte in cui si è cercato un file senza trovarlo (spesso questo non è un problema, in quanto un processo può trovare un file dopo averlo cercato senza successo in varie directory (con relativo messaggio di errore "ENOENT (No such file or directory)".
ldd Stampa l'elenco delle librerie condivise utilizzate dal comando specificato
lsof Elenca gli open file del sistema. Un open file può essere: un normale file, una directory, un file speciale a blocchi o caratteri, una librerira, una socket Internet, una socket Unix domain... E' utile per vedere le risorse utilizzate da un programma (e, per esempio, capire dove sta loggando).

Privacy Policy