Odpowiedzi:
Tylko programy uprzywilejowane jako root mogą z wdziękiem zamknąć system. Kiedy więc system zamyka się w normalny sposób, jest to albo użytkownik z uprawnieniami roota, albo skrypt acpi. W obu przypadkach można to sprawdzić, sprawdzając dzienniki. Wyłączenie acpi może być spowodowane naciśnięciem przycisku zasilania, przegrzaniem lub rozładowaniem baterii (laptopa). Zapomniałem trzeciego powodu - oprogramowania UPS, gdy nastąpi awaria zasilania, który i tak wyśle ostrzeżenie.
Niedawno miałem system, który kilkakrotnie zaczął się beznadziejnie wyłączać, okazało się, że się przegrzewa, a mobo skonfigurowano tak, by wyłączał się wcześnie. System nie miał szansy na zapisanie logów, ale na szczęście monitorowanie temperatury systemu pokazało, że zaczyna rosnąć tuż przed wyłączeniem.
Więc jeśli jest to normalne zamknięcie, zostanie ono zarejestrowane, jeśli jest to wtargnięcie ... powodzenia, a jeśli jest to zimne zamknięcie, najlepszą szansą, aby wiedzieć, jest kontrolowanie i monitorowanie jego otoczenia.
Wypróbuj następujące polecenia:
Wyświetl listę ostatnich wpisów ponownego uruchomienia:
last reboot | less
Wyświetl listę ostatnich pozycji zamknięcia:
last -x | less
lub dokładniej:
last -x | grep shutdown | less
Jednak nie będziesz wiedział, kto to zrobił. Jeśli chcesz wiedzieć, kto to zrobił, musisz dodać trochę kodu, co oznacza, że będziesz wiedział następnym razem.
Znalazłem ten zasób online. Może ci się przydać:
last -x shutdown
Jest kilka rzeczy do sprawdzenia:
Uruchom to polecenie * i porównaj dane wyjściowe z poniższymi przykładami:
last -x | head | tac
Normalne zamykanie i włączanie wygląda następująco (pamiętaj, że masz zdarzenie zamknięcia, a następnie zdarzenie rozruchu systemu):
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)
W niektórych przypadkach możesz to zobaczyć (zwróć uwagę, że nie ma linii o wyłączeniu, ale system był na poziomie 0, który jest „stanem zatrzymania”):
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)
Nieoczekiwane zamknięcie z powodu utraty zasilania wygląda następująco (pamiętaj, że masz zdarzenie rozruchu systemu bez wcześniejszego zdarzenia zamknięcia systemu):
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)
Polecenie bash do filtrowania najciekawszych komunikatów w dzienniku jest następujące:
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'
Gdy wystąpi nieoczekiwane wyłączenie zasilania lub awaria sprzętu, systemy plików nie zostaną poprawnie odmontowane, więc przy następnym uruchomieniu możesz uzyskać dzienniki w następujący sposób:
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.
Gdy system wyłączy się, ponieważ użytkownik nacisnął przycisk zasilania, otrzymasz dzienniki w następujący sposób:
systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.
Tylko wtedy, gdy system zostanie zamknięty zgodnie z porządkiem, otrzymujesz dzienniki w następujący sposób:
rsyslogd: ... exiting on signal 15
Gdy system wyłącza się z powodu przegrzania, otrzymujesz dzienniki w następujący sposób:
critical temperature reached...,shutting down
Jeśli masz zasilacz UPS z uruchomionym demonem w celu monitorowania zasilania i zamknięcia, oczywiście powinieneś sprawdzić jego dzienniki (NUT loguje się do / var / log / messages, ale apcupsd loguje się do / var / log / apcupsd *)
Notatki
*: Oto opis laststrony 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.
Używamy headdo przechowywania ostatnich 10 zdarzeń i tacodwracamy kolejność, aby nie mylić faktu, że ostatnie odbitki od ostatniego do najnowszego wydarzenia.
tacpolecenia
Niektóre możliwe pliki dziennika do eksploracji: (znaleziono system Ubuntu, ale mam nadzieję, że są one obecne w większości systemów 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
Ponownie, te pliki dziennika są obecne w systemie Ubuntu, więc nazwy plików mogą być inne. tailKomenda jest twoim przyjacielem.
Uprość, lastwyświetlając wpisy zamknięcia systemu i zmiany poziomu uruchamiania oraz filtrowanie shutdowni reboot:
last -x shutdown reboot
cat foo | grep barvs grep bar foorodzaju sposób, wydaje się, że ostatni jest zdolny do filtrowania siebie.
Miałem podobną potrzebę na Debianie 7.8 i zauważyłem, że w zasadzie nie ma jasnego i wyraźnego komunikatu w dzienniku, co jest trochę zaskakujące.
Grep through wskaże /var/logczas wyłączenia maszyny, pokaże prawidłowe zamknięcie demonów itp., Ale nie początkowy powód.
shutdown[25861]: shutting down for system halt
Inne wspomniane rozwiązania ( last -x) niewiele pomogły.
Czytanie, /etc/acpi/powerbtn-acpi-support.shktóre obejmuje:
if [-x /etc/acpi/powerbtn.sh]; następnie
# Kompatybilność ze starym skryptem konfiguracyjnym z pakietu acpid
/etc/acpi/powerbtn.sh
elif [-x /etc/acpi/powerbtn.sh.dpkg-bak]; następnie
# Kompatybilność ze starym skryptem konfiguracyjnym z pakietu acpid
# który wciąż jest dostępny, ponieważ został zmieniony przez administratora
/etc/acpi/powerbtn.sh.dpkg-bak
jeszcze
# Normalne obchodzenie się.
/ sbin / shutdown -h -P teraz „Naciśnięty przycisk zasilania”
fi
Zauważ, że jako parametr shutdownpolecenia podano wyraźny tekst . Spodziewałbym się, że ten ciąg będzie automatycznie rejestrowany przez program zamykający.
W każdym razie, aby otrzymać wyraźną wiadomość, umieszczam tekst poniżej (jako root) w nowo utworzonym /etc/acpi/powerbtn.shpliku wykonywalnym za pomocąchmod a+x /etc/acpi/powerbtn.sh
#! / bin / sh
logger w /etc/acpi/powerbtn.sh, prawdopodobnie „Przycisk zasilania wciśnięty”
/ sbin / shutdown -h -P teraz „Naciśnięty przycisk zasilania”
Wykonanie tego w ten sposób prawdopodobnie spowoduje dłuższą zmianę niż modyfikację /etc/acpi/powerbtn-acpi-support.sh. Ta ostatnia opcja prawdopodobnie straciłaby swój efekt przy kolejnej aktualizacji pakietu acpi-support-base.
Zauważ, że Ubuntu 14.04 robi to inaczej ( /etc/acpi/powerbtn.shjuż istnieje z inną zawartością niż acpidpakiet). Debian 8 prawdopodobnie robi to inaczej. Zapraszam do oferowania wariantów.
A teraz, gdy zostanie naciśnięty przycisk zasilania, pojawi się linia taka jak poniżej /var/log/messages, /var/log/syslogi /var/log/user.log:
logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed
To jest wyraźny komunikat w dzienniku.
acpi-support-basei acpidpakietów. Nie testowałem się. Czy możesz wyjaśnić, która dystrybucja i wersja przynosi korzyści?
Mam tylko niezgrabny pomysł, ale może Ci się uda: wpisz polecenie lasti sprawdź informacje logowania dla wszystkich użytkowników. następnie odfiltruj użytkowników z uprawnieniami wymaganymi do halttego zalogowania w tym momencie. następnie sprawdź ich .bash_historyplik, aby sprawdzić, czy zatrzymali się, czy nie.
W moim przypadku miałem problem z przegrzaniem i znalazłem dziennik / var / log / syslog w folderze „grep shut *” w folderze / var / log.
Zarejestrowany błąd był następujący:
Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down
Po prostu włóż to w moją maszynę wirtualną KVM (gdzie zastanawiałem się, czy ponowne uruchomienie hosta spowodowało czyste zamknięcie gości), znalazłem to, czego potrzebowałem /var/log/auth.log(oprócz last -x shutdowntego samego). Tam pojawiły się następujące linie:
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 -xpokazuje te linie, zauważ, że są drukowane w najnowszej kolejności (tzn. najpierw przeczytaj ostatni wiersz, a następnie przejdź w górę), ale z powodu resetu zegara (23:56 przed uruchomieniem, 23:55 po) widoczne również w poprzednich wierszach, kolejność wydaje się nieco zadziwiająca:
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)
Ze swojej strony, sprawdzając, czy goście są bezpiecznie zamykani, gdy host jest uruchamiany, mógłbym również zalogować się do (ssh) jednego z gości i pozostać tam, gdy uruchamiam hosta, pobierając te linie do terminalu:
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 zamknięcie skryptu
skrypt musi podać wszystkie parametry itp. do oryginalnego pliku wykonywalnego zamknięcia,
ALE: skrypt musi to zapisać
last -x)
cat /usr/adm/syslog
w moim przypadku było to oprogramowanie wyłączające serwer.
/etc/rc.d/7/upsd.boot
/var/log/acpid: okazało się, że przycisk zasilania został trafiony. Jakieś inne pomysły, gdzie szukać, jeśli acpid nie daje pojęcia?