Syslog "lesen" auf nicht-systemd Systemen

[buhtz]

Ich habe kein Nicht-Systemd System zur Hand und frage daher.

Wie lese ich syslog Meldungen einer bestimmten Anwendung (nicht Unit!) auf Systemen die kein SystemD haben. Bei letzteren tue ich das ja in der Regel mit journactl --identifier APPNAME.

Das Netz nennt mir die Datei /var/log/syslog. Die gibt es (by default) in meinem System auch nicht.

Ein einfaches grepen einer Text-Datei ist natürlich eine Lösung. Aber ich vermute, dass es es auch hierfür speziellere Terminal tools gibt?

Die Dateien werden ja auch noch rotiert, mit Kompression und Nummerierung. Dann gibt es noch /var/log/messages, usw. Ich vermute doch stark, es gibt einen Mechanismus der es Admins ermöglicht, das ganze System dieser Log-Dateien nach Meldungen einer Bestimmten Anwendung zu durchsuchen, wenn er nicht weiß, in welcher der syslog Ziele die Messages der Anwendung landen.

[MSfree]

Das Netz nennt mir die Datei /var/log/syslog. Die gibt es (by default) in meinem System auch nicht.

Es gibt keinen festen Namen für die Datei, in die gelogt werden soll. Zwar gibt es mit der Installation von rsyslog eine vorgefertigte Konfigurationsdatei /etc/rsyslod.conf, die im wesentlichen nach /var/log/messages loggen läßt, aber es hindert keinen daran, nach /home/hugo/geheime.logdatei zu loggen.

Daher wird dir das Netz auch nicht den Namen rausrücken, wo hingelogt wird, weil der Name eben konfigurierbar ist und der Default von der Distribution abhängt.

dass es es auch hierfür speziellere Terminal tools gibt?

Ja, die gibt es, z.B. grep

[GregorS]

Ich habe kein Nicht-Systemd System zur Hand und frage daher.
...
Das Netz nennt mir die Datei /var/log/syslog. Die gibt es (by default) in meinem System auch nicht.

Ich hatte noch nie ein System, bei dem es nicht auch die Datei /var/log/syslog gegeben hätte. Bei mir läuft allerdings auch nichts mit systemd.

Die Dateien werden ja auch noch rotiert, mit Kompression und Nummerierung.

Nicht, wenn Du logrotate deaktivierst. IIRC habe ich bei mir die entsprechenden cron-Zeilen auskommentiert. Platz ist doch eh kein Problem mehr. Und wenn man sich keine Logs per Mail zuschicken lässt, reicht es, wenn alles in einer Datei steht.

Gruß

Gregor

[Meillo]

dass es es auch hierfür speziellere Terminal tools gibt?

Ja, die gibt es, z.B. grep

Genau.

Die Idee von Unix (also die Unix Philosophie) ist es, dass alle Daten im gleichen Format (plain text) vorliegen und dadurch gar keine *speziellen* Tools gebraucht werden, sondern immer mit den gleichen *allgemeinen* Tools gearbeitet werden kann. Dadurch skaliert das System und es skalieren auch die Kenntnisse der User.

Wenn spezielle Tools fuer etwas benoetigt werden, so ist das aus Sicht der Unix Philosophie ein Rueckschritt, da es der eigentlichen Idee und des Erfolgsfaktors entgegen laeuft. Es waere folglich seltsam, wenn zum Sichten von Logfile spezielle Tools noetig waeren.

[niemand]

Die Idee von Unix (also die Unix Philosophie) ist es, dass alle Daten im gleichen Format (plain text) vorliegen und dadurch gar keine *speziellen* Tools gebraucht werden, sondern immer mit den gleichen *allgemeinen* Tools gearbeitet werden kann.

Es gibt aber auch ’ne Unix-Philosophie, nach der jedes Werkzeug genau einen Job machen machen sollte, den aber dafür exzellent. Unter dem Gesichtspunkt steht journalctl dann wieder nicht zu schlecht da: versuch’ beispielsweise mal, mit grep alle Meldungen eines bestimmten Programms aus dem Log zu fischen, wenn du im Vorfeld keine Infos über die möglichen Erscheinungsformen dieser Meldungen hast.

