Znaczenie kolumn w poleceniu „last”

Gdy badałem serwer, który regularnie uruchamia się ponownie, zacząłem przeglądać „ostatnie” narzędzie, ale problem polega na tym, że nie jestem w stanie znaleźć, co dokładnie oznaczają kolumny. Oczywiście przejrzałem mężczyznę, ale nie zawiera on tych informacji.

root@webservice1:/etc# last reboot   
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 09:44 - 09:58  (00:13)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 09:34 - 09:43  (00:08)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 09:19 - 09:33  (00:13)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 08:51 - 09:17  (00:25)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 00:11 - 09:17  (09:05)    
reboot   system boot  3.2.13-grsec-xxx Wed Apr 11 19:40 - 09:17  (13:36)    
reboot   system boot  3.2.13-grsec-xxx Sun Apr  8 22:06 - 09:17 (3+11:10)   
reboot   system boot  3.2.13-grsec-xxx Sat Apr  7 14:31 - 09:17 (4+18:45)   
reboot   system boot  3.2.13-grsec-xxx Fri Apr  6 10:20 - 09:17 (5+22:56)   
reboot   system boot  3.2.13-grsec-xxx Thu Apr  5 00:16 - 09:17 (7+09:01)   
reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 07:34 - 09:17 (9+01:42)   
reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 02:31 - 09:17 (9+06:45)   
reboot   system boot  3.2.13-grsec-xxx Mon Apr  2 23:17 - 09:17 (9+09:59)   

Pierwsze kolumny mają sens aż do dołączonych wersji jądra. Co dokładnie reprezentują te czasy? Ostatni wydaje się być czasem przestoju.

Po drugie, ma to być serwer w trybie 24/7, chyba że czasy się nie zgadzają, co może oznaczać, że ma przestoje lub coś podobnego. Na przykład, jeśli spojrzymy na dwie ostatnie linie, czy to oznacza, że ​​mój serwer był wyłączony od 2 kwietnia 09:17 do 3 kwietnia 02:31?

Jeśli chodzi o informacje w tle, jest to serwer Debian Squeeze.

EDYTOWAĆ

Jeśli ostatnimi kolumnami są godzina rozpoczęcia, godzina zakończenia i czas pracy, jak możesz zinterpretować te dwie linie:

reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 07:34 - 09:17 (9+01:42)   
reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 02:31 - 09:17 (9+06:45)   

Druga sesja wydaje się kończyć po rozpoczęciu pierwszej, co nie ma dla mnie sensu.

Myślę, że to trzyletni post, ale i tak odpowiem, z korzyścią dla każdego, kto spotka się z nim w przyszłości, tak jak niedawno.

Po przeczytaniu innych postów i samodzielnym monitorowaniu wyników przez pewien czas wygląda na to, że każda linia zawiera datę rozpoczęcia i godzinę sesji, godzinę zakończenia sesji (ale nie datę zakończenia) oraz czas trwania sesji (jak długo byli zalogowani) w formacie podobnym do

(dni + godziny: minuty)

Wygląda na to, że zrestartowany użytkownik zalogował się przy każdym uruchomieniu systemu i wyłączył się, gdy system został ponownie uruchomiony lub zamknięty, a na tych liniach informacja o czasie trwania sesji to czas (dni + godziny: minuty) ta „sesja” trwała, to znaczy, jak długo system był włączony, zanim został zamknięty.

Dla mnie najnowszy wpis ponownego uruchomienia pokazuje aktualny czas jako czas „wylogowania”, a dane dotyczące czasu trwania sesji dla tego wpisu odpowiadają bieżącemu czasowi działania.

Więc na tej linii:

zrestartuj system boot 3.2.13-grsec-xxx Wt 3 kwietnia 07:34 - 09:17 (9 + 01: 42)

System został uruchomiony we wtorek, 3 kwietnia, o godzinie 7:34 i został zamknięty 9 dni i 1 godzinę i 42 minuty później (12 kwietnia), o godzinie 9:17 rano. (Lub, dane wyjściowe zostały zebrane w tym czasie i jest to najnowszy wpis restartu, a „restart” jeszcze nie „wylogował się”. W takim przypadku wynik zmieni się, jeśli ponownie uruchomisz ostatnie polecenie).

Dlaczego miałbyś 2 wpisy dla użytkownika restartującego, 3 kwietnia, oba trwające 9 dni, jest dla mnie tajemnicą; moje systemy tego nie robią.

streszczenie

• Pierwszym znacznikiem czasu wydaje się być czas, w którym system przestał działać podczas ponownego uruchamiania.
• Drugi znacznik czasu i upływający czas nie są zbyt przydatne.
• Przekazanie tej -xopcji lastmoże być przydatne do pokazania innych zdarzeń związanych z wyłączeniami i zmianami poziomu uruchamiania, które wpływają na znaczniki czasu wyświetlane w rebootwierszach. tuptimeNarzędzie wymieniona w innym odpowiedź może lepiej o tym, ale nie spojrzał na niego.

