it-swarm.it

Come scoprire dai registri cosa ha causato l'arresto del sistema?

Per esempio. Lo vedo tra /var/log/messages:

Mar 01 23:12:34 hostname shutdown: shutting down for system halt

C'è un modo per scoprire cosa ha causato l'arresto? Per esempio. è stato eseguito dalla console o qualcuno ha premuto il pulsante di accensione, ecc.?

123
alex

Solo i programmi con privilegi di root possono arrestare con grazia un sistema. Quindi quando un sistema si spegne in modo normale, è un utente con privilegi di root o uno script acpi. In entrambi i casi puoi scoprirlo controllando i registri. Un arresto acpi può essere causato dalla pressione del pulsante di accensione, dal surriscaldamento o dalla batteria scarica (laptop). Ho dimenticato il terzo motivo, il software UPS in caso di interruzione dell'alimentazione, che invierà comunque un avviso.

Recentemente ho avuto un sistema che ha iniziato ripetutamente a spegnersi in modo sfortunato, ho scoperto che si stava surriscaldando e il mobo era configurato per spegnersi presto. Il sistema non ha avuto la possibilità di salvare i log, ma fortunatamente il monitoraggio della temperatura del sistema ha mostrato che stava iniziando ad aumentare appena prima di spegnersi.

Quindi, se si tratta di un arresto normale, verrà registrato, se si tratta di un'intrusione ... buona fortuna, e se si tratta di un arresto a freddo, la migliore possibilità di sapere è controllare e monitorare il suo ambiente.

50
forcefsck

Prova i seguenti comandi:

Visualizza l'elenco delle ultime voci di riavvio: last reboot | less

Visualizza l'elenco delle ultime voci di arresto: last -x | less

o più precisamente: last -x | grep shutdown | less

Tuttavia, non saprai chi è stato. Se vuoi sapere chi è stato, dovrai aggiungere un po 'di codice, il che significa che lo saprai la prossima volta.

Ho trovato questa risorsa online. Potrebbe esserti utile:

Come scoprire chi o cosa ha bloccato il mio sistema

127

Devi esaminare 2 cose:

  1. L'output del comando last -x
  2. I file di registro in /var/log/

Utilizzare questi 2 comandi e continuare a leggere per ulteriori informazioni.

last -x | head | tac

grep -iv ': starting\|kernel: .*: Power Button\|watching system buttons\|Stopped Cleaning Up\|Started Crash recovery kernel' \
  /var/log/messages /var/log/syslog /var/log/apcupsd* \
  | grep -iw 'recover[a-z]*\|power[a-z]*\|shut[a-z ]*down\|rsyslogd\|ups'

1) Riguardo all'output dell'ultimo comando -x

Esegui questo comando * e confronta l'output con gli esempi seguenti:

last -x | head | tac

Esempi di arresto normale

Un arresto normale e l'accensione si presentano così (si noti che si dispone di un evento di arresto e quindi di un evento di avvio del sistema):

runlevel (to lvl 0)   2.6.32- Sat Mar 17 08:48 - 08:51  (00:02) 
shutdown system down  ... <-- first the system shuts down   
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 3)       

In alcuni casi potresti vedere questo (nota che non c'è alcuna linea sull'arresto ma il sistema era al runlevel 0 che è lo "stato di arresto"):

runlevel (to lvl 0)   ... <-- first the system shuts down (init level 0)
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 2)   2.6.24-... Fri Aug 10 15:58 - 15:32 (2+23:34)   

Esempi di spegnimento imprevisto

Un arresto imprevisto dovuto alla perdita di potenza è simile al seguente (si noti che si dispone di un evento di avvio del sistema senza un precedente evento di arresto del sistema):

runlevel (to lvl 3)   ... <-- the system was running since this momemnt
reboot   system boot  ... <-- then we've a boot WITHOUT a prior shutdown
runlevel (to lvl 3)   3.10.0-693.21.1. Sun Jun 17 15:40 - 09:51  (18:11)    

