[gelöst] Logs unter systemd auswerten

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
Benutzeravatar
mindX
Beiträge: 1541
Registriert: 27.03.2009 19:17:28
Lizenz eigener Beiträge: GNU General Public License

[gelöst] Logs unter systemd auswerten

Beitrag von mindX » 20.11.2014 15:02:35

Hallo,

ich blicke bei meinen Logs nicht mehr durch.

Code: Alles auswählen

$ dpkg -l | grep systemd
ii  libpam-systemd:amd64                  215-5+b1 amd64 system and service manager - PAM module
ii  libsystemd-login0:amd64               215-5+b1 amd64 systemd login utility library (deprecated)
ii  libsystemd0:amd64                     215-5+b1 amd64 systemd utility library
ii  systemd                               215-5+b1 amd64 system and service manager
ii  systemd-sysv                          215-5+b1 amd64 system and service manager - SysV links
ii  systemd-ui                            3-2 amd64 graphical frontend for systemd

Code: Alles auswählen

$ dpkg -l | grep syslog
ii  rsyslog                               8.4.2-1 amd64 reliable system and kernel logging daemon
Die Logs mit Änderungsdatum heute:

Code: Alles auswählen

:/var/log$ ls -lt
insgesamt 5132
-rw-r-----  1 root        adm              441496 Nov 20 14:48 daemon.log
-rw-r-----  1 root        adm             1583847 Nov 20 14:48 syslog
-rw-r-----  1 root        adm              285813 Nov 20 14:45 auth.log
-rw-rw-r--  1 root        utmp             235008 Nov 20 14:40 wtmp
-rw-r-----  1 root        adm              853864 Nov 20 14:00 messages
-rw-r-----  1 root        adm               67392 Nov 20 14:00 user.log
-rw-r--r--  1 root        root              35223 Nov 20 13:19 Xorg.0.log
-rw-r-----  1 root        adm              992647 Nov 20 13:18 kern.log
drwx--x--x  2 root        root               4096 Nov 20 13:18 lightdm
-rw-r-----  1 root        adm              195897 Nov 20 13:18 debug

Code: Alles auswählen

:/var/log/journal/883c845103e7ce3858634a6352a62ae6$ ls -lt
insgesamt 24580
-rw-r-----+ 1 root systemd-journal 16777216 Nov 20 14:50 system.journal
-rw-r-----+ 1 root systemd-journal  8388608 Nov 20 14:03 user-1000.journal

Code: Alles auswählen

journalctl
spuckt nur Sachen aus, mit denen ich nichts anfangen kann. Außerdem hat es ca. 400 Zeilen. Die Dateigrößen von system.journal und von user-1000.journal von 16 bzw. 8 MB haben mich auf mehr Informationen hoffen lassen.

Da die Abstimmung zu systemd gegessen ist und man sich wohl oder übel ins Thema einarbeiten muss, würde mich interessieren, wie die "best practice" zum Umgang mit dem neuen Logging aussieht.
Irgendwo hab ich aufgeschnappt, man könnte die Logs komplett an rsyslog durchleiten. Falls das stimmt, wie? Oder rsyslog runterwerfen? Bekommt man dann über journalctl aussagekräftige Infos wie über dmesg?

Wie dem auch sei - ich steh im Wald und bin für jeden Tipp dankbar. :)
Zuletzt geändert von mindX am 21.11.2014 12:29:24, insgesamt 1-mal geändert.

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

Re: Logs unter systemd auswerten

Beitrag von catdog2 » 20.11.2014 15:38:03

