Jak zjistit z protokolů, co způsobilo vypnutí systému?
Např. Vidím to v /var/log/messages:
Mar 01 23:12:34 hostname shutdown: shutting down for system halt
Existuje způsob, jak zjistit, co způsobilo vypnutí? Např. Bylo to spuštěno z konzole nebo někdo stiskl tlačítko napájení atd.?
Systém může elegantně ukončit pouze privilegované programy root. Takže když se systém vypne běžným způsobem, je to buď uživatel s oprávněními root nebo skript acpi. V obou případech to zjistíte kontrolou protokolů. Vypnutí acpi může být způsobeno stisknutím tlačítka napájení, přehřátím nebo vybitou baterií (laptop). Zapomněl jsem třetí důvod, software UPS, když došlo k výpadku napájení, který pošle varování přesto.
Nedávno jsem měl systém, který se začal opakovaně vypínat nemilosrdně, ukázalo se, že se přehříval a mobo bylo nakonfigurováno tak, aby se právě vypnulo brzy. Systém neměl šanci uložit protokoly, ale naštěstí sledování teploty systému ukázalo, že se začalo zvyšovat těsně před vypnutím.
Takže pokud se jedná o normální vypnutí, bude zaznamenáno, pokud jde o vniknutí ... hodně štěstí, a pokud se jedná o zastavení za studena, vaše nejlepší šance vědět, je kontrolovat a sledovat jeho prostředí.
Vyzkoušejte následující příkazy:
Zobrazit seznam posledních restartovaných položek: last reboot | less
Zobrazit seznam posledních odstavených položek: last -x | less
nebo přesněji: last -x | grep shutdown | less
Nebudete však vědět, kdo to udělal. Pokud chcete vědět, kdo to udělal, budete muset přidat kousek kódu, což znamená, že to budete příště vědět.
Tento zdroj jsem našel online. Může být užitečné pro vás:
Musíte prozkoumat 2 věci:
- Výstup příkazu last -x
- Soubory protokolu v /var/log/
Použijte tyto 2 příkazy a pokračujte ve čtení pro další informace.
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) Pokud jde o výstup posledního příkazu -x
Spusťte tento příkaz * a porovnejte výstup s následujícími příklady:
last -x | head | tac
Příklady běžného vypnutí
Vypadá to, že normální vypnutí a zapnutí jsou následující (všimněte si, že máte vypínací událost a poté spouštěcí událost systému):
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)
V některých případech to můžete vidět (všimněte si, že neexistuje žádný řádek o vypnutí, ale systém byl na runlevel 0, což je „stav zastavení“):
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)
Neočekávané příklady vypnutí
Vypadá to neočekávané vypnutí z důvodu výpadku napájení (pamatujte, že máte událost spouštění systému bez předchozí události vypnutí systému):
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) Pokud jde o přihlášení/var/log /
Bash příkaz k filtrování nejzajímavějších zpráv protokolu je tento:
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'
Pokud dojde k neočekávanému vypnutí nebo selhání hardwaru, souborové systémy nebudou správně odpojeny, takže při příštím spuštění můžete získat tyto protokoly:
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.
Když se systém vypne, protože uživatel stiskl tlačítko napájení, dostanete protokoly takto:
systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.
Pouze když se systém řádně vypne, dostanete protokoly takto:
rsyslogd: ... exiting on signal 15
Když se systém vypne z důvodu přehřátí, dostanete protokoly takto:
critical temperature reached...,shutting down
Pokud máte UPS a provozujete démona pro monitorování napájení a vypnutí, měli byste samozřejmě zkontrolovat jeho protokoly (NUT se přihlásí/var/log/zprávy, ale apcupsd se přihlásí/var/log/apcupsd *)
Poznámky
*: Zde je popis last z jeho manuálové stránky:
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.
Používáme head k uchování posledních 10 událostí a pomocí tac k invertování objednávky, abychom se nenechali zmást skutečností, že poslední výtisky od poslední po poslední událost.
Některé možné protokolované soubory prozkoumat: (nalezeno systém Ubuntu, ale doufám, že jsou přítomny ve většině systémů 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
Tyto soubory protokolu jsou opět přítomny v systému Ubuntu, takže názvy souborů se mohou lišit. Příkaz tail je váš přítel.
Zjednodušte pomocí last zobrazování položek pro vypnutí systému a změn úrovně spouštění a filtrování na shutdown a reboot:
last -x shutdown reboot
Ne plně uspokojující
Podobnou potřebu jsem měl na Debianu 7.8 a pozoroval jsem, že v protokolu není žádná jasná a explicitní zpráva, což je trochu překvapivé.
Přejděte do /var/log A řekněte čas, kdy byl stroj vypnut, zobrazte správné vypnutí démonů atd., Ale ne počáteční důvod.
shutdown[25861]: shutting down for system halt
Jiná uvedená řešení (last -x) Moc nepomohla.
Vypadá to, jak to funguje
Čtení /etc/acpi/powerbtn-acpi-support.sh, Které zahrnuje:
pokud [-x /etc/acpi/powerbtn.sh]; then # Kompatibilita se starým konfiguračním skriptem z balíčku acpid /etc/acpi/powerbtn.sh Elif [-x /etc/acpi/powerbtn.sh.dpkg-bak] ; then # Kompatibilita se starým konfiguračním skriptem z balíčku acpid #, který stále existuje, protože jej změnil admin /etc/acpi/powerbtn.sh.dpkg-bak else # Normální manipulace. /sbin/vypnutí -h -P nyní "Tlačítko napájení stisknuto" fi
Všimněte si, že jako parametr příkazu shutdown je uveden explicitní text. Očekával bych, že tento řetězec bude automaticky protokolován programem vypnutí.
Úprava pro lepší protokoly
Abych dostal výslovnou zprávu, vložil jsem text níže (jako root) do nově vytvořeného /etc/acpi/powerbtn.sh Vytvořeného spustitelného souboru s chmod a+x /etc/acpi/powerbtn.sh
#!/bin/sh logger v /etc/acpi/powerbtn.sh, pravděpodobně „Tlačítko napájení stisknuto“ /sbin/vypnutí -h -P nyní „Tlačítko napájení stiskl "
Pokud tak učiníte, pravděpodobně bude trvat déle než změna /etc/acpi/powerbtn-acpi-support.sh. Druhá možnost pravděpodobně ztratí svůj účinek při další aktualizaci balíčku acpi-support-base.
Všimněte si, že Ubuntu 14.04 to dělá jinak (/etc/acpi/powerbtn.sh Již existuje s jiným obsahem z balíčku acpid). Také Debian 8 to pravděpodobně dělá jinak. Neváhejte a nabídněte varianty.
Zisk!
A nyní, když stisknete tlačítko napájení, se v /var/log/messages, /var/log/syslog A /var/log/user.log Objeví řádek jako níže:
logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed
Tohle je v protokolu výslovná zpráva.
Mám jen neohrabaný nápad, ale možná to funguje pro vás: zadejte příkaz last a podívejte se na přihlašovací informace pro všechny uživatele. poté filtrujte uživatele s povolením požadovaným pro halt, který byl v tu chvíli přihlášen. pak se podívejte na jejich .bash_history soubor, abyste zjistili, zda se zastavili nebo ne.
V mém případě jsem měl problém s přehřátím a našel jsem přihlášení/var/log/syslog pomocí 'grep shut *' ve složce/var/log.
Byla zaznamenána tato chyba:
Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down
Jen čip v tom, že na mém KVM VM ((kde jsem přemýšlel, zda hostitelský restart provedl čisté vypnutí hostů)), jsem našel, co jsem potřeboval v /var/log/auth.log (navíc last -x shutdown ukazuje to samé). Tam se tyto řádky ukázaly:
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 ukazuje tyto řádky, všimněte si, že jsou vytištěny v pořadí nejnovější-první (tj. nejdříve si přečtěte poslední řádek a poté nahoru), ale kvůli resetování hodin (23: 56 před bootováním, 23:55 po) také patrné v předchozích řádcích, objednávka vypadá trochu zmateně:
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)
Pokud jde o mě, když jsem zkontroloval, že se hosté po zavedení hostitele čistě vypnou, mohl jsem se také jen přihlásit (ssh) k jednomu z hostů a zůstat tam, když spustím hostitele, a dostat tyto řádky do terminálu:
[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.
alias vypnutí skriptu
skript musí poskytnout všechny parametry atd. původnímu spustitelnému spustitelnému programu
ALE: skript musí tyto protokolovat