Ich schätze, dies ist ein drei Jahre alter Beitrag, aber ich werde trotzdem antworten, zum Wohle aller anderen, die in Zukunft darauf stoßen, so wie ich es kürzlich getan habe.
Wenn ich andere Beiträge lese und die Ausgabe über einen bestimmten Zeitraum selbst beobachte, sieht es so aus, als ob jede Zeile das Startdatum und die Uhrzeit der Sitzung, die Endzeit der Sitzung (aber nicht das Enddatum) und die Dauer der Sitzung auflistet (wie lange sie eingeloggt waren) in einem Format wie
(Tage+Stunden:Minuten)
Der Neustartbenutzer scheint sich bei jedem Systemstart angemeldet zu haben und beim Neustart oder Herunterfahren des Systems ausgeschaltet zu sein, und in diesen Zeilen ist die Information zur "Sitzungsdauer" die Zeitdauer (Tage + Stunden:Minuten). diese "Sitzung" dauerte, das heißt, wie lange das System aktiv war, bevor es heruntergefahren wurde.
Für mich zeigt der letzte Neustarteintrag die aktuelle Zeit als "abgemeldete" Zeit an, und die Sitzungsdauerdaten für diesen Eintrag stimmen mit der aktuellen Betriebszeitausgabe überein.
Also in dieser Zeile:
reboot system boot 3.2.13-grsec-xxx Di 3. April 07:34 - 09:17 (9+01:42)
Das System wurde am Dienstag, dem 3. April, um 7:34 Uhr gestartet und 9 Tage und 1 Stunde und 42 Minuten später (am 12. April) um 9:17 Uhr heruntergefahren. (Oder diese Ausgabe wurde zu diesem Zeitpunkt gesammelt, und dies ist der letzte Neustarteintrag, und „reboot“ hat sich noch nicht wirklich „abgemeldet“. In diesem Fall ändert sich die Ausgabe, wenn Sie den letzten Befehl erneut ausführen.)
Warum Sie am 3. April 2 Einträge für den Neustartbenutzer haben würden, die beide 9 Tage lang waren, ist mir ein Rätsel; meine Systeme tun das nicht.
Zusammenfassung
- Der erste Zeitstempel scheint die Zeit zu sein, zu der das System während des Neustarts heruntergefahren ist.
- Der zweite Zeitstempel und die verstrichene Zeit sind nicht sehr nützlich.
- Überschreiten des
-xOption zulastkann nützlich sein, um andere Ereignisse im Zusammenhang mit Herunterfahren und Änderungen der Ausführungsebene anzuzeigen, die die inrebootangezeigten Zeitstempel beeinflussen Linien. DietuptimeTool, auf das in einer anderen Antwort verwiesen wird, kann dies klarer machen, aber ich habe es mir nicht angesehen.
Einzelheiten
Die last man-Seite auf CentOS 6 und 7 sagt:
Der Pseudo-Benutzer-Neustart meldet sich bei jedem Neustart des Systems an.
Es sagt nichts darüber aus, wann sich der Benutzer abmeldet, und die unten gezeigten Beweise scheinen darauf hinzudeuten, dass keine Abmeldezeit explizit aufgezeichnet wird. Die reboot und shutdown man-Seiten enthalten weitere Einzelheiten zum Aufzeichnen der Runlevel-Änderungen, falls es jemanden interessiert.
Aus Tests geht hervor, dass die Anmeldezeit spät im Prozess des Herunterfahrens liegt – es ist nicht ab dem Zeitpunkt, an dem reboot Befehl wurde ausgegeben.
Daher scheint es, dass die Abmeldezeiten (der zweite Zeitstempel) und die Dauer, für die "reboot" angemeldet war (in Klammern angegeben), wahrscheinlich ignoriert werden sollten.
Wenn Sie die -F passieren Option auf last , zeigt es Ihnen vollständige Zeitstempel, was etwas klarer macht, dass die Maschine nicht zufällig zur gleichen Zeit neu gestartet wird, sondern nur ein paar Mal genau denselben Zeitstempel anzeigt. Auch, wenn Sie den -x bestehen -Flag, zeigt es "System-Shutdown-Einträge und Runlevel-Änderungen."
Hier habe ich es unter CentOS 7 ausgeführt und auch den -R bestanden Option zum Unterdrücken der Spalte Hostname/Kernel-Version. Ich habe auch einige uninteressante Root-Logins entfernt:
# 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)
Vor allem die 6 "reboot"-Zeilen haben eine Logout-Zeit gleich der aktuellen Uhrzeit.
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)
Vor allem die 5 "reboot"-Zeilen haben eine Abmeldezeit, die der Zeit des darauffolgenden "shutdown system down" entspricht.
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)
Die Abmeldezeit von "reboot" stimmt wieder mit der Zeit von "shutdown system down" überein.
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)
Wie oben.
Ich gehe aus den obigen Ergebnissen davon aus, dass für den Pseudo-Benutzer "reboot" keine explizite Abmeldezeit aufgezeichnet wird, also last weist ihm eine Abmeldezeit des nächsten "Systemstarts herunterfahren" oder die aktuelle Zeit zu, wenn darauf kein "Systemstart herunterfahren" folgt.
Die "Runlevel (to lvl 3)"-Einträge scheinen eine sinnvollere Abmeldezeit zu haben, aber sie scheint die Abstürze nicht zu berücksichtigen.