Bedeutung der Spalten im Befehl "last"

Als ich nach einem Server gesucht habe, der regelmäßig neu gestartet wird, habe ich angefangen, das "letzte" Dienstprogramm zu durchsuchen. Das Problem ist jedoch, dass ich nicht finden kann, was die Spalten genau bedeuten. Ich habe natürlich den Mann durchgesehen, aber er enthält diese Informationen nicht.

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)   

Die ersten Spalten sind bis zu den enthaltenen Kernelversionen sinnvoll. Was bedeuten diese Zeiten genau? Die letzte scheint die Betriebszeit zu sein.

Zweitens sollte dies ein rund um die Uhr verfügbarer Server sein, außer dass die Zeiten nicht übereinstimmen, was bedeuten könnte, dass Ausfallzeiten oder ähnliches auftreten. Wenn wir uns beispielsweise die beiden letzten Zeilen ansehen, bedeutet dies, dass mein Server vom 2. April, 09:17 Uhr, bis zum 3. April, 02:31 Uhr, ausgeschaltet war?

Was die Hintergrundinformationen betrifft, so ist dies ein Debian Squeeze-Server.

BEARBEITEN

Wenn die letzten Spalten Startzeit, Stoppzeit und Betriebszeit sind, wie können Sie diese beiden Zeilen interpretieren:

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)   

Die zweite Sitzung scheint zu enden, nachdem die erste begonnen hat, was für mich keinen Sinn ergibt.

Ich schätze, dies ist ein drei Jahre alter Beitrag, aber ich werde trotzdem antworten, zum Nutzen aller anderen, die ihn in Zukunft haben, so wie ich es kürzlich getan habe.

Wenn Sie andere Beiträge lesen und die Ausgabe selbst über einen bestimmten Zeitraum überwachen, werden in jeder Zeile das Startdatum und die Uhrzeit der Sitzung, die Endzeit der Sitzung (jedoch nicht das Enddatum) und die Dauer der Sitzung aufgelistet (wie lange sie eingeloggt waren) in einem Format wie

(Tage + Stunden: Minuten)

Der Neustartbenutzer hat sich anscheinend bei jedem Systemstart angemeldet und bei jedem Neustart oder Herunterfahren des Systems ausgeschaltet. In diesen Zeilen ist die "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 Neustart-Eintrag die aktuelle Zeit als "Abgemeldet" -Zeit an und die Sitzungsdauer-Daten für diesen Eintrag stimmen mit der aktuellen Verfügbarkeitsausgabe überein.

Also in dieser Zeile:

Systemstart neu starten 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 morgens heruntergefahren. (Oder diese Ausgabe wurde zu diesem Zeitpunkt gesammelt, und dies ist der letzte Neustarteintrag, und "Neustart" ist noch nicht "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 machen das nicht.

Zusammenfassung

• Der erste Zeitstempel scheint der Zeitpunkt zu sein, zu dem das System während des Neustarts heruntergefahren ist.
• Der zweite Zeitstempel und die abgelaufene Zeit sind nicht sehr nützlich.
• Das Übergeben der -xOption an lastkann nützlich sein, um andere Ereignisse im Zusammenhang mit Abschaltungen und Änderungen der Ausführungsstufe anzuzeigen, die sich auf die in den rebootZeilen angezeigten Zeitstempel auswirken . Das tuptimeTool, auf das in einer anderen Antwort verwiesen wird, mag dies klarer machen, aber ich habe es nicht angeschaut.

Einzelheiten

In der lastManpage zu CentOS 6 und 7 heißt es:

Der Neustart des Pseudo-Benutzers wird bei jedem Neustart des Systems protokolliert.

Es sagt nichts darüber aus, wann sich der Benutzer abmeldet, und die unten gezeigten Beweise scheinen darauf hinzudeuten, dass keine Abmeldezeit explizit aufgezeichnet wurde. Die rebootund shutdownman - Seiten haben mehr Details über die Ausführungsebene Änderungen der Aufnahme , wenn jemand interessiert ist .

Aus dem Test geht hervor, dass die Anmeldezeit zu spät beim Herunterfahren liegt - nicht zu dem Zeitpunkt, zu dem der rebootBefehl ausgegeben wurde.

Daher sollten die Abmeldezeiten (der zweite Zeitstempel) und die Dauer, für die "Neustart" angemeldet war (in Klammern angegeben), wahrscheinlich ignoriert werden.

Wenn Sie die -FOption auf übergeben last, werden Ihnen vollständige Zeitstempel angezeigt, wodurch etwas klarer wird, dass der Computer nicht zufällig zur gleichen Zeit neu gestartet wird, sondern nur ein paar Mal denselben Zeitstempel. Wenn Sie das -xFlag übergeben, wird außerdem "System heruntergefahren und Ebenenänderungen ausgeführt" angezeigt.

Hier habe ich es unter CentOS 7 ausgeführt und die -ROption zum Unterdrücken der Spalte mit dem Hostnamen / der Kernelversion übergeben. 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)

Die 6 "Neustart" -Zeilen haben vor allem eine Abmeldezeit, die der aktuellen Zeit entspricht.

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)

Die 5 "Neustart" -Zeilen haben vor allem eine Abmeldezeit, die der Zeit des darauf folgenden "Herunterfahrens des Systems" 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 für "Neustart" entspricht der Zeit für "Herunterfahren des Systems".

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.

Aus den obigen Ergebnissen gehe ich davon aus, dass für den Pseudobenutzer "Neustart" keine explizite Abmeldezeit aufgezeichnet wird. lastWeisen Sie ihm daher eine Abmeldezeit für den nächsten "Herunterfahren des Systems" oder die aktuelle Zeit zu, wenn es keinen "Herunterfahren des Systems" gibt "danach.

Die "Runlevel (bis Stufe 3)" -Einträge scheinen eine vernünftigere Abmeldezeit zu haben, aber sie scheinen die Abstürze nicht zu berücksichtigen.

In der Manpage scheinen die letzten Spalten die Sitzungsstart-, -stoppzeiten und die Sitzungsdauer zu sein.

Ich habe nachgesehen, wann ein Server vom Serveranbieter neu gestartet wurde (eine geplante Aufgabe, um die jüngsten Meltdown- und Spectre-CPU-Schwachstellen zu beheben) und was die eigentliche Ausfallzeit des Vorgangs war.

Ich verwende eine Alternative zum "letzten Neustart", weil ich das Gefühl habe, dass es an Klarheit mangelt, wie Sie auch schon bemerken.

Beim Ausführen tuptime -lkann ich die folgende Liste des Systemverhaltens sehen:

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

In dem klar ist, dass das Shudown nach dem Herunterfahren des Systems zu der bestimmten Stunde und dem Datum "02:56:47 AM 01/18/2018" durchgeführt wurde. Die Ausfallzeit betrug "18 Minuten und 44 Sekunden" und der Start war am "03:15:31 01/18/2018" und läuft noch.

Die letzte Betriebszeit, wie Sie sagen. Neustartzeit der letzten beiden Spalten und aktuelle Uhrzeit, denke ich. Denn wenn ich den letzten Befehl ausführe, zeigt die zweite Spalte von hinten die aktuelle Zeit und ändert sich immer.