Abrufen von Datum und Uhrzeit des Systemstarts unter Linux


44

Ich weiß, dass uptimedie Zeit gedruckt wird, zu der eine Maschine in Betrieb war, aber gibt es einen einfacheren (zuverlässigen) Weg, um das Datum des Starts zu ermitteln, als von dieser Ausgabe herunterzuzählen?

Ich habe versucht, mich umzusehen /proc, aber nichts Relevantes gefunden. Es gibt auch eine Zeile wie diese auf meinem dmesg:

[    0.673492] rtc_cmos rtc_cmos: setting system clock to 2011-03-14 14:26:52 UTC (1300112812)

Aber ich frage mich, ob diese Methode Distributions- und Kernelversion-unabhängig ist?


unreliable or hardUm was geht es uptime?
Bobby

2
@Bobby: Nichts über den Befehl oder seine Funktion per se, aber wie gesagt, ich möchte das Datum und die Uhrzeit des letzten Systemstarts abrufen, nicht wie lange es schon her ist. uptimeGibt einen String wie "up 13 days, 21:01" zurück, und Sie müssen ihn danach zählen.
jho

4
Es ist trivial, vom Betriebszeitwert zurück zu zählen. Wenn Sie zuverlässig wollen , wollen Sie /proc/uptime.
Sam Hocevar

Antworten:


40

Ich habe hier einige Befehle gefunden . Versuchen Sie who -boder last reboot | head -1.
whogibt numerische Daten an, während last rebootabgekürzte Tag- / Monatsnamen zurückgegeben werden.


wie wäre es, wenn wir nur das Datum und nichts anderes wollen?
T0xicCode

4
who -b | cut -d' ' -f13gibt nur das Datum zurück (-f14 gibt die Zeit zurück)
charlesbridge

2
Achtung: last reboothabe nicht das richtige Datum angegeben! who -btat.
Qwertzguy

last rebootgab mir auch ein falsches datum, wtmp schien am ersten tag des
monats

23

Dies fragt die Betriebszeit vom Kernel ab und zeigt sie in der lokalen Zeitzone an:

date -d "`cut -f1 -d. /proc/uptime` seconds ago"

Seien Sie vorsichtig mit anderen Optionen. Der lastBefehl funktioniert nicht mehr, sobald wtmper gedreht wurde. Der whoBefehl hängt von der Verfügbarkeit und Integrität von ab utmp. Und hat /proc/1möglicherweise das aktuelle Datum anstelle des Startzeitdatums und ist auf einem gehärteten System möglicherweise sogar nicht verfügbar. Bearbeiten : dmesgHat nur einen Backbuffer mit fester Länge, ist also auch nicht realisierbar. Die Kernel-Protokolle befinden sich möglicherweise in, /var/logaber die meisten Distributionen behalten nur 8 Wochen davon bei.


1
Interessanterweise stimmt dies nicht mit who -bein oder zwei Minuten bei meinem 210-Tage-System überein . Sieht so aus who -b, als würde ein Zeitstempel gemeldet, während diese Zählung in gewisser Weise von Zeitverschiebungen beeinflusst wird, auch wenn diese regelmäßig durch einen Lauf korrigiert werden ntpd.
Ruslan

3
Nachdem alle alternativen Antworten überprüft wurden, wurde festgelegt am: date -d "`cut -f1 -d. /proc/uptime` seconds ago" -u(mit Uhrzeit / Datum in UTC)
david6

Phänomenale Antwort. Wenn der Kernel es nicht weiß, weiß es niemand - es ist die Quelle der Wahrheit für das System. Die Sekunden erleichtern das Durchführen von Zeitberechnungen (Ich bin darauf gestoßen, weil ich wissen möchte, "Welcher meiner Hosts hat nicht innerhalb des letzten Tages [86,400 Sekunden] neu gestartet?")
Mike S

17

Ich stolperte über diese Frage , während nach einer Möglichkeit, eine konsistente, parseable zu erhalten Boot - Zeit , im Gegensatz zu , da Boot - Zeit , die bei jedem Aufruf ändert.

Es sieht so aus, uptime -sals würde dies auf den meisten Linux-Systemen funktionieren.


uptime -sAusgänge zB 2017-08-09 01:23:45. Das ist am besten, indem man am einfachsten ist. Dieser Befehl ist im Paket "procps" enthalten.
Teika Kazura

Das uptimein CentOS 6 ( procps version 3.2.8) scheint dies leider nicht zu unterstützen.
Mwfearnley

