Jessie: journalctl spinnt

[ingo2]

Hatte gestern mal wieder einen 90s Timeout beim Shutdown und wollte das mal im Log ansehen. Gebe also ein:

Code: Alles auswählen

journalctl -b -1

Und was gibt der aus: das Log vom 10. April
Mit "-b -0" kommt korrekterweise der aktuelle Bootvorgang

Ist die Journal-Funktion auch bei weiteren Usern "broken"?

Gruß
Ingo

[catdog2]

Schau mal unter /var/log nach, Debian Jessie leitet alles an rsyslog weiter und hält das journal nur im RAM. Wenn du ein persistentes journal haben willst musst du ein Verzeichnis /var/log/journal anlegen und vmtl. systemd-journald neu starten (rsyslog kann man dann entfernen, ausser man hat die logs gern doppelt).

[ingo2]

Unter /var/log sieht das vollständig aus:

Code: Alles auswählen

$ ls -l /var/log | grep syslog
-rw-r-----  1 root        adm                 1176 Apr 23 11:17 syslog
-rw-r-----  1 root        adm               227389 Apr 23 11:12 syslog.1
-rw-r-----  1 root        adm                44969 Apr 22 11:44 syslog.2.gz
-rw-r-----  1 root        adm                45461 Apr 21 11:25 syslog.3.gz
-rw-r-----  1 root        adm                45020 Apr 20 11:42 syslog.4.gz
-rw-r-----  1 root        adm                23203 Apr 19 10:46 syslog.5.gz
-rw-r-----  1 root        adm                45708 Apr 18 12:25 syslog.6.gz
-rw-r-----  1 root        adm                67559 Apr 17 12:22 syslog.7.gz

und auch die sevices:

Code: Alles auswählen

$ ls -l /var/log | grep daemon
-rw-r-----  1 root        adm               263849 Apr 23 11:12 daemon.log
-rw-r-----  1 root        adm               384732 Apr 17 12:22 daemon.log.1
-rw-r-----  1 root        adm                27143 Apr 10 11:31 daemon.log.2.gz
-rw-r-----  1 root        adm                33259 Apr  4 11:35 daemon.log.3.gz
-rw-r-----  1 root        adm                23086 Mär 27 13:43 daemon.log.4.gz

D.h.: vorhanden sind die Logs offenbar und der Inhalt für die Zeit vom 10.4. bis heute ist vollständig?

Ingo

[rendegast]

Ich hatte eine Diskrepanz zwischen
journalctl --list-boots
journalctl | grep "\-\- Reboot"

Lag an kaputten journals in /var/log/journal/, als root

Code: Alles auswählen

journalctl --verify

Bei mir waren es glücklicherweise nur "unbedeutetende",
zBsp. UID 65534/nobody.

Nach Entfernen (Löschen/Umbennen/Verschieben) war alles wieder gut.
EDIT nur der beanstandeten 'FAIL' Dateien.




-------------------
Bleibt die Frage, was man noch mit diesen Resten machen kann?

[ingo2]

Jepp, das scheint bei mir auch der Fall zu sein:

Code: Alles auswählen

# journalctl --list-boots
-72 ec25fa2f24324742b82d1a9478446b23 Mo 2015-08-10 09:34:43 CEST—Mo 2015-08-10 23:11:26 CEST
-71 0a414282ae1f4a0cb33280b6143b99f4 Di 2015-08-11 12:35:09 CEST—Di 2015-08-11 18:07:43 CEST
....
 -5 9fc2c1ba1e0048e9847d3ea8683a8c22 Fr 2016-04-08 20:10:00 CEST—Fr 2016-04-08 23:14:37 CEST
 -4 96bbd4a085064cfc8d53c32485a7f0e9 Sa 2016-04-09 12:24:43 CEST—Sa 2016-04-09 19:54:43 CEST
 -3 55f6be4af6294f90befcbd63849d1b0e Sa 2016-04-09 21:27:38 CEST—Sa 2016-04-09 23:18:09 CEST
 -2 98171eb1cd294143b9ce82d8f5bc3d0f So 2016-04-10 11:26:23 CEST—So 2016-04-10 12:06:16 CEST
 -1 a8d73c4520614194adb04ce7d6f84dbe So 2016-04-10 16:34:17 CEST—So 2016-04-10 23:36:09 CEST
  0 27faebb2b276497cb86929c83ace34cd Mo 2016-04-11 11:25:39 CEST—Mo 2016-04-11 11:40:34 CEST

