A cura dell'equipe del servizio di Pronto Intervento Unix
Redattore Dott. Bartolomeo Bogliolo
In questo manuale vengono riportati gli interventi da adottare in situazioni di emergenza. L'obiettivo e' quello di fornire, a chi possa trovarsi in una situazione d'emergenza, indicazioni sufficienti per risolvere la situazione.
Nel primo capitolo (Patologie) vengono riportati i principali problemi che possono occorrere e richiedere interventi di pronto soccorso, i loro sintomi e le relative terapie.
Nel secondo capitolo (Interventi di pronto soccorso) vengono descritti i protocolli terapeutici da seguire per risolvere i problemi descritti nel primo capitolo.
Sono spesso importanti gli aspetti legali
e di diritto spesso legati alle urgenze. Il paragrafo (Cenni
di medicina legale) riporta alcune valide indicazioni sull'argomento.
Trattandosi di un manuale di pronto soccorso le indicazioni riportate non sono
sempre esaustive. La trattazione completa di ogni singola patologia puo' essere
trovata nella documentazione consigliata nella Bibliografia
ragionata cui si rimanda per ulteriori approfondimenti.
Questa seconda edizione, notevolmente rinnovata nei contenuti, e' stata pubblicata dopo il grande successo della precedente versione. E' stata in particolare curata la diagnostica fornendo riferimenti precisi ai diversi protocolli di cura ed alle piu' recenti scoperte farmacologiche.
Il presente manuale non ha ricevuto alcun contributo da parte delle aziende farmaceutiche.
NdA Il contenuto della presente pagina e' molto serio. A differenza dell'autore...
Unix e' un sistema operativo. Unix consente quindi l'utilizzo dell'hardware (tastiera, video, dischi, ..) creando un ambiente virtuale in cui gli utenti ed i programmi agiscono.
Un sistema operativo e' alla base di ogni programma di sistema, di ambiente o applicativo; i malfunzionamenti del sistema operativo sono quindi potenzialmente molto gravi. In realta' i casi di effettivo malfunzionamento del sistema operativo sono molto rari. Molta maggior frequenza hanno invece problemi generati da utenti, programmi (ed amministratori di sistema!) che hanno un impatto sull'andamento generale della macchina Unix.
Per poter operare correttamente i programmi su Unix necessitano di spazio libero sul sistema. Sono di particolare importanza i file system root, usr e tmp.
Sintomi:
comportamenti strani sul sistema ( vanno in errore i programmi, non funzionano le compilazioni, gli spostamenti di file, il sistema e' rallentato, ..)
segnalazione su console di sistema
Esami:
utilizzare il comando df -k (o bdf su hp-ux) per identificare il file system che presenta il problema
utilizzare du -xsk * | sort -n per individuare velocemente le directory/file su cui agire
Prognosi:
Eliminare i file responsabili della completa occupazione del file system (i file sono sempre creati da processi che sono l'elaborazione di programmi lanciati da utenti ... e' importante determinare quali sono le ragioni dell'improvvisa mancanza di spazio su un sistema)
Note:
Alcuni dottori preferiscono ricercare i file piu' grandi di una certa dimensione con find /dir -xdev -size +900M -exec ls -l {} \; ma la ricerca con du e' da preferire nella diagnostica, secondo l'autore, poiche' presenta meno veri negativi.
Gli utenti debbono essere responsabilizzati per un corretto utilizzo delle risorse del disco.
Un disco, di qualsiasi dimensione sia, si riempira' sempre. Il monitoraggio della situazione dei dischi deve essere pertanto continuo. Tuttavia la repentina perdita di spazio ha sempre una motivazione che deve essere ricercata e corretta.
Attenzione a non farsi ingannare da file o directory che iniziano con . (eg. .tmp). Questi non vengono elencati quando la shell tratta il carattere *. Solo alcuni utenti malati utilizzano file o directory nascoste in questo modo (ma io sono tra quelli).
In alcune occasioni ci si trova con un file system con problemi di spazio e, nonostante le ricerche e l'eventuale liberazione temporanea di spazio, non si riesce a trovare il file coinvolto. Gli esami clinici ottenuti con i comandi df -k e du sembrano in contraddizione: il primo riporta un file system pieno, il secondo conteggiando lo spazio utilizzato nelle diverse directory del file system da' un occupazione inferiore. In questo caso ci si tratta della patologia di file fantasma. L'eziologia e' semplice: quando si cancella un file ma questo e' ancora utilizzato da un processo attivo il file non e' piu' rintracciabile su nessuna directory (quindi il du non lo "trova") ma lo spazio non viene liberato anzi, se il processo continua le attivita' di scrittura, ulteriore spazio viene occupato. Determinato il processo responsabile la prognosi e' certa: ucciso il processo si libera lo spazio.
Uno strumento diagnostico molto utile, ma i cui referti non sono sempre facili da intepretare e' il freeware lsof. Nel caso specifico l'utilizzo di lsof -a +L 1 consente di individuare i file aperti il cui numero di link e' inferiore a zero.
Sintomi:
gli stessi della patologia Mancanza di spazio sul file system
Esami:
utilizzare il comando df -k (o bdf su hp-ux) per identificare il file system che presenta il problema
utilizzare ps -efa > pippo; sleep 10; ps -efa > pluto; diff pippo pluto per determinare i processi maggiormente attivi: ci vuole anche fantasia e fortuna (o esperienza)
Prognosi:
Uccidere il processo responsabile
in casi estremi puo' essere effettuato un reboot. Si tratta pero' di una sconfitta della scienza medica: non siete stati abbastanza bravi a trovare la vera causa della malattia!
Note:
ovviamente il problema non si puo' presentare con NFS come ben sanno gli specialisti di networkfilesystemiologia.
Unix ha una gestione della sicurezza
semplice ed al tempo stesso molto potente. Vi sono situazioni in cui possono
essere restituiti errori a programmi di sistema o applicativi dovuti ad una
errata configurazione dei permessi su file o directory.
La prognosi e' molto semplice e si riduce ad un semplice comando. Molto piu'
difficile e' la diagnosi per identificare la causa del problema.
Sintomi:
processi o applicazioni segnalano un errore, non svolgono una funzione, terminano l'esecuzione
Diagnosi:
usare il comando ls -l per identificare la causa del problema
se il sistema lo supporta puo' essere molto utile nella diagnosi il truss che tuttavia richiede competenze specialistiche per interpretarne i dati diagnostici
Prognosi:
correggere il problema con il comando chmod
In alcuni casi programmi applicativi o demoni di sistema possono pesare eccessivamente sulla CPU o entrare completamente in loop. In questo caso le prestazioni del sistema decadono pesantemente ed e' necessaria un'attivita' manuale per il ripristino del normale funzionamento della macchina.
Sintomi:
rallentamento del sistema
Esami:
controllare l'effettivo carico del sistema con w (load average superiore a 3) o sar
effettuare alcune volte ps -efa > pippo; sleep 10; ps -efa > pluto; diff pippo pluto per determinare i processi attivi
Prognosi:
contattare gli utenti che hanno attivato il programma e/o verificarne l'effettiva necessita'
Uccidere i processi responsabili (la tentazione sarebbe quella di uccidere i programmatori responsabili, tuttavia tale intervento non risolve la situazione nel breve periodo)
Note:
Le compilazioni di programmi complessi pesano molto sulla CPU analogamente avviene per programmi non interattivi (batch). Tali attivazioni dovrebbero essere poste in sequenza e non in parallelo, eseguite in orari non di carico, attivate con nice.
Spesso programmi in sviluppo o non ben testati entrano in loop.
In alcuni casi i processi che causano il rallentamento sono processi di accesso alle basi dati. In tal caso si tratta probabilmente di selezioni non ben costruite.
Quando un processo muore ed il padre non se ne interessa, per disperazione diventa uno zombie. Gli zombie vagano per il sistema, in genere senza danno, anche al cinico padre non succede nulla. Tuttavia il numero delle anime su Unix e' limitato (maxproc), siano queste vive o zombie. Pertanto e' possibile che un numero elevato di zombie non consenta piu' la nascita di nuovi processi.
Sintomi:
impossibilita' nel lanciare un qualsiasi comando
impossibilita' nel connettersi al sistema
rallentamento del sistema
Esami:
effettuare un ps -efa | grep defunct
Prognosi:
utilizzare un eventuale comando di restart del processo padre
in mancanza di un comando di restart o in caso di mancato effetto dello stesso, uccidere il padre degenere
Note:
oltre che per cinismo il processo padre puo' dimenticarsi di aspettare i figli anche per valide ragioni. E' quindi opportuna qualche indagine per escludere la presenza di altre patologie.
il caso di morte del processo padre non e' una patologia: gli orfani vengono adottati da init (il processo numero 1). Nel caso molto grave di zombie orfani oltre all'uccisione di init (da effettuare con estrema cautela, taluni autori la escludono e preferiscono il reboot) puo' essere utilizzato il comando di restart init -q.
E' possibile che alcuni programmi allochino una quantita' di memoria elevata (centinaia di Mbyte) occupando cosi' una risorsa utile ad altri processi.
Sintomi:
segnalazione di mancanza di memoria o swap space
impossibilita' nel lanciare alcuni comandi (tra cui il ps)
rallentamento del sistema
Prognosi:
uccidere il processo responsabile
in casi estremi (ma purtroppo frequenti con questa patologia) e' necessario il reboot del sistema.
Note:
la patologia e' grave ed e' necessario agire in fretta. Anche comandi normali (eg. ps) possono fallire rendendo difficoltosa una corretta diagnosi. Il reboot puo' quindi diventare presto inevitabile.
Quando un processo accede ad un area non indirizzabile (tipicamente per un errore di programma) il sistema Unix cattura l'errore e termina il processo scaricando su un file l'immagine della memoria del processo stesso. In altri casi il processo puo' determinare da solo una situazione d'errore e quindi terminare la propria esecuzione. In entrambe i casi l'attivita' che il processo stava svolgendo viene interrotta e, probabilmente deve essere ripristinata.
Sintomi:
il servizio fornito dal processo non e' piu' disponibile
nella directory di esecuzione del programma appare un file di core
Prognosi:
controllare eventuali log del programma e quelli di sistema
far ripartire il programma
Note:
a differenza di altri "sistemi operativi" che hanno la tendenza a diventare blu i caso di errore di un programma, questa e' la situazione che occorre con maggior frequenza su un sistema Unix in caso di errore su un programma.
alcune delle ragioni di blocco di un programma sono analoghe a quelle gia' riportate e relative al sistema (utilizzo eccessivo di memoria, raggiungimento del limite massimo di processi per utente, ...) altre dipendono dalla logica del programma stesso
Nel caso in cui il sistema operativo rilevi una grave inconsistenza nelle sue strutture viene riportato un messaggio di PANIC sulla console ed il sistema viene bloccato.
Sintomi:
non funziona piu' nulla
Prognosi:
annotare tutte le indicazioni riportate dal sistema sulla console per consentire una adeguata diagnostica del problema
effettuare la ripartenza del sistema
Sistemi diversi possono essere collegati tra loro in rete. Il collegamento in rete consente l'utilizzo di una serie di servizi e la possibilita' di scambio dati tra tutti i componenti della rete.
I collegamenti possono essere di tipo locale o geografico. I collegamenti remoti dal punto di vista logico non presentano differenze tuttavia dal punto di vista fisico (e prestazionale) vi sono notevoli differenza tra collegamenti in rete locale ed in rete geografica.
In alcuni casi puo' verificarsi il blocco di un tratto di rete.
Sintomi:
Gli utenti sono arrabbiatissimi
impossibilita' del collegamento in remoto
Esami:
controllare i collegamenti con ping verso tutti gli elementi intermedi
controllare l'istradamento dei messaggi dai diversi sistemi (sia raggiungibili che no) con il comando traceroute
Prognosi:
contattare il fornitore del servizio di comunicazione: SIP o analoghi se si tratta di un collegamento geografico
ricercare il componente guasto (HUB, router, cavo, ...) e sostituirlo se si tratta di un collegamento locale
In alcuni casi vengono effettuate operazioni pesanti sulla rete che rallentano tutte le attivita' sul tratto di rete utilizzato.
Sintomi:
tutte le attivita' che richiedono la comunicazione tra sistemi sono rallentate
Esami:
controllare i tempi di risposta con ping dei diversi sistemi per determinare la tratta di rete che presenta un sovraccarico
Prognosi:
determinare il servizio o il collegamento che utilizza la rete in modo non controllato e terminarlo
Note:
e' spesso difficile distinguere questa patologia da quella dei Processi CPU intensive poiche' presentano gli stessi sintomi e spesso possono esservi delle relazioni
Il panico nell'utente e' una delle reazioni piu' comuni e diffuse. Si tratta in genere di una conseguenza di un altro problema ma non sono rari i casi in cui il panico si presenta senza alcuna ragione apparente.
La frequenza della situazione e l'elevata pericolosita' delle azioni che ne possono scaturire richiedono una trattazione adeguata.
Sintomi:
isteria
pianto
telefonate continue
Prognosi:
rassicurare il colpito
risolvere il problema che cagiona la situazione di panico
in casi estremi schiaffeggiare il paziente
sono ancora sperimentali alcune recenti terapie
L'utente rompiscatole e' una patologia molto diffusa e di difficile cura. In molti casi si tratta di una malattia il cui decorso e' cronico e quindi incurabile. Vi sono tuttavia situazioni in cui e' necessario un intervento di pronto soccorso anche su tale grave patologia. Dal punto di vista eziologico l'utente rompiscatole si divide in due differenti patologie:
Sintomi:
telefonate ed email continue
continue richieste di attivita' inutili
oppure continue richieste di informazioni complicatissime
Prognosi:
esuadire le richieste, rispondere alle telefonate ed alle email, ... puo' essere efficace per un limitato periodo anche se non risolve il problema: attenzione tale protocollo di cura da' assuefazione!
trovate qualcosa da fargli leggere o fategli prendere qualche decisione: a seconda della dose del medicamento somministrato otterrete un sollievo per diverse ore superando cosi' la situazione d'emergenza
Alcune terapie d'urto possono essere d'aiuto in casi particolari
Non credete a chi sostiene che su Unix i virus non esistono. Esistono e sono anche molto complessi da curare; e' pero' vero che sono molto meno frequenti che su Windows.
E' importante sottolineare che esistono molte altre forme di infezione come i worms (i vermi), i trojan (che non sono il mestiere piu' vecchio del mondo), ... e molte altre creature aliene che spesso vengono impropriamente confuse con i virus veri e propri.
Sintomi:
comportamento strano del sistema
utilizzo anormale di risorse (eg. CPU, network)
Prognosi:
utilizzare un antivirale specifico
evitare in modo assoluto il contagio
nei casi piu' gravi terminare il sistema e ripartire con un backup sicuro
La prevenzione e' la migliore arma contro i virus e le altre infezioni!
Alcune situazioni d'emergenza richiedono
una operativa relativamente complessa che, sebbene ben note agli esperti degli
specifici domini, possono non essere note al personale non esperto.
In questo capitolo vengono riportati i singoli passi per effettuare correttamente
i principali interventi citati nei capitoli precedenti.
Nell'effettuare gli interventi e' necessaria
una notevole attenzione: la cura puo' essere peggiore del male!
[Ippocrate: Primum non nocere - First, do not harm!]
Prima di cancellare un file e' necessario porsi alcune domande:
Un errore di valutazione, oltre a non risolvere il problema originale, puo' portare a patologie piu' gravi (eg. File fantasma) ed a perdite di dati.
Le protocolli di terapia utilizzabili in alternativa sono i seguenti:
La cancellazione e l'annullamento comportano la perdita di dati. Lo spostamento richiede un tempo maggiore (e naturalmente richiede spazio disco) se effettuato su un altro file system; se e' effettuato sullo stesso file system e' veloce ma... non serve a nulla in termini di spazio! L'annullamento o azzeramento e' necessario quando vi sono processi attivi che agiscono sul file (le alter tecniche sono inutili e creano ulteriori problemi) ed e' altrimenti consigliabile per evitare problemi sucessivi (eg. Problemi di accesso).
Un consiglio: controllate piu' volte prima di cancellare qualcosa...
Prima uccidere o terminare un processo e' necessario porsi alcune domande:
Un errore di valutazione, oltre a non risolvere il problema originale, puo' portare a patologie piu' gravi (eg. Blocco di un processo) ed a perdite di dati.
Le protocolli di terapia da utilizzare e' il seguente:
Uccidere gli zombie non serve: sono gia' morti (cfr. Zombie).
Un consiglio: controllate piu' volte prima di ammazzare qualcuno...
In alcuni casi e' necessario effettuare uno shutdown di una macchina Unix. Deve essere posta particolare attenzione poiche' tale intervento porta ad un blocco completo di tutte le attivita' correnti sulla macchina in esame.
Per il blocco della macchina il comando da utilizzare e':
shutdown -i0 -g0 -y
Nel caso in cui si voglia effettuare immediatamente una ripartenza del sistema il comando da utilizzare e':
shutdown -i6 -g0 -y
Nel caso in cui la macchina Unix sia spenta per effettuare il reboot verificare che non vi siano cassette, dischetti, .. nei drive e riaccendere la macchina.
Nel caso in cui lo spegnimento della macchina Unix non sia stato effettuato correttamente alla ripartenza viene automaticamente effettuato un file system check (fsck). Il file system check parla da solo, si fa domande e si risponde sempre y. In alcuni, rari casi, si risponde NO e si blocca; in tali casi e' necessaria una attivazione manuale (rispondendo YES).
Alla partenza del sistema (bootstrap) vengono attivati una serie di servizi di sistema ed applicativi. In alcune situazioni puo' essere utile disattivare e riattivare tali servizi anche a sistema attivo.
1. Collegarsi come utente root
2. Spostarsi nella directory dei comandi di boot con cd /etc/rc2.d
3. Disattivare il servizio con il comando ./S88sendmail stop
4. Riattivare il servizio con il comando ./S88sendmail start
Naturalmente l'esempio si riferisce al servizio di sistema del sendmail ma puo' essere ugualmente applicato a tutti gli altri servizi.
Per i servizi applicativi spesso la sequenza di attivazione e' piu' complessa e richiede l'utilizzo di utenti specifici. Mancando tuttavia regole generali non e' possibile fare un esempio specifivo.
Non si hanno casi certi in cui tale terapia sia stata risolutiva per le patologie di interesse (Utente in panico e Utente rompiscatole). Resta comunque, in determinate condizioni, un piacevole passatempo ed e' stato percio' citato in questa antologia.
La precisa operativa viene descritta nella relativa documentazione.
(NdA) In ogni caso continuero' nei tentativi di sperimentazione per amore della scienza medica anche se debbo ammettere alcune difficolta' nell'ottenere il permesso dai parenti del paziente.
Naturalmente sul sistema possono essere operati molti altri interventi. Tuttavia questi non ricadono nella categoria degli interventi di pronto soccorso ovvero non possono essere svolti senza l'intervento di uno specialista. Si e' comunque ritenuto opportuno riportarne un breve elenco anche perche' alcune patologie possono risultare causate da operative non corrette durante tali interventi.
In alcuni casi debbono essere espletati
alcuni adempimenti burocratici o legali.
Le situazioni d'errore ed i dati relativi debbono essere documentati e riportati
su file di facile accesso. A fronte di problemi documentare in maniera completa
tutti gli estremi della situazione occorsa. Di ogni problema e' piu' che opportuno
derminare in maniera sicura la causa effettiva dell'anomalia (naturalmente non
e' sempre semplice ma, parafrasando un famoso proverbio: degli errori dei sistemisti
sono pieni i log!).
Alcuni problemi debbono essere riportati ai fornitori. Tra questi tutti gli errori hardware, i panic di sistema, anomalie del sistema operativo, anomalie dell'RDBMS. A parte gli errori hardware tali eventi sono poco frequenti e debbono essere adeguatamente documentati.
E' fondamentale mantenere aggiornata per ogni sistema una cartella clinica riportante tutti gli interventi effettuati e le principali patologie occorse al sistema.
Quanto riportato in questo manuale e' necessariamente indicativo come e' opportuno in un documento di veloce consultazione per le emergenze. E' tuttavia disponibile un'ampia documentazione sulle diverse specialita'.
Il sistema operativo Unix presenta diverse versioni e "dialetti". Nella Stele di Rosetta sono riportati alcuni comandi sulle principali versioni di Unix. Maggior dettaglio si puo' trovare nella documentazione specifica per sistema: Sun Solaris, linux, HP-UX, IBM AIX, Compaq/Digital Tru64/Digital Unix, ...
Comandi poco noti ma molto potenti sono descritti nel documento Comandi Unix poco noti. Una trattazione piuttosto ampia e pratica delle problematiche di sicurezza e' riportata nel documento Sicurezza su Unix.
Sono ottimi strumenti diagnostici ed effettuano un grande numero di esami clinici i report generati con Unix utilities.
Anche sugli RDBMS relazionali, spesso
ospitati sui sistemi Unix, e' disponibile parecchia documentazione: Introduzione
ai database relazionali ed a Oracle, Startup
e Shutdown di Oracle, Corso di amministrazione
su Oracle, Informix, ...
Testo: Manuale di pronto soccorso UNIX
Data: 29 Febbraio 1998
Versione: 2.0.3 - 31 Febbraio 2005
Autore: mail@meo.bogliolo.name