:/var/log/journal/883c845103e7ce3858634a6352a62ae6$ ls -lt
Ich finde interessant, dass du ein /var/log/journal hast. In einem vor einigen Wochen installierten jessie hatte ich das nicht oder hast du das selbst angelegt?
spuckt nur Sachen aus, mit denen ich nichts anfangen kann. Außerdem hat es ca. 400 Zeilen. Die Dateigrößen von system.journal und von user-1000.journal von 16 bzw. 8 MB haben mich auf mehr Informationen hoffen lassen.
Glaub das zeigt nur das seit dem letzen boot an, mach mal journalctl --list-boots und dann journalctl -b -1 usw.
Es gibt zahlreiche Filtermöglichkeiten ansonsten, einfach mal die manpage und http://0pointer.de/blog/projects/journalctl.html konsultieren.
Irgendwo hab ich aufgeschnappt, man könnte die Logs komplett an rsyslog durchleiten. Falls das stimmt, wie? Oder rsyslog runterwerfen?
Wenn sich nix geändert kürzlich passiert das eh. rsyslog kann man natürlich auch runter werfen und nur das journal nehmen.
Bekommt man dann über journalctl aussagekräftige Infos wie über dmesg?
dmesg wird natürlich auch erfasst. journalctl -k
Unix is user-friendly; it's just picky about who its friends are.

JuergenPB

Re: Logs unter systemd auswerten

Beitrag von JuergenPB » 20.11.2014 15:46:38

Soweit ich das bisher verstanden haben kann man journald mit der Datei

Code: Alles auswählen

/etc/systemd/journald.conf
konfigurieren. Genaues dazu in der manpage zu journald.conf

Code: Alles auswählen

NAME
       journald.conf - Journal service configuration file

SYNOPSIS
       /etc/systemd/journald.conf

DESCRIPTION
       This file configures various parameters of the systemd journal service,
       systemd-journald.service(8).

OPTIONS
       All options are configured in the "[Journal]" section:
…
…

JTH
Moderator
Beiträge: 3082
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: Logs unter systemd auswerten

Beitrag von JTH » 20.11.2014 15:47:33

Hey,
mindX hat geschrieben: Irgendwo hab ich aufgeschnappt, man könnte die Logs komplett an rsyslog durchleiten. Falls das stimmt, wie?
das passiert aktuell immer, solange ein Syslog-Daemon installiert ist. Es gibt dafür in /etc/systemd/journald.conf die Option ForwardToSyslog, die standardmäßig auf Yes steht (siehe man journald.conf).
mindX hat geschrieben: Bekommt man dann über journalctl aussagekräftige Infos wie über dmesg?
Über journalctl bekommst du eigentliche alles, was geloggt wird. Man sollte aber ein bisschen filtern oder die Ausgabe anders beschränken.