Detale

lastStrona człowiek na CentOS 6 i 7 mówi:

Ponowne uruchomienie pseudo użytkownika loguje się przy każdym ponownym uruchomieniu systemu.

Nie mówi nic o wylogowaniu użytkownika, a przedstawione poniżej dowody wydają się sugerować, że czas wylogowania nie jest wyraźnie rejestrowany. Strony rebooti shutdownzawierają bardziej szczegółowe informacje na temat rejestrowania zmian poziomu przebiegu, jeśli ktoś jest zainteresowany.

Z testów wynika, że ​​czas logowania się kończy od późnego procesu zamykania - nie od momentu wydania rebootpolecenia.

Dlatego wydaje się, że czasy wylogowania (drugi znacznik czasu) i czas, przez który zalogowano się „restart” (pokazane w nawiasach), powinny być prawdopodobnie zignorowane.

Jeśli przełączysz tę -Fopcję last, wyświetli Ci się pełna sygnatura czasowa, co sprawia, że ​​nieco bardziej jasne jest, że maszyna nie jest przypadkowo restartowana w tym samym czasie, po prostu pokazuje dokładnie ten sam znacznik czasu kilka razy. Ponadto, jeśli podasz -xflagę, wyświetli się „wpisy zamknięcia systemu i zmiany poziomu uruchamiania”.

Tutaj uruchomiłem go na CentOS 7, a także przeszedłem -Ropcję pomijania kolumny nazwa hosta / wersja jądra. Usunąłem też trochę nieciekawych loginów root:

# date ; last -x -F -R
Mon Nov 12 01:10:44 UTC 2018
root     pts/0        Mon Nov 12 00:02:57 2018   still logged in
runlevel (to lvl 3)   Sat Nov 10 17:57:29 2018 - Mon Nov 12 01:10:44 2018 (1+07:13)
reboot   system boot  Sat Nov 10 17:57:12 2018 - Mon Nov 12 01:10:44 2018 (1+07:13)
runlevel (to lvl 3)   Sat Oct 27 17:58:20 2018 - Sat Nov 10 17:57:29 2018 (13+23:59)
reboot   system boot  Sat Oct 27 17:58:03 2018 - Mon Nov 12 01:10:44 2018 (15+07:12)
runlevel (to lvl 3)   Sat Jul 21 18:14:55 2018 - Sat Oct 27 17:58:20 2018 (97+23:43)
reboot   system boot  Sat Jul 21 18:14:16 2018 - Mon Nov 12 01:10:44 2018 (113+06:56)
runlevel (to lvl 3)   Sun Nov 12 22:36:14 2017 - Sat Jul 21 18:14:55 2018 (250+19:38)
reboot   system boot  Sun Nov 12 22:35:35 2017 - Mon Nov 12 01:10:44 2018 (364+02:35)
root     pts/0        Fri Nov 10 07:13:20 2017 - crash                    (2+15:22)
runlevel (to lvl 3)   Sun Aug 27 04:15:56 2017 - Sun Nov 12 22:36:14 2017 (77+18:20)
reboot   system boot  Sun Aug 27 04:14:59 2017 - Mon Nov 12 01:10:44 2018 (441+20:55)
runlevel (to lvl 3)   Mon Aug 14 00:14:01 2017 - Sun Aug 27 04:15:56 2017 (13+04:01)
reboot   system boot  Mon Aug 14 00:13:46 2017 - Mon Nov 12 01:10:44 2018 (455+00:56)

Przede wszystkim 6 linii „restart” ma czas wylogowania równy bieżącemu czasowi.