2) Per quanto riguarda i log in/var/log /

Un comando bash per filtrare i messaggi di registro più interessanti è questo:

grep -iv ': starting\|kernel: .*: Power Button\|watching system buttons\|Stopped Cleaning Up\|Started Crash recovery kernel' \
  /var/log/messages /var/log/syslog /var/log/apcupsd* \
  | grep -iw 'recover[a-z]*\|power[a-z]*\|shut[a-z ]*down\|rsyslogd\|ups'

Quando si spegne inaspettatamente o si verifica un guasto hardware, i filesystem non verranno smontati correttamente, quindi al prossimo avvio potresti ottenere registri come questo:

EXT4-fs ... INFO: recovery required ... 
Starting XFS recovery filesystem ...
systemd-fsck: ... recovering journal
systemd-journald: File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.

Quando il sistema si spegne perché l'utente ha premuto il pulsante di accensione, si ottengono registri come questo:

systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.

Solo quando il sistema si arresta in modo ordinato si ottengono registri come questo:

rsyslogd: ... exiting on signal 15

Quando il sistema si arresta a causa del surriscaldamento, si ottengono registri come questo:

critical temperature reached...,shutting down

Se hai un UPS e esegui un demone per monitorare l'alimentazione e lo spegnimento, dovresti ovviamente controllare i suoi log (NUT accede/var/log/messaggi ma apcupsd accede/var/log/apcupsd *)


Notes

*: Ecco la descrizione di last dalla sua pagina man:

last [...] prints information about connect times of users. 
Records are printed from most recent to least recent.  
[...]
The special users reboot and shutdown log in when the system reboots
or (surprise) shuts down. 

Usiamo head per conservare gli ultimi 10 eventi e utilizziamo tac per invertire l'ordine, in modo da non confonderci per il fatto che le ultime stampe dall'evento più recente a quello meno recente.

26
ndemou

Alcuni possibili file di log da esplorare: (ho trovato un sistema Ubuntu, ma spero che siano presenti sulla maggior parte dei sistemi Linux/Unix)

/var/log/debug
/var/log/syslog (will be pretty full and may be harder to browse)
/var/log/user.log
/var/log/kern.log
/var/log/boot

Ancora una volta, questi file di registro sono presenti su un sistema Ubuntu, quindi i nomi dei file potrebbero essere diversi. Il comando tail è tuo amico.

11
user6148

Semplifica usando last visualizzando le voci di spegnimento del sistema ed esegui le modifiche di livello e il filtro su shutdown e reboot:

last -x shutdown reboot
8
jhvaras

Non del tutto soddisfacente

Avevo un bisogno simile su un Debian 7.8 e osservo che praticamente non c'è nessun messaggio chiaro ed esplicito nel registro, il che è un po 'sorprendente.

Grep attraverso /var/log Direbbe l'ora in cui la macchina è stata spenta, mostrerà l'arresto dei demoni, ecc., Ma non il motivo iniziale.

shutdown[25861]: shutting down for system halt

Le altre soluzioni citate (last -x) Non sono state di grande aiuto.

Guardando come funziona