uptime -snicht immer konstant Ergebnisse zurück: superuser.com/q/1247713/71144
cweiske

1
Beachten Sie, dass dies immer in der Ortszeit ist , die Zeitzone / der Versatz jedoch nicht gedruckt werden. Wenn Sie dies also programmgesteuert von Computern abrufen möchten, ist dies nicht ideal, da Sie die Zeitzone je nach Anwendungsfall möglicherweise separat bestimmen müssen. Also, ich würde einige der anderen Antworten vorschlagen.
JJC

11

Ich habe die btimeZeile /proc/statbeim Stöbern gefunden

cat /proc/stat | grep btime | awk '{ print $2 }'

und nach einer kurzen Suche fand ich diese Seite: / proc / stat explicit , auf der die "verschiedenen Informationen zur Kernelaktivität, die in der /proc/statDatei verfügbar sind " aufgeführt sind.

Die Zeile "btime" gibt die Zeit in Sekunden seit der Unix-Epoche an, zu der das System gestartet wurde.


1
Scheint viel einfacher zu schreibenawk '/btime/{print $2}' /proc/stat
William Pursell

@WilliamPursell am einfachsten ist immer was du schon kennst. Ich bin kein awk Zauberer. : P
Oddstr13

Guter Punkt. Sie haben die Katze jedoch unentgeltlich benutzt. Grep einfach aus der Datei.
Mike S

@MikeS richtig - ich stehe jedoch immer noch zu meiner ursprünglichen Befehlskette als eindeutige Darstellung, wo sich die Informationen befinden, auch 7 Jahre nach meiner Antwort.
Oddstr13

8
  • gut : uptime -s, who -boder Parsing/proc/uptime
  • schlecht : ls -ld /proc/1und Varianten.

Verwenden Sie für diesen Zweck nicht ls -ld / proc / 1. Es wird manchmal nach s2disk oder s2ram aktualisiert .

In meinem Fall who -bsagte:

Systemstart 2. Mai 09:51

Während ls -ld /proc/1:

dr-xr-xr-x 7 root root 0 3. Mai 13:09 / proc / 1

ls -ldfür /procoder /sysscheinen nach der Wiederaufnahme fortzufahren, aber es hängt von der Implementierung ab und kann sich in Zukunft ändern. Wenden Sie daher solche Methoden nicht an. Und wenn Ihre Systemuhr nicht UTC , sondern Ortszeit ist , haben sie einen negativen Versatz.

(Ich habe noch keine Berechtigung zum Kommentieren von Antworten. Deshalb habe ich eine neue Antwort geöffnet. Entschuldigung.)

EDIT: uptime -swurde in dieser Antwort zuerst von mikegreiling beantwortet


2

Am einfachsten ist es, nachzusehen, wann / sbin / init gestartet wurde (dies ist immer der erste Prozess, der nach dem Laden des Kernels gestartet wird):

# ls -ld /proc/1
dr-xr-xr-x 7 root root 0 2011-03-27 23:54 /proc/1

So kann ich sehen, dass meine Maschine am 27. März 2011 um 6 Minuten vor Mitternacht hochgefahren wurde.

Wenn Sie es in Skripten verwenden möchten, können Sie statstattdessen den folgenden Befehl verwenden:

# stat --printf='%Y' /proc/1
1301266491

Das %Ygibt die Zeit seit der letzten Änderung des Verzeichnisses (Prozesserstellungszeit) in Sekunden seit der Epoche (1.1./70) an und ist ein Standard-Unix-Zeitstempel.


1
Leider funktioniert dies nicht: Die Uhrzeit in diesen Ordnern kann sich aus anderen Gründen ändern (ich habe hier ein System mit einer Betriebszeit von 5 Tagen und der Uhrzeit von / proc / 1 liegt vor 25 Minuten)
kdt

1
Es ist nicht zuverlässig , wie in meiner Antwort erklärt
Teika Kazura

1

Unter Linux

ls -ld /proc

scheint mir zu geben was ich brauche. Der obige Beitrag ist ungerade. /proc/uptimeenthält keinen Datumswert - er müsste von der aktuellen Uhrzeit abgezogen werden. Vielleicht meinte er:

date -d @$(( $(date +%s) - $(cut -f1 -d. /proc/uptime) ))

uptime -sliefert einen Datumswert
Mikegreiling

1

Unter Bash, ohne Pfeifen oder andere Prozesse; nur text:

$ REPLY="$(</proc/uptime)"
$ REPLY="${REPLY%%.*}"
$ echo "$REPLY"
31207