Für die gleiche Ausgabe wie von dmesg (das du aber auch einfach weiter benutzen kannst) gibt es eine extra Option:
man journalctl hat geschrieben: -k, --dmesg
Show only kernel messages. This implies -b and adds the match "_TRANSPORT=kernel".
Andere hilfreiche Filteroptionen sind z.B. -b zum Beschränken auf Meldungen seit dem letzten (oder auch weiter zurückliegenden) Boot (normalerweise sieht man alle noch vorhandenen Meldungen), -u für Meldungen eines bestimmten Services (z.B. # journalctl -u ssh) oder -f als Äquivalent zu tail -f /var/log/sowieso. Im ArchWIki gibt es eine kurze Übersicht.

Du solltest vielleicht noch darauf achten, dass journalctl dir als normalem Benutzer keine systemweiten Logs anzeigt, wenn du nicht in der Gruppe systemd-journal bist:
man journalctl hat geschrieben: All users are granted access to their private per-user journals. However, by default, only root
and users who are members of the "systemd-journal" group get access to the system journal and
the journals of other users.
Manchmal bekannt als Just (another) Terminal Hacker.

Benutzeravatar
habakug
Moderator
Beiträge: 4314
Registriert: 23.10.2004 13:08:41
Lizenz eigener Beiträge: MIT Lizenz

Re: Logs unter systemd auswerten

Beitrag von habakug » 20.11.2014 16:00:46

Hallo!
Ich finde interessant, dass du ein /var/log/journal hast. In einem vor einigen Wochen installierten jessie hatte ich das nicht oder hast du das selbst angelegt?
Vielleicht nicht, denn das Verhalten wird durch den Eintrag für "Storage=" gesteuert. Aus der Manpage (in etwa):
Storage=
Legt fest wo die Journal-Dateien gespeichert werden. Zur Auswahl stehen "volatile", "persistent", "auto" und "none". "volatile" speichert die Log-Dateien im Arbeitsspeicher, z.B. unter "/run/log/journal" (welches bei Bedarf erzeugt wird). "persistent" speichert die Log-Dateien auf Festplatte/Massenspeicher, z.B unter "/var/log/journal" (welches bei Bedarf erzeugt wird) mit Ausweichen auf "/run/log/journal" (im Arbeitsspeicher) während des Bootens und wenn die Festplatte/Massenspeicher nicht beschreibbar ist. "auto" entspricht "persistent", aber das Verzeichnis "/var/log/journal" wird bei Bedarf *nicht* angelegt (wenn es nicht existiert), sodaß die Existenz von "/var/log/journal" entscheidet ob die Daten nach "/run/log/journal" gehen oder nicht. "none" schaltet das Speichern der Logs komplett ab, d.h. alle Logdaten werden weggeworfen. Das Weiterleiten zu anderen Zielen, wie etwa an die Konsole, den Kernel-Ringpuffer oder einen anderen Syslog-Daemon funktioniert jedoch weiterhin. Default ist "auto".
Und ja, es ist praktisch den User zur Gruppe "systemd-journal" hinzuzufügen.

Code: Alles auswählen

# gpasswd -a username systemd-journal
Dann kann man da in Ruhe herumblättern oder Speichern (und herumblättern):

Code: Alles auswählen

$ journalctl -k > dmesg.log
less dmesg.log
Gruss, habakug
( # = root | $ = user | !! = mod ) (Vor der PN) (Debianforum-Wiki) (NoPaste)

Benutzeravatar
mindX
Beiträge: 1541
Registriert: 27.03.2009 19:17:28
Lizenz eigener Beiträge: GNU General Public License

Re: Logs unter systemd auswerten

Beitrag von mindX » 20.11.2014 20:51:23

Herzlichen Dank für die hilfreichen Tipps!

Nachdem ich meinen user zur Gruppe systemd-journal hinzugefügt habe, sieht das Ganze schon deutlich informativer aus :)
Um nur den aktuellen Systemstart abzufragen, bietet sich ein journalctl --this-boot an. Um mich 'nicht zu verwirren', habe ich Debianrsyslog und Debianexim4 deinstalliert und alle Logs gelöscht, mal sehen, ob sich das so bewährt... /var/log/journal habe ich übrigens nicht selbst angelegt.

Dann noch eine Frage, die womöglich mit systemd zusammenhängt, kann aber auch OT sein: Seit neuestem läuft bei jedem booten ein fsck:

Code: Alles auswählen

Nov 20 19:33:05 M72e systemd-fsck[413]: /dev/sda3: Der Zeitpunkt des letzten Schreibens des Superblocks liegt in der Zukunft.
Nov 20 19:33:05 M72e systemd-fsck[413]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter Hardware-Uhr)  REPARIERT.
...
Nov 20 19:33:17 M72e systemd[1]: Reached target Network is Online.
Nov 20 19:33:17 M72e systemd[1]: Starting LSB: RPC portmapper replacement...
Nov 20 19:33:18 M72e networking[459]: Configuring network interfaces...done.
Nov 20 19:33:18 M72e ntpdate[514]: Can't find host 0.debian.pool.ntp.org: Name or service not known (-2)
Nov 20 19:33:18 M72e ntpdate[514]: Can't find host 1.debian.pool.ntp.org: Name or service not known (-2)
Nov 20 19:33:18 M72e ntpdate[514]: Can't find host 2.debian.pool.ntp.org: Name or service not known (-2)
Die Meldung von ntpdate ist mir neu, obwohl ich seit Lenny die Systemzeit über cron und ntp1.ptb.de einstelle. Könnte es da einen Zusammenhang geben?

e/ Das fsck-Problem lag tatsächlich an systemd, besser gesagt daran, dass systemd jetzt auch die Systemzeit einstellt. :roll:
Es ließ sich aber über

Code: Alles auswählen

timedatectl set-local-rtc 0
beheben.

Antworten