Risposte:
Solo i programmi con privilegi di root possono arrestare con grazia un sistema. Pertanto, quando un sistema si arresta 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 registri, 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.
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:
last -x shutdown
Ci sono un paio di cose da controllare:
Esegui questo comando * e confronta l'output con gli esempi seguenti:
last -x | head | tac
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)
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)
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 *)
Appunti
*: Ecco la descrizione lastdalla 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 headper mantenere gli ultimi 10 eventi e usiamo tacper invertire l'ordine in modo da non confonderci con il fatto che le ultime stampe dall'evento più recente a quello meno recente.
taccomando
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 tailcomando è tuo amico.
Semplifica utilizzando la lastvisualizzazione delle voci di arresto del sistema ed esegui modifiche di livello e filtri su shutdowne reboot:
last -x shutdown reboot
cat foo | grep barvs vs grep bar foo, sembra che l'ultimo sia in grado di filtrare se stesso.
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 through /var/logdirebbe 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.
Lettura /etc/acpi/powerbtn-acpi-support.shche include:
if [-x /etc/acpi/powerbtn.sh]; poi
# Compatibilità con il vecchio script di configurazione dal pacchetto acpid
/etc/acpi/powerbtn.sh
elif [-x /etc/acpi/powerbtn.sh.dpkg-bak]; poi
# Compatibilità con il vecchio script di configurazione dal pacchetto acpid
# che è ancora in giro perché è stato modificato dall'amministratore
/etc/acpi/powerbtn.sh.dpkg-bak
altro
# Gestione normale.
/ sbin / shutdown -h -P ora "Pulsante di accensione premuto"
fi
Si noti che viene fornito un testo esplicito come parametro del shutdowncomando. Mi aspetto che quella stringa venga registrata automaticamente dal programma di spegnimento.
Ad ogni modo, per ottenere un messaggio esplicito ho inserito il testo seguente (come root) in un /etc/acpi/powerbtn.sheseguibile appena creato conchmod a+x /etc/acpi/powerbtn.sh
#! / Bin / sh
logger in /etc/acpi/powerbtn.sh, presumibilmente "Pulsante di accensione premuto"
/ sbin / shutdown -h -P ora "Pulsante di accensione premuto"
Farlo in questo modo probabilmente farà un cambiamento più duraturo rispetto alla modifica /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 in modo diverso ( /etc/acpi/powerbtn.shesiste già con contenuti diversi dal acpidpacchetto). Inoltre, Debian 8 probabilmente lo fa diversamente. Sentiti libero di offrire varianti.
E ora, quando viene premuto il pulsante di accensione, una linea come di seguito appare in /var/log/messages, /var/log/sysloge /var/log/user.log:
logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed
Questo è un messaggio esplicito nel registro.
acpi-support-basee i acpidpacchetti. Non mi sono messo alla prova. Puoi approfondire su quale distribuzione e versione produce vantaggi?
Ho solo un'idea goffa, ma forse funziona per te: inserisci il comando laste controlla le informazioni di accesso per tutti gli utenti. quindi, filtrare gli utenti con l'autorizzazione richiesta per haltche era stato effettuato l'accesso in quel momento. quindi controlla il loro .bash_historyfile per vedere se sono entrati in arresto o meno.
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
Ho appena inserito il chip sulla mia macchina virtuale KVM (dove mi chiedevo se un riavvio dell'host ha fatto un arresto pulito degli ospiti), ho trovato quello di cui avevo bisogno /var/log/auth.log(oltre a last -x shutdownmostrare 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 -xmostra queste righe, nota che vengono stampate nell'ultimo ordine più recente (ovvero leggi prima l'ultima riga e poi vai su), ma a causa del ripristino dell'orologio (23:56 prima dell'avvio, 23:55 dopo) 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 si spengano in modo pulito all'avvio dell'host, potrei anche accedere a (ssh) uno degli ospiti e rimanere lì quando avvio l'host, ottenendo queste linee nel terminale:
root@Web:~#
Broadcast message from root@Web
(unknown) at 22:25 ...
The system is going down for power off NOW!
Connection to web closed by remote host.
Connection to web closed.
alias l'arresto di uno script
lo script deve fornire tutti i parametri, ecc. all'eseguibile dell'arresto originale
MA: lo script deve registrare questi
last -x)
cat /usr/adm/syslog
nel mio caso è stato il software ups che ha spento il server.
/etc/rc.d/7/upsd.boot
/var/log/acpid: si è scoperto che il pulsante di accensione è stato colpito. Altre idee, dove cercare se acpid non ne ha la più pallida idea?