web-dev-qa-db-de.com

Wie finde ich das vorherige Boot-Protokoll nach einem Neustart von Ubuntu 16.04+?

Meine Frage ist, wie kann ich das Startprotokoll des vorherigen Systemstartversuchs finden?

Heute, als ich meinen PC zum ersten Mal einschaltete, stoppte der Startvorgang des Ubuntu-Logos, als ich drückte Esc Ich habe mehrere Zeilen mit einem Kernelfehler gesehen und unten einen Neustart angefordert, also habe ich gedrückt Ctrl+ALt+Del und der nächste Bootvorgang verlief ohne Probleme.

Ich habe Probleme beim Auffinden von Meldungen auf dem Bildschirm, die ich beim ersten erfolglosen Start gesehen habe. Hätte ich ein Foto auf mein Handy machen sollen?

/var/log/boot ist da, aber leer, ich suchte kern.log und syslog nach Zeichenfolgen, an die ich mich mit dem heutigen Datum wie error erinnerte, fand aber nichts Gewohntes Ich habe auf dem vorherigen Startbildschirm gesehen.

$ journalctl -b -1 gibt mir nur Kernelnachrichten während des Bootens, ich kann das auch anderswo finden, und sie sind nicht das, was während des Bootens auf dem Bildschirm angezeigt wurde, journalctl ist für mich nutzlos, ich suche nach Nachrichten, die während des Bootens auf dem Bildschirm angezeigt werden.

Derzeit besteht nur die Möglichkeit, ein Foto von der Nachricht auf Papier zu machen.

18
Mike

Als Fehler gemeldet, der nicht dokumentiert ist

Zu diesem Thema ist ein Fehlerbericht abgelegt. Da rsyslog bereits mehrere Boot-Journale in /var/log/syslog und syslog.1, .2.gz, .3.gz... syslog.7.gz verwaltet, hatten die Entwickler das Gefühl, zusätzliche journalctl -Protokolle würden Speicherplatz verschwenden.

Der Fehlerbericht besagt am 3. Januar 2018 , dass für Neuinstallationen rsyslog nicht mehr die Standardeinstellung ist und journalctl Behalten Sie mehrere Startdatenprotokolle bei.

Erstellen Sie mehrere Startprotokolle, ohne Ubuntu neu zu installieren

Die meisten von uns werden keine Neuinstallation durchführen, um mehrere journalctl Startprotokolle zu aktivieren. In diesem Fall können wir Folgendes verwenden:

$ Sudo mkdir -p /var/log/journal
$ Sudo systemd-tmpfiles --create --prefix /var/log/journal
Cannot set file attribute for '/var/log/journal', value=0x00800000, mask=0x00800000: Operation not supported

Entsprechend github report kann die Warnmeldung "Kann Dateiattribut nicht setzen" ignoriert werden.

Optionale dauerhafte Speichereinstellung

Nachdem ich die vorherige Startprotokollierung für viele Monate verwendet habe, habe ich eine andere Option entdeckt das kann in /etc/systemd/journald.conf eingestellt werden:

From journald.conf man page :

Lagerung =

Steuert, wo Journaldaten gespeichert werden. Einer von "volatile", "persistent", "auto" und "none". Wenn "flüchtig", werden Journalprotokolldaten nur im Speicher gespeichert, d. H. Unterhalb der Hierarchie/run/log/journal (die bei Bedarf erstellt wird). Wenn "persistent", werden Daten vorzugsweise auf der Festplatte gespeichert, dh unterhalb der /var/log/journal -Hierarchie (die bei Bedarf erstellt wird), mit einem Fallback auf /run/log/journal (die bei Bedarf erstellt wird) während des frühen Startvorgangs und wenn die Festplatte nicht beschreibbar ist. "auto" ähnelt "persistent", aber das Verzeichnis /var/log/journal wird bei Bedarf nicht erstellt, sodass seine Existenz steuert, wohin die Protokolldaten gehen. "none" deaktiviert den gesamten Speicher, alle empfangenen Protokolldaten werden gelöscht. Die Weiterleitung an andere Ziele wie die Konsole, den Kernel-Protokollpuffer oder einen Syslog-Socket funktioniert jedoch weiterhin. Der Standardwert ist "auto".

Kurz gesagt, entfernen Sie den Kommentar und ändern Sie die Zeile in:

Storage=persistent

Liste der vorherigen Starts anzeigen

$ journalctl --list-boots
-15 58a9e56135564cd8a52d547b19e76bf5 Fri 2018-02-02 18:34:35 MST—Fri 2018-02-02 23:07:14 M
-14 3514e056440341b1b6e5f03d109681bc Sat 2018-02-03 06:05:12 MST—Sat 2018-02-03 08:07:44 M
-13 0d1a32dc275348589f5ecdc72180c018 Sat 2018-02-03 08:08:05 MST—Sat 2018-02-03 08:08:34 M
-12 74159b593f3a401589ee6bd78e31684b Sat 2018-02-03 08:08:51 MST—Sun 2018-02-04 08:32:09 M
-11 4b394a9aad584ab2bfabe3b77eeed78f Sun 2018-02-04 08:32:26 MST—Mon 2018-02-05 16:54:02 M
-10 8e461ed2593c4fd896ca3b71eb3c0fba Mon 2018-02-05 16:54:34 MST—Tue 2018-02-06 03:54:30 M
 -9 ec7ba0e4dfe241c0b9c978d278fcca6d Tue 2018-02-06 03:54:47 MST—Tue 2018-02-06 16:25:02 M
 -8 b5c110267c214c38b63d0a367197d118 Tue 2018-02-06 16:25:19 MST—Thu 2018-02-08 16:49:03 M
 -7 75c3b117ac6a4de984dc3ced15edb7f8 Thu 2018-02-08 16:49:22 MST—Fri 2018-02-09 03:51:09 M
 -6 7338bd1007bc42dda5c8667eeefe1a59 Fri 2018-02-09 03:51:26 MST—Fri 2018-02-09 16:55:52 M
 -5 4b6cd0121327454ca3db035c7ed42df6 Fri 2018-02-09 16:56:09 MST—Sat 2018-02-10 07:55:14 M
 -4 0d56207f9ec0405ca3a3fd638334de2f Sat 2018-02-10 07:55:32 MST—Mon 2018-02-12 22:16:05 M
 -3 0f230cc546fd4aec8f5233e0074ab3e1 Tue 2018-02-13 03:57:20 MST—Wed 2018-02-14 22:58:56 M
 -2 c0d2c0141dd840cbab75d3c2254f8781 Wed 2018-02-14 22:59:13 MST—Sat 2018-02-17 22:46:14 M
 -1 aafb2573a6374e019a7165cb8eee74a0 Sun 2018-02-18 06:02:03 MST—Mon 2018-02-19 04:16:36 M
  0 8462f1969c6f4d61973e7e245014b846 Mon 2018-02-19 04:16:53 MST—Tue 2018-02-20 18:51:42 M