shutdown system down  Fri Aug 11 08:05:29 2017 - Mon Aug 14 00:13:46 2017 (2+16:08)
root     pts/0        Fri Aug 11 08:05:23 2017 - down                      (00:00)
runlevel (to lvl 3)   Fri Jun 30 07:05:42 2017 - Fri Aug 11 08:05:29 2017 (42+00:59)
reboot   system boot  Fri Jun 30 07:05:27 2017 - Fri Aug 11 08:05:29 2017 (42+01:00)
[...]
root     pts/0        Fri Jun 30 05:48:16 2017 - crash                     (01:17)
root     pts/0        Tue Jun 27 04:59:56 2017 - Tue Jun 27 05:00:30 2017  (00:00)
root     pts/0        Mon Jun 26 11:20:57 2017 - Mon Jun 26 04:24:39 2017  (-6:-56)
runlevel (to lvl 3)   Mon Jun 26 11:15:13 2017 - Fri Jun 30 07:05:42 2017 (3+19:50)
reboot   system boot  Mon Jun 26 11:14:57 2017 - Fri Aug 11 08:05:29 2017 (45+20:50)
root     pts/0        Sun Jun 25 14:07:51 2017 - crash                     (21:07)
[...]
root     tty1         Thu Jun 22 13:07:42 2017 - crash                    (3+22:07)
runlevel (to lvl 3)   Thu Jun 22 13:07:07 2017 - Mon Jun 26 11:15:13 2017 (3+22:08)
reboot   system boot  Thu Jun 22 13:06:51 2017 - Fri Aug 11 08:05:29 2017 (49+18:58)
root     pts/0        Thu Jun 22 12:43:56 2017 - crash                     (00:22)
runlevel (to lvl 3)   Thu Jun 22 12:30:53 2017 - Thu Jun 22 13:07:07 2017  (00:36)
reboot   system boot  Thu Jun 22 12:30:38 2017 - Fri Aug 11 08:05:29 2017 (49+19:34)
root     pts/1        Thu Jun 22 12:26:49 2017 - crash                     (00:03)
root     pts/0        Thu Jun 22 11:55:28 2017 - crash                     (00:35)
runlevel (to lvl 3)   Thu Jun 22 11:49:53 2017 - Thu Jun 22 12:30:53 2017  (00:41)
reboot   system boot  Thu Jun 22 11:49:14 2017 - Fri Aug 11 08:05:29 2017 (49+20:16)

5 linii „restartu” przede wszystkim ma czas wylogowania równy czasowi „zamknięcia systemu”, który nastąpił po nich.

shutdown system down  Thu Jun 22 11:47:45 2017 - Thu Jun 22 11:49:14 2017  (00:01)
[...]
runlevel (to lvl 3)   Wed Jun 21 15:59:42 2017 - Thu Jun 22 11:47:45 2017  (19:48)
reboot   system boot  Wed Jun 21 15:59:27 2017 - Thu Jun 22 11:47:45 2017  (19:48)

Czas wylogowania „restart” ponownie odpowiada czasowi „zamykania systemu”.

shutdown system down  Wed Jun 21 15:57:58 2017 - Wed Jun 21 15:59:27 2017  (00:01)
root     pts/0        Wed Jun 21 14:27:43 2017 - down                      (01:30)
[...]
runlevel (to lvl 3)   Tue Jun 20 17:14:15 2017 - Wed Jun 21 15:57:58 2017  (22:43)
reboot   system boot  Tue Jun 20 17:14:00 2017 - Wed Jun 21 15:57:58 2017  (22:43)

Jak powyżej.

Zakładam na podstawie powyższych wyników, że nie jest rejestrowany jawny czas wylogowania dla pseudo-użytkownika „restart”, więc lastprzypisuje mu czas wylogowania z następnego „rozruchu systemu zamykającego” lub aktualny czas, jeśli nie ma „rozruchu systemu zamykającego” „śledzenie tego.

Pozycje „poziom pracy (do poziomu 3)” wydają się mieć bardziej rozsądny czas na wylogowanie, ale wydaje się, że nie uwzględnia awarii.

Z strony podręcznika ostatnie kolumny wydają się czasem rozpoczęcia sesji, godzinami zakończenia i czasem trwania sesji.

Szukałem, kiedy serwer został zrestartowany przez dostawcę serwera (zaplanowane zadanie załatania ostatnich luk w zabezpieczeniach procesora Meltdown i Spectre) i jaki był prawdziwy przestój operacji.

Korzystam z alternatywy dla „ostatniego restartu”, ponieważ wydaje mi się, że brakuje jej przejrzystości, jak już zauważyliście.

Wykonywanie tuptime -lWidzę następującą listę zachowania systemu:

...
Startup:  26  at  06:51:32 AM 11/06/2017
Uptime:   72 days, 20 hours, 5 minutes and 15 seconds
Shutdown: OK  at  02:56:47 AM 01/18/2018
Downtime: 18 minutes and 44 seconds

Startup:  27  at  03:15:31 AM 01/18/2018
Uptime:   5 days, 7 hours, 11 minutes and 32 seconds

Jest jasne, że shudown został wykonany po procedurze zamykania systemu o określonej godzinie i dacie „02:56:47 AM 01/18/2018”. Przestoje trwały „18 minut i 44 sekund”, a uruchomienie nastąpiło o „03:15:31 AM 01/18/2018” i nadal trwa.

Ostatnia dyspozycyjność linii, jak mówisz. Myślę, że ostatnie dwie kolumny czas ponownego uruchomienia i bieżący czas. Ponieważ kiedy uruchamiam ostatnie polecenie, druga kolumna od tyłu pokazuje aktualny czas i zawsze się zmienia.