Lettura /etc/acpi/powerbtn-acpi-support.sh Che include:

 if [-x /etc/acpi/powerbtn.sh]; then 
 # Compatibilità con il vecchio script di configurazione dal pacchetto acpid 
 /etc/acpi/powerbtn.sh[.____.[Elif [-x /etc/acpi/powerbtn.sh.dpkg-bak] ; quindi 
 # Compatibilità con il vecchio script di configurazione dal pacchetto acpid 
 # che è ancora disponibile perché è stato modificato dall'amministratore 
 /etc/acpi/powerbtn.sh.dpkg-bak 
 else 
 # Gestione normale. 
/sbin/shutdown -h -P ora "Pulsante di accensione premuto" 
 fi 

Si noti che viene fornito un testo esplicito come parametro del comando shutdown. Mi aspetto che quella stringa venga registrata automaticamente dal programma di spegnimento.

Regolazione per registri migliori

Ad ogni modo, per ottenere un messaggio esplicito ho inserito il testo seguente (come root) in un /etc/acpi/powerbtn.sh Appena creato e reso eseguibile con chmod a+x /etc/acpi/powerbtn.sh

 #!/bin/sh 
 logger in /etc/acpi/powerbtn.sh, presumibilmente "Pulsante di accensione premuto" 
/sbin/shutdown -h -P now "Pulsante di accensione premuto "

Farlo in questo modo probabilmente farà una modifica più duratura rispetto alla modifica di /etc/acpi/powerbtn-acpi-support.sh. Quest'ultima opzione probabilmente perderebbe il suo effetto al prossimo aggiornamento del pacchetto acpi-support-base.

Si noti che Ubuntu 14.04 lo fa diversamente (/etc/acpi/powerbtn.sh Esiste già con contenuti diversi dal pacchetto acpid). Inoltre, Debian 8 probabilmente lo fa diversamente. Sentiti libero di offrire varianti.

Profitto!

E ora quando si preme il pulsante di accensione, una riga come sotto appare in /var/log/messages, /var/log/syslog E /var/log/user.log:

logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed

Questo è un messaggio esplicito nel registro.

8

Ho solo un'idea goffa, ma forse funziona per te: inserisci il comando last e controlla le informazioni di accesso per tutti gli utenti. quindi, filtrare gli utenti con l'autorizzazione richiesta per halt che erano stati registrati in quel momento. quindi dai un'occhiata a .bash_history file per vedere se sono entrati in arresto o meno.

4
sazary

Nel mio caso ho avuto un problema di surriscaldamento e ho trovato il log in/var/log/syslog da 'grep shut *' nella cartella/var/log.

L'errore registrato è stato questo:

Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down
1
luandrea

Ho appena inserito il chip sul mio KVM VM (dove mi chiedevo se un riavvio di Host ha fatto un arresto pulito degli ospiti), ho trovato quello di cui avevo bisogno in /var/log/auth.log (inoltre last -x shutdown mostra lo stesso). Lì apparvero queste righe:

Sep  3 23:56:31 Web systemd-logind[531]: Power key pressed.
Sep  3 23:56:31 Web systemd-logind[531]: Powering Off...
Sep  3 23:56:31 Web systemd-logind[531]: System is powering down.
Sep  3 23:55:45 Web systemd-logind[591]: New seat seat0.
Sep  3 23:55:45 Web systemd-logind[591]: Watching system buttons on /dev/input/event0 (Power Button)
Sep  3 23:55:54 Web sshd[805]: Server listening on 0.0.0.0 port 22.
Sep  3 23:55:54 Web sshd[805]: Server listening on :: port 22.

last -x mostra queste righe, nota che vengono stampate nell'ordine più recente-primo (cioè leggi prima l'ultima riga e poi sali su), ma a causa del reset dell'orologio (23: 56 prima dell'avvio, dopo le 23:55) evidente anche nelle righe precedenti, l'ordine sembra un po 'sconcertante:

runlevel (to lvl 2)   3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
reboot   system boot  3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
shutdown system down  3.13.0-123-gener Sun Sep  3 23:56 - 23:55  (00:00)    
runlevel (to lvl 0)   3.13.0-123-gener Sun Sep  3 23:56 - 23:56  (00:00)

Da parte mia, controllando che gli ospiti vengano chiusi in modo pulito all'avvio di Host, potrei anche accedere a (ssh) uno degli ospiti e rimanere lì quando avvio l'host, ottenendo queste linee nel terminale:

[email protected]:~#
Broadcast message from [email protected]
        (unknown) at 22:25 ...

The system is going down for power off NOW!
Connection to web closed by remote Host.
Connection to web closed.
1
stolsvik

alias l'arresto di uno script
lo script deve fornire tutti i parametri, ecc. all'eseguibile dell'arresto originale
MA: lo script deve registrarli

0
LanceBaynes