Zeigt das letzte Startprotokoll an

$ journalctl -b-1
-- Logs begin at Fri 2018-02-02 18:34:35 MST, end at Thu 2018-03-01 16:43:25 MST. --
Feb 28 20:03:15 alien systemd-journald[290]: Runtime journal (/run/log/journal/) is 8.0M, 
Feb 28 20:03:15 alien kernel: Linux version 4.14.23-041423-generic ([email protected]) (gcc 
Feb 28 20:03:15 alien kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.14.23-041423-generi
Feb 28 20:03:15 alien kernel: KERNEL supported cpus:
Feb 28 20:03:15 alien kernel:   Intel GenuineIntel
Feb 28 20:03:15 alien kernel:   AMD AuthenticAMD
Feb 28 20:03:15 alien kernel:   Centaur CentaurHauls
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registe
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
Feb 28 20:03:15 alien kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 b
Feb 28 20:03:15 alien kernel: e820: BIOS-provided physical RAM map:
Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usabl
lines 1-19

Achten Sie genau auf den Parameter -b-1, der sich von anderen möglicherweise angezeigten Referenzen unterscheidet. Von Manpage :

-b [ID][±offset], --boot=[ID][±offset]

Nachrichten von einem bestimmten Boot anzeigen. Dies fügt eine Übereinstimmung für "_BOOT_ID =" hinzu.

Das Argument kann leer sein. In diesem Fall werden Protokolle für den aktuellen Start angezeigt.

Wenn die Start-ID weggelassen wird, werden die Starts ab dem Beginn des Journals durch einen positiven Versatz und die Starts ab dem Ende des Journals durch einen Versatz kleiner oder gleich Null nachgeschlagen. Somit bedeutet 1 den ersten im Journal gefundenen Schuh in chronologischer Reihenfolge, 2 den zweiten und so weiter; Während -0 der letzte Start ist, -1 der vorletzte Start und so weiter. Ein leerer Offset entspricht der Angabe von -0, es sei denn, der aktuelle Start ist nicht der letzte Start (z. B. weil --directory angegeben wurde, um Protokolle von einem anderen Computer anzuzeigen).

Dann ab und zu mit cron oder Timer können Sie alte Protokolle säubern:

journalctl --vacuum-time=2d  # keep last two days or

journalctl --vacuum-size=300M  # keep last 300MB
13

Ich hatte das gleiche Problem und fand anscheinend die Antwort auf dem #ubuntu irc-Kanal.

Aus irgendeinem Grund fehlte mir der Ordner /var/log/journal, auf den systemd-journal Zugriff hat.

Nach dem Hinzufügen des Ordners konnte ich Protokolle früherer Startvorgänge über $ journalctl -b1 anzeigen.

9
dba

Die Schritte zur Lösung finden Sie in der oberen Antwort auf der Manpage für systemd-journald:

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

Ich habe das als su gemacht

3
Aaron Skomra

Die Antwort finden Sie in man journald.conf, speziell in der Option Storage=:

Steuert, wo Journaldaten gespeichert werden. Einer von "volatile", "persistent", "auto" und "none". [...] "auto" ähnelt "persistent", aber das Verzeichnis/var/log/journal wird bei Bedarf nicht erstellt, sodass seine Existenz kontrolliert, wohin die Protokolldaten gehen. [...] Standardmäßig "auto".

Bitte beachten Sie, dass keine Protokollrotation oder ähnliche Techniken erforderlich sind, die mit dem alten Syslog-Dämon üblich waren. Die Journaldatei ist standardmäßig so konfiguriert, dass sie bis zu einer bestimmten Größe wächst, und alte Protokolleinträge werden automatisch gelöscht, wenn die Journaldatei zu groß wird.

Auf meinem System ist diese Größe derzeit mit 120 MB konfiguriert. Sie können sie in /etc/systemd/journald.conf für die Serviceeinheit systemd-journald.service anpassen.

3
lanoxx

Verwenden Sie journalctl -bX, wobei x der Boot ist, auf den Sie sich beziehen, also -b0 Ihr tatsächlicher Boot und -b-1 der Boot zuvor (was nur funktioniert, wenn Sie den Ordner /var/log/journal haben, der zu gehört Gruppe 'systemd-journal' vorhanden). Ich kann dir nicht sagen, wie weit genau du gehen kannst, aber die beiden sind sicher.

Liste verfügbar Stiefel mit

journalctl --list-boots
3
Videonauth