(Nur die REPLYStandardvariable wiederverwenden , aber Sie können wählen, was Sie brauchen.)


Sicher warum nicht? Ein bisschen kluger Gebrauch von variabler Substringiness. Cool. +1. Danke für die Idee!
Mike S

1

Dies scheint robust zu sein und wird Ihnen im UTC- und ISO8601-Format angezeigt. (Entfernen Sie die letzten beiden Optionen, um sie jeweils zu deaktivieren.)

date -d "`cut -f1 -d. /proc/uptime` seconds ago" -u -Iseconds

0
date -d @$(sed -n '/^btime /s///p' /proc/stat)

(Ein weiterer Weg, dies zu tun, der unter bestimmten Umständen nützlich ist.)


0

Befehl:

(echo ' Currently:' | tr "\n" ' ' ; date +"%Y-%m-%d %k:%M:%S" ; echo '  Up Since:' | tr '\n' ' ' ; uptime -s ; echo '  Duration:' | tr '\n' ' ' ; uptime -p)

Ausgabe:

 Currently: 2016-05-09  9:06:29
  Up Since: 2016-05-04 12:56:04
  Duration: up 4 days, 20 hours, 10 minutes

0

Klar und prägnant mit dem Befehl tuptime :

# tuptime -t
No.             Startup Date                                          Uptime            Shutdown Date   End                    Downtime

1     09:43:39 AM 08/08/2017      41 days, 0 hours, 51 minutes and 2 seconds   10:34:41 AM 09/18/2017    OK                  10 seconds
2     10:34:51 AM 09/18/2017                         1 minute and 16 seconds   10:36:07 AM 09/18/2017    OK                    1 second
3     10:36:08 AM 09/18/2017                       13 minutes and 20 seconds   10:49:28 AM 09/18/2017    OK                   3 seconds
4     10:49:31 AM 09/18/2017       45 days, 0 hours, 1 minute and 20 seconds   09:50:51 AM 11/02/2017    OK                   4 seconds
5     09:50:55 AM 11/02/2017                       27 minutes and 25 seconds   10:18:20 AM 11/02/2017    OK                   4 seconds
6     10:18:24 AM 11/02/2017                                       9 seconds   10:18:33 AM 11/02/2017    OK                   9 seconds
7     10:18:42 AM 11/02/2017      4 days, 5 hours, 41 minutes and 47 seconds   04:00:29 PM 11/06/2017    OK                  44 seconds
8     04:01:13 PM 11/06/2017    15 days, 17 hours, 33 minutes and 48 seconds   09:35:01 AM 11/22/2017   BAD   10 minutes and 40 seconds
9     09:45:41 AM 11/22/2017               8 hours, 9 minutes and 20 seconds   05:55:01 PM 11/22/2017   BAD     7 minutes and 8 seconds
10    06:02:09 PM 11/22/2017                1 hour, 7 minutes and 54 seconds   07:10:03 PM 11/22/2017   BAD   11 minutes and 30 seconds
11    07:21:33 PM 11/22/2017               1 hour, 58 minutes and 32 seconds   09:20:05 PM 11/22/2017    OK                   5 seconds
12    09:20:10 PM 11/22/2017                       14 minutes and 52 seconds   09:35:02 PM 11/22/2017   BAD    5 minutes and 52 seconds
13    09:40:54 PM 11/22/2017                         4 minutes and 6 seconds   09:45:00 PM 11/22/2017   BAD    4 minutes and 51 seconds
14    09:49:51 PM 11/22/2017             11 hours, 15 minutes and 10 seconds   09:05:01 AM 11/23/2017   BAD    7 minutes and 20 seconds
15    09:12:21 AM 11/23/2017      3 days, 2 hours, 17 minutes and 40 seconds   11:30:01 AM 11/26/2017   BAD   27 minutes and 44 seconds
16    11:57:45 AM 11/26/2017   109 days, 19 hours, 12 minutes and 37 seconds   07:10:22 AM 03/16/2018    OK                  17 seconds
17    07:10:39 AM 03/16/2018     25 days, 3 hours, 55 minutes and 59 seconds   12:06:38 PM 04/10/2018    OK                   3 seconds
18    12:06:41 PM 04/10/2018      8 days, 19 hours, 3 minutes and 20 seconds   07:10:01 AM 04/19/2018   BAD    3 minutes and 52 seconds
19    07:13:53 AM 04/19/2018     77 days, 9 hours, 44 minutes and 39 seconds
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.