Abgesehen davon kannst du sehr wohl das Journal mit den allgemeinen Bordmitteln von den zusätzlichen Informationen befreien und mit grep dran herumwerkeln, wenn dir so sein sollte.

[buhtz]

Bitte jetzt keine systemd Diskussion. Peace Leude!

Das Problem ist weniger, dass alles in plain text ist, sondern dass je nach System andere log Dateien existieren, mal mit und ohne Rotation. Da verliert man dein Überblick. Ein Tools das alle Varianten kennt und ggf. detektiert wäre schön.

Der Hintergrund meiner Frage ist, dass ich meinen Usern in einem kurze FAQ Eintrag erklären muss, wie sie die syslog Einträge meiner Anwendung lesen können, wenn sie auf einem Nicht-SystemD System arbeiten. Scheinbar gibt es darauf keine kurze Antwort. Vielleicht ist es aber auch eine nicht so gute Idee (nicht meine!) syslog für eine GUI Anwendung (backintime-qt) zu nutzen.

Wenn wir bei Unix Philosophie sind: Welche Art von Anwendungen sollten den syslog nutzen? Wo ist die Grenze?

[Meillo]

Die Idee von Unix (also die Unix Philosophie) ist es, dass alle Daten im gleichen Format (plain text) vorliegen und dadurch gar keine *speziellen* Tools gebraucht werden, sondern immer mit den gleichen *allgemeinen* Tools gearbeitet werden kann.

Es gibt aber auch ’ne Unix-Philosophie, nach der jedes Werkzeug genau einen Job machen machen sollte, den aber dafür exzellent. Unter dem Gesichtspunkt steht journalctl dann wieder nicht zu schlecht da: versuch’ beispielsweise mal, mit grep alle Meldungen eines bestimmten Programms aus dem Log zu fischen, wenn du im Vorfeld keine Infos über die möglichen Erscheinungsformen dieser Meldungen hast.

Das ist kein Problem der Visualisierungstools, sondern der Datenhaltung.

Generell gesprochen darf die ``one tool, one job''-Regel nicht dazu fuehren, dass es dann einfach tausende Tools fuer lauter Einzelfaelle gibt, sondern sie soll nur dafuer sorgen, dass die Tools orthogonal und damit kombinierbar sind. Denn das Ziel sind kombinierbare, allgemeine Tools und keine Spezialtools fuer nur einzelne Faelle. Das wird nicht im jedem Fall klappen, sollte aber angestrebt werden ... aus einer Betrachtung des Gesamtsystems und der Gesamtkomplexitaet heraus.

Ich habe das nur deshalb angemerkt, weil buhtz ein Spezialtool erwartet hat, was aus meiner Sicht eine seltsame Erwartung auf einem Unix-System ist. Dies wollte ich aufzeigen.

[Meillo]

Welche Art von Anwendungen sollten den syslog nutzen? Wo ist die Grenze?

Einfach gesagt: diejenigen die nicht direkt an den User melden koennen ... also alles was nicht an einem interaktiven Terminal haengt. D.h. Hintergrundprozesse/Daemonen/Services.

[rhHeini]

Aus Sicht eines Devuan Daedalus = Bookworm ohne systemd:

rsyslog loggt binär in die syslog, es gibt eine syslog.1, und weitere 2 Dateien syslog.2.gz und syslog.3.gz. Die Rotation muss man manual oder über cron anstossen, automatisch wie früher geht es nimmer, weiss nicht warum. Da sollte alles drin landen.

Cinnamon stellt als Tool eine Anwendng Namens Systemprotokoll zur Verfügung, dahinter verbirgt sich gnome-system-log-pkexec. Damit kann man alle Logs ansehen wenn geöffnet.

Ältere Logs sind dmesg, kern.log, messages (ist inzwischen leer).

[chrbr]

Das Netz nennt mir die Datei /var/log/syslog. Die gibt es (by default) in meinem System auch nicht.

Ein einfaches grepen einer Text-Datei ist natürlich eine Lösung. Aber ich vermute, dass es es auch hierfür speziellere Terminal tools gibt?

Ich bin gerade auf diese möglicherweise relevante Seite gestossen: https://forums.freebsd.org/threads/web- ... ost-643504
Vielleicht ist die Aufzählung einen Blick wert.
Viele Grüße, Christoph