it-swarm-eu.dev

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.?

123
alex

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í.

50
forcefsck

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:

Jak zjistit, kdo nebo co zastavil můj systém

127

Musíte prozkoumat 2 věci:

  1. Výstup příkazu last -x
  2. 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.

26
ndemou

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.

11
user6148

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
8
jhvaras

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.

8

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.

4
sazary

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
1
luandrea

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.
1
stolsvik

alias vypnutí skriptu
skript musí poskytnout všechny parametry atd. původnímu spustitelnému spustitelnému programu
ALE: skript musí tyto protokolovat

0
LanceBaynes