hat alle Info.

Code: Alles auswählen

journalctl | grep "\-\- Reboot"
-- Reboot --
-- Reboot --
....

spuckt unzählige solcher Zeilen aus.

Code: Alles auswählen

# journalctl --verify
PASS: /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/system@8d99b15c60d44889b13e2cd7ef56f0e3-00000000000de2a0-00052dc438679bd3.journal
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░   0%
File corruption detected at /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/user-1000@9c26fece3908437dbc2249fe96abbf2b-00000000000bacac-00052b5d4550c55a.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/user-1000@9c26fece3908437dbc2249fe96abbf2b-00000000000bacac-00052b5d4550c55a.journal (Ungültige Nachricht)
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░   0%
File corruption detected at /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/user-1000@9c26fece3908437dbc2249fe96abbf2b-0000000000000244-0004c83c59696117.journal:000000 (of 147456 bytes, 0%).
FAIL: /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/user-1000@9c26fece3908437dbc2249fe96abbf2b-0000000000000244-0004c83c59696117.journal (Ungültige Nachricht)
PASS: /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/user-1000.journal
....
PASS: /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/system@9c26fece3908437dbc2249fe96abbf2b-0000000000051beb-00051f6123ff747c.journal
PASS: /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/system@9c26fece3908437dbc2249fe96abbf2b-000000000007a9be-0005242cf2d6dbd0.journal
PASS: /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/system@9c26fece3908437dbc2249fe96abbf2b-000000000002c56a-00051a96602cb815.journal
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░   0%
File corruption detected at /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/user-1000@9c26fece3908437dbc2249fe96abbf2b-00000000000de295-00052dc4386380da.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/user-1000@9c26fece3908437dbc2249fe96abbf2b-00000000000de295-00052dc4386380da.journal (Ungültige Nachricht)

ist voll von "Invalid Timestamps".

Habe mal auch jetzt alle Files in /var/log/journal/9ae107f8ca4d8c4a36923f76502d0ecc/ gelöscht und werde rebooten - melde mich wieder.

Jetzt klappt es wieder, aber die Ursache zu finden .... ist wohl umöglich.
Dafür gibt's ja noch good old rsyslog

[rendegast]

Hatte oben noch ein EDIT gemacht

Nach Entfernen (Löschen/Umbennen/Verschieben) war alles wieder gut.
EDIT nur der beanstandeten 'FAIL' Dateien.

Sowas soll ja nach den Versprechungen nicht sein.
Sind die Dinger inhaltslos, oder verliere ich eventuell wichtige Information?
Das wohl nicht, die FAIL-Dateien separiert lassen sich lesen

Code: Alles auswählen

# journalctl -D .FAIL_all/ | wc -l
1290
# journalctl -D .FAIL_1000/ | wc -l
171
# journalctl -D .FAIL_1001/ | wc -l
914
# journalctl -D .FAIL_65534/ | wc -l
210

Die Summierung stimmt annähernd,
wir wollen keine Korinthenkacker sein.


In der Standardeinstellung journal nur auf /run/-tmpfs
taucht das Problem eleganterweise gar nicht auf.

Und das war bei / resp. /var/log/ auf einem ext4,
wie wäre es beim CoW btrfs?




EDIT typo

[ingo2]

Nach dieser Aktion hatte ich auch prompt wieder gleich einen Hänger beim Shutdown - dachte eigentlich, das wäre mit dem NFS-Würgeround (s. hier: viewtopic.php?f=15&t=158291&start=225#p1082753) erledigt.

Ok, ich nehme das jetzt auch mal so hin und hoffe, daß solche Kinderkrankheiten von systemd mit Stretch endgültig der Vergangenheit angehören.

Ingo

[ingo2]

Erinnert mich stark an das Kapitel 13 zu NFS im "Unix-Haters Handbook" ( web.mit.edu/~simsong/www/ugh.pdf )

13 The File System ..............................................................261
Sure It Corrupts Your Files,
But Look How Fast It Is!

Aber mit Unix(philosophie) hat systemd ja nichts mehr am Hut
Ingo