Antworten:
Nur Programme mit Root-Rechten können ein System ordnungsgemäß herunterfahren. Wenn ein System auf normale Weise heruntergefahren wird, ist es entweder ein Benutzer mit Root-Rechten oder ein ACPI-Skript. In beiden Fällen können Sie dies anhand der Protokolle herausfinden. Ein Herunterfahren des ACPI kann durch Drücken des Netzschalters, Überhitzung oder schwachen Akku (Laptop) verursacht werden. Ich habe den dritten Grund vergessen, die USV-Software bei Stromausfall, die sowieso einen Alarm sendet.
Vor kurzem hatte ich ein System, das wiederholt undankbar abschaltete. Es stellte sich heraus, dass es überhitzt und der Mobo so konfiguriert war, dass er sich nur vorzeitig ausschaltete. Das System hatte keine Möglichkeit, Protokolle zu speichern, aber glücklicherweise zeigte die Überwachung der Systemtemperatur, dass der Anstieg unmittelbar vor dem Ausschalten einsetzte.
Wenn es sich also um ein normales Herunterfahren handelt, wird es protokolliert, wenn es sich um eine Störung handelt ... Viel Glück, und wenn es sich um ein kaltes Herunterfahren handelt, besteht Ihre beste Chance zu wissen, dass Sie die Umgebung steuern und überwachen müssen.
Probieren Sie die folgenden Befehle aus:
Liste der letzten Neustarteinträge anzeigen:
last reboot | less
Liste der letzten Abschalteinträge anzeigen:
last -x | less
oder genauer:
last -x | grep shutdown | less
Sie werden jedoch nicht wissen, wer es getan hat. Wenn Sie wissen möchten, wer es getan hat, müssen Sie ein bisschen Code hinzufügen, was bedeutet, dass Sie es beim nächsten Mal wissen werden.
Ich habe diese Ressource online gefunden. Es könnte für Sie nützlich sein:
Wie finde ich heraus, wer oder was mein System gestoppt hat?
last -x shutdown
Es gibt ein paar Dinge zu überprüfen:
Führen Sie diesen Befehl * aus und vergleichen Sie die Ausgabe mit den folgenden Beispielen:
last -x | head | tac
Ein normales Herunterfahren und Hochfahren sieht folgendermaßen aus (beachten Sie, dass ein Herunterfahren-Ereignis und dann ein Systemstartereignis vorliegt):
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 einigen Fällen wird möglicherweise Folgendes angezeigt (Beachten Sie, dass beim Herunterfahren keine Zeile angezeigt wird, das System sich jedoch auf Runlevel 0 befand. Dies ist der "Stopp-Status"):
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)
Ein unerwartetes Herunterfahren aufgrund eines Stromausfalls sieht folgendermaßen aus (beachten Sie, dass ein Systemstartereignis ohne vorheriges Systemabschlussereignis vorliegt):
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)
Ein Bash-Befehl zum Filtern der interessantesten Protokollmeldungen lautet wie folgt:
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'
Wenn ein unerwartetes Ausschalten oder ein Hardwarefehler auftritt, werden die Dateisysteme nicht ordnungsgemäß ausgehängt, sodass Sie beim nächsten Start möglicherweise die folgenden Protokolle erhalten:
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.
Wenn sich das System ausschaltet, weil der Benutzer den Ein- / Ausschalter gedrückt hat, werden Protokolle wie folgt angezeigt:
systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.
Nur wenn das System ordnungsgemäß heruntergefahren wird, erhalten Sie Protokolle wie folgt:
rsyslogd: ... exiting on signal 15
Wenn das System aufgrund einer Überhitzung heruntergefahren wird, werden folgende Protokolle angezeigt:
critical temperature reached...,shutting down
Wenn Sie über eine USV verfügen und einen Dämon zur Überwachung der Stromversorgung und zum Herunterfahren betreiben, sollten Sie dessen Protokolle überprüfen (NUT-Protokolle in / var / log / messages, apcupsd-Protokolle in / var / log / apcupsd *).
Anmerkungen
*: Hier ist die Beschreibung der lastManpage:
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.
Wir verwenden head, um die letzten 10 Ereignisse taczu speichern, und wir verwenden , um die Reihenfolge umzukehren, damit wir nicht durch die Tatsache verwirrt werden, dass die letzten Abzüge vom letzten zum letzten Ereignis gedruckt wurden.
tacKommando
Einige mögliche Protokolldateien zum Durchsuchen: (Ich habe ein Ubuntu-System gefunden, hoffe aber, dass sie auf den meisten Linux / Unix-Systemen vorhanden sind.)
/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
Auch diese Protokolldateien sind auf einem Ubuntu-System vorhanden, daher können die Dateinamen unterschiedlich sein. Der tailBefehl ist dein Freund.
Vereinfachen Sie die lastAnzeige der System-Shutdown-Einträge und führen Sie Änderungen und Filterungen auf shutdownund reboot:
last -x shutdown reboot
cat foo | grep bargegen grep bar fooArt und Weise, scheint es , dass zuletzt die Filterung selbst in der Lage ist.
Ich hatte ein ähnliches Bedürfnis auf einem Debian 7.8 und beobachte, dass im Protokoll im Grunde keine klare und explizite Meldung enthalten ist, was ein wenig überraschend ist.
Durchsuchen zeigt /var/logdie Zeit an, zu der die Maschine heruntergefahren wurde, zeigt das ordnungsgemäße Herunterfahren der Daemons usw., jedoch nicht den ursprünglichen Grund.
shutdown[25861]: shutting down for system halt
Die anderen genannten Lösungen ( last -x) haben nicht viel geholfen.
Lesen, /etc/acpi/powerbtn-acpi-support.shdas beinhaltet:
if [-x /etc/acpi/powerbtn.sh]; dann
# Kompatibilität mit alten Konfigurationsskripten aus dem acpid-Paket
/etc/acpi/powerbtn.sh
elif [-x /etc/acpi/powerbtn.sh.dpkg-bak]; dann
# Kompatibilität mit alten Konfigurationsskripten aus dem acpid-Paket
# was immer noch da ist, weil es vom admin geändert wurde
/etc/acpi/powerbtn.sh.dpkg-bak
sonst
# Normale Handhabung.
/ sbin / shutdown -h -P jetzt "Einschaltknopf gedrückt"
fi
Beachten Sie, dass als Parameter des shutdownBefehls ein expliziter Text angegeben wird . Ich würde erwarten, dass dieser String automatisch vom Shutdown-Programm protokolliert wird.
Um eine explizite Nachricht zu erhalten, habe ich den folgenden Text (als root) in eine neu erstellte /etc/acpi/powerbtn.shausführbare Datei mit eingefügtchmod a+x /etc/acpi/powerbtn.sh
#! / bin / sh
Logger in /etc/acpi/powerbtn.sh, vermutlich "Power-Taste gedrückt"
/ sbin / shutdown -h -P jetzt "Einschaltknopf gedrückt"
Wenn Sie dies auf diese Weise tun, wird dies wahrscheinlich länger dauern als das Ändern /etc/acpi/powerbtn-acpi-support.sh. Die letztere Option würde wahrscheinlich ihre Wirkung beim nächsten Upgrade des Pakets verlieren acpi-support-base.
Beachten Sie, dass Ubuntu 14.04 dies anders macht (es gibt /etc/acpi/powerbtn.shbereits einen anderen Inhalt als das acpidPaket). Auch Debian 8 macht das wahrscheinlich anders. Fühlen Sie sich frei, Varianten anzubieten.
Und jetzt , wenn die Power - Taste gedrückt wird, erscheint eine Zeile wie unten in /var/log/messages, /var/log/syslogund /var/log/user.log:
logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed
Das ist eine explizite Meldung im Protokoll.
acpi-support-baseund die acpidPakete in Betracht zu ziehen . Ich habe mich nicht getestet. Können Sie erläutern, welche Distribution und Version davon profitiert?
Ich habe nur eine unbeholfene Idee, aber vielleicht funktioniert es für Sie: Geben Sie den Befehl ein lastund überprüfen Sie die Anmeldeinformationen für alle Benutzer. filtern Sie dann die Benutzer mit der Berechtigung, die zu haltdiesem Zeitpunkt angemeldet war. dann checke ihre .bash_historydatei aus um zu sehen ob sie halt eingegeben haben oder nicht.
In meinem Fall hatte ich ein Problem mit Überhitzung und fand das Protokoll in / var / log / syslog durch ein 'grep shut *' im Ordner / var / log.
Der protokollierte Fehler war:
Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down
Ich habe auf meiner KVM-VM (wo ich mich gefragt habe, ob ein Neustart des Hosts das Herunterfahren der Gäste sauber macht) genau das eingegeben, was ich brauchte /var/log/auth.log(zusätzlich zum last -x shutdownAnzeigen derselben). Dort tauchten folgende Zeilen auf:
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 -xZeigt diese Zeilen an. Beachten Sie, dass sie in der Reihenfolge " Neueste zuerst" gedruckt werden (dh zuerst die letzte Zeile lesen und dann nach oben gehen), jedoch aufgrund des Zurücksetzens der Uhr (23:56 vor dem Start, 23:55 nach dem Start). Auch in den vorherigen Zeilen ist zu erkennen, dass die Reihenfolge etwas verwirrend ist:
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)
Um zu überprüfen, ob die Gäste sauber heruntergefahren werden, wenn der Host gestartet wird, könnte ich mich auch einfach bei einem der Gäste anmelden (ssh) und dort bleiben, wenn ich den Host hochfahre, und die folgenden Zeilen im Terminal erhalten:
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 das Herunterfahren eines Skripts
Das Skript muss alle Parameter usw. an die ursprüngliche ausführbare Shutdown-Datei übergeben,
ABER: Das Skript muss diese protokollieren
last -x)
cat /usr/adm/syslog
in meinem Fall war es die ups-Software, die den Server herunterfährt.
/etc/rc.d/7/upsd.boot
/var/log/acpidich ein bisschen Glück mit : Es stellte sich heraus, dass der Ein- / Ausschalter gedrückt wurde. Irgendwelche anderen Ideen, wo man nachschaut, wenn acpid keine Ahnung hat?