Ich möchte die Logs zwischen zwei Sitzungen bzw. Bootphasen vergleichen. Ein einfacher Texteditor, der Logdateien vergleichen kann, reicht mir hier aber nicht, denn: 1. kann es vorkommen, dass die Logs von zwei Sitzungen hintereinander in die gleiche Log Datei geschrieben werden, was man manuell mit extra Arbeit zwar auftrennen könnte, aber 2. bei modernen Linuxsystemen muss die Initialisierungsreihenfolge der einzelnen Komponenten nicht mehr sequentiell immer die gleiche sein. Wenn also der Log Eintrag für Service A vor Service B steht und beim nächsten Start das genau anders herum ist, dann bringt ein einfacher Textvergleich nichts, da normale Textvergleichsprogramm so etwas nicht berücksichtigen. Deswegen suche ein Vergleichsprogramm, das beides unter einen Hut kriegt und die Einträge grafisch nebeneinander anzeigen kann. Gibt es so etwas?
Wie willst Du das automatisieren, wenn ein Dienst seine Einträge nicht nacheinander ausgibt weil andere dazwischenfunken? Das Programm müßte erkennen welche Meldung zu welchem Dienst gehört. Da hilft nur Brain 2.0
"Da hilft nur Brain 2.0" ISt das Freeware? Google findet keinen Download
Andreas B. schrieb: > Wie willst Du das automatisieren, wenn ein Dienst seine Einträge > nicht > nacheinander ausgibt weil andere dazwischenfunken? Das Programm müßte > erkennen welche Meldung zu welchem Dienst gehört. > Da hilft nur Brain 2.0 Durch einen zeilenweisen Abgleich. Ich dachte da bspw. an so ne Art Map Datenstruktur gepaart mit Metainformationen. Die Metainformationen enthalten dann bspw. die Kernelzeit. die bspw. bei dmesg immer dabei steht. Dann weiß man z.B. dass Gerät XY sowohl in der erste Sitzung als auch in der zweiten erkannt wurde. Anhand der Zeit erkennt man den Start der unterschiedlichen Sessions. Natürlich gehört da noch etwas mehr dazu, wenn die Log für ein bestimmtes Gerät oder einen Dienst mehrere Zeilen lang sind. Aber da gibt's bei dmesg zumindest auch schon ne grobe Gruppierung. Deswegen ja "intelligentes" Vergleichsprogramm, das ne ungefähre Vorstellung hat, von dem was es ausgibt. Bei den Logs von systemd dürfte das schon gut strukturiert sein, da könnte es einfacher sein. So in etwa stelle ich mir das grob vor.
Scherzkeks schrieb: > ISt das Freeware? Gab es bei Mami umsonst und als Erweiterung in der Schule. Also schon irgendwie Freeware.
systemd-analyze und systemd-bootchart, bzw. auch bootchart2 könnten weiterhelfen. (je nachdem was Du eigentlich erreichen möchtest)
Nano schrieb: > Wenn also der Log Eintrag für Service A vor Service B steht und beim > nächsten Start das genau anders herum ist, dann bringt ein einfacher > Textvergleich nichts, da normale Textvergleichsprogramm so etwas nicht > berücksichtigen. Dann schalte das System doch auf Ausgabe der Log-Informationen als XML um. Mit Hilfe der Meta-Informationen, die dann mit untergebracht werden können (z.B. Name des Service), wird für ein Vergleichsprogramm der Abgleich viel einfacher. Oder ist das moderne Linuxsystem so modern dann auch wieder nicht?
Ich sehe da nur einen Weg: 1. Log der Session 1 und Session 2 separieren 2. Diff drauf loslassen
Frank M. schrieb: > 2. Diff drauf loslassen So simpel geht es sicher nicht. Allein wegen der Timestamps ist das sinnlos. Ich wuerde Perl nehmen und was Spezialisierte stricken. leo
leo schrieb: > So simpel geht es sicher nicht. Allein wegen der Timestamps ist das > sinnlos. Beim Separieren der Logs kann man auch den Timestamp filtern. Wenn ich es richtig verstanden habe, interessiert sich der TO nur für die Reihenfolge und nicht für die Timestamps. > Ich wuerde Perl nehmen und was Spezialisierte stricken. Du hast ein Werkzeug genannt - aber keine Lösung. Natürlich muss man was stricken, aber dafür reicht auch sh, grep, sed und diff.
Frank M. schrieb: > Beim Separieren der Logs kann man auch den Timestamp filtern. Wenn ich > es richtig verstanden habe, interessiert sich der TO nur für die > Reihenfolge und nicht für die Timestamps. Ne, eigentlich interessiere ich mich für die Änderungen. >> Ich wuerde Perl nehmen und was Spezialisierte stricken. > > Du hast ein Werkzeug genannt - aber keine Lösung. Natürlich muss man was > stricken, aber dafür reicht auch sh, grep, sed und diff. So etwas komplexes schreibt man besser in python. Aber das hatte ich nicht vor, ich wollte nur wissen, ob es da schon was in der Richtung gibt. Das oben genannte systemd-bootchart werde ich mir mal ansehen.
Frank M. schrieb: > leo schrieb: >> So simpel geht es sicher nicht. Allein wegen der Timestamps ist das >> sinnlos. > > Beim Separieren der Logs kann man auch den Timestamp filtern. Wenn ich > es richtig verstanden habe, interessiert sich der TO nur für die > Reihenfolge und nicht für die Timestamps. > >> Ich wuerde Perl nehmen und was Spezialisierte stricken. > > Du hast ein Werkzeug genannt - aber keine Lösung. Natürlich muss man was > stricken, aber dafür reicht auch sh, grep, sed und diff. journald mit journalctl kann gut filtern. Das systemd journal als solches wird default meist nicht gespeichert, das lebt im initramfs. wenn ein Aufruf von journalctl --list-boots nur einen Eintrag, also den aktuellen Bootverlauf anzeigt /etc/systemd/journald.conf ggf. Storage=persistent setzen. Dann läßt sich deutlich einfacher arbeiten bspw ausgabe von journalctl -b -p err -t kernel #vergleichen mit journalctl -b -1 -p err -t kernel #voriger boot -b (0) aktuell (-1) vorhergehender -p, --priority= (log level) -t -t, --identifier=SYSLOG_IDENTIFIER (department) und viele mehr. --- da gibts mehr Lesestoff in Bezug zu Usern und Sessions https://wiki.archlinux.org/index.php/systemd/User#Reading_the_journal
1 | root@##########:~# journalctl -b -p err -t kernel |
2 | -- Logs begin at Thu 2021-02-04 10:39:51 CET, end at Thu 2021-02-04 18:17:01 CET. -- |
3 | -- No entries -- |
4 | root@##########:~# journalctl -b -1 -p err -t kernel |
5 | Specifying boot ID or boot offset has no effect, no persistent journal was found. |
a) gratuliere Kernel hat nichts zu meckern b) andere interessante Stelle wählen ;) c) schalte es halt ein # mkdir /var/log/journal # systemd-tmpfiles --create --prefix /var/log/journal # systemctl restart systemd-journald d)neu anwerfen, zurück zu journalctl --list-boots e) die Nummerierung ist ätzend ... y) installiere slackware z) have fun
just visiting schrieb: > c) schalte es halt ein Ja, ich wollte eigentlich Logs aus der Vergangenheit vergleichen. > # mkdir /var/log/journal > # systemd-tmpfiles --create --prefix /var/log/journal > # systemctl restart systemd-journald > > d)neu anwerfen, zurück zu > > journalctl --list-boots Ich werde mal gucken, ob das bei Debian nicht etwas anders geht oder ob ich da wirklich nen Ordner in /var/log erstellen muss. > y) installiere slackware Hatte ich früher, aber das System aktuell zu halten ist mir bei Slackware dann doch zu aufwendig geworden. Außerdem muss man zu viel aus den sourcen compilieren. Und dann ist das bei Slackware mit Patrick Volkerding offiziell nur ein Mann. Aber ansonsten ist Slackware eine klasse Distribution, ich habe nur gute Erfahrungen damit gemacht. Dennoch nutze ich heute lieber Debian.
Das Windows-Programm WinMerge könnte hilfreich sein. Vielleicht gibt es eine Linux-Version.
Nano schrieb: > Erfahrungen damit gemacht. Dennoch nutze ich heute lieber Debian. Dat hat kein systemD... Ich mach grad Coronaurlaub auf slax, debian+trinity :) dort residiert das temporär als binärer blobb unter /run/log/journal/ bislang werd ich damit nicht warm, das Ding journald ist die Ausnahme. >> ich da wirklich nen Ordner in /var/log erstellen muss. Ist doch dort gut aufgehoben, kann aber sicher dahin wo immer du es haben willst. #Computer --tea Earl-Grey hot
just visiting schrieb: > Nano schrieb: > >> Erfahrungen damit gemacht. Dennoch nutze ich heute lieber Debian. > > Dat hat kein systemD... Ähm doch.
1 | systemctl status |
2 | ● ######## |
3 | State: running |
4 | Jobs: 0 queued |
5 | Failed: 0 units |
6 | Since: Thu 2021-02-04 11:39:51 CET; 8h ago |
7 | CGroup: / |
8 | ├─user.slice |
9 | │ └─user-1000.slice |
Der Debian Fork, der kein systemd verwendet, heißt Devuan. Aber den nutze ich nicht. Ich finde systemd eigentlich ganz praktisch und auch sinnvoll. >>> ich da wirklich nen Ordner in /var/log erstellen muss. > > Ist doch dort gut aufgehoben, > kann aber sicher dahin wo immer du es haben willst. Ja, aber eventuell gibt's da nen offiziellen Weg, den man mit dpkg-reconfigure oder ähnlichem vielleicht nur aktivieren muss. > #Computer --tea Earl-Grey hot Jean Luc Picard
Nano schrieb: > Ähm doch. slackware hat keines. u. slax heute Debian einen seltsamen mix systemD/sysV > > Ja, aber eventuell gibt's da nen offiziellen Weg, den man mit > dpkg-reconfigure oder ähnlichem vielleicht nur aktivieren muss. > ? systemd-tmpfiles --remove --create
just visiting schrieb: > Nano schrieb: > >> Ähm doch. > > slackware hat keines. Ich weiß. Slackware hatte auch eher bsd style Initscripte. > u. slax heute Debian einen seltsamen mix systemD/sysV Das hängt auch davon ab wie alt deine Debian Installation ist bzw. wie viele upgrades auf die nächste Majorversionen die schon hinter sich hat. >> Ja, aber eventuell gibt's da nen offiziellen Weg, den man mit >> dpkg-reconfigure oder ähnlichem vielleicht nur aktivieren muss. >> > > ? Wenn du deine Java Run Time Umgebung ändern willst, dann kannst du die symbolischen links java und javac manuell umbiegen, oder es unter Debian gleich richtig machen und einfach dafür update-alternatives --config java verwenden. Gleiches gilt für den Browser, dein VNC Programm und viele andere. Eine Liste kriegst du mit: update-alternatives --get-selections Und das manuell zu machen ist halt am System vorbei, ohne dass das System dies irgendwie richtig mitkriegt und so gemacht wird, wie es vorgesehen ist. > > systemd-tmpfiles --remove --create Hat nichtmal ne --list Option.
Nano schrieb: > > Und das manuell zu machen ist halt am System vorbei, ohne dass das > System dies irgendwie richtig mitkriegt und so gemacht wird, wie es > vorgesehen ist. > jo, man journald.conf When packages need to customize the configuration, they can install configuration snippets in /usr/lib/systemd/*.conf.d/. Files in etc are reserved for the local administrator, who may use this logic to override the configuration files installed vendor packages. Jetzt ist das aber systemD selber u. eine einzige Örtlichkeit. .... Storage= Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. "none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work however. Defaults to "auto". alles grüner Bereich. --- aber das ist ja auch noch nicht was du suchst.
captains log, supplemental $mkdir /var/log/journal 2x reboot $journalctl --list-boots -2 072428ed8e984b67a6095f1bd872d91c Thu 2021-02-04 11:15:21 CET—Fri 2021-02-05 00:11:44 CET -1 7926260915a94f16bbe3195dbc3624b4 Fri 2021-02-05 00:12:35 CET—Fri 2021-02-05 00:16:18 CET 0 8241aa6ca6fa4b03bb283ff6f873c5b2 Fri 2021-02-05 00:17:12 CET—Fri 2021-02-05 00:19:04 CET
leo schrieb: > Frank M. schrieb: >> 2. Diff drauf loslassen > > So simpel geht es sicher nicht. Allein wegen der Timestamps ist das > sinnlos. Nö. > Ich wuerde Perl nehmen und was Spezialisierte stricken. Den Timestamp kann man mit einfachsten Shellmitteln wegwerfen und die Dateien dann mit kdiff3 schick vergleichen. Huch.
Sheeva P. schrieb: > leo schrieb: >> Frank M. schrieb: >>> 2. Diff drauf loslassen >> >> So simpel geht es sicher nicht. Allein wegen der Timestamps ist das >> sinnlos. > > Nö. > >> Ich wuerde Perl nehmen und was Spezialisierte stricken. > > Den Timestamp kann man mit einfachsten Shellmitteln wegwerfen und die > Dateien dann mit kdiff3 schick vergleichen. Huch. Und dann stellst du fest, dass vieles nicht passt, weil beim ersten Boot A, B, C, D die Reihenfolge der gebooteten Prozesse war und im zweiten Boot es nun A, D, C, B ist und kdiff3 findet deswegen außer ein paar wenige keine Gemeinsamkeiten. Merke: Wäre es mit einem diff getan, hätte ich den Thread nicht gestartet.
Nano schrieb: > Und dann stellst du fest, dass vieles nicht passt, weil beim ersten Boot > A, B, C, D die Reihenfolge der gebooteten Prozesse war und im zweiten > Boot es nun A, D, C, B ist Deswegen schrieb ich ja: 1. Log der Session 1 und Session 2 separieren Dann ist die Reihenfolge, wie die einzelnen Prozesse gestartet wurden, egal. Aber Du siehst, was Session 1 anders macht als Session 2.
Frank M. schrieb: > Nano schrieb: >> Und dann stellst du fest, dass vieles nicht passt, weil beim ersten Boot >> A, B, C, D die Reihenfolge der gebooteten Prozesse war und im zweiten >> Boot es nun A, D, C, B ist > > Deswegen schrieb ich ja: > > 1. Log der Session 1 und Session 2 separieren > > Dann ist die Reihenfolge, wie die einzelnen Prozesse gestartet wurden, > egal. Aber Du siehst, was Session 1 anders macht als Session 2. Das ist aber alles Handarbeit, die ich vermeiden wollte. Denn dann fragst du dich, wird B gestartet oder nicht, ach da unten am Ende. Und D da oben. Deswegen meine Frage nach einem Programm das gleiches sucht und das dann kategorisiert und aufbereitet. So dass wirklich nur die Änderungen übrig bleiben.
Nano schrieb: > Deswegen meine Frage nach einem Programm das gleiches sucht und das dann > kategorisiert und aufbereitet. So dass wirklich nur die Änderungen übrig > bleiben. Logfiles nehmen, jeweils die Zeitstempel rausschneiden (mit 'cut'), Dateien sortieren ('sort'), diff machen. Dann hast Du tatsächlich nur die Unterschiede in den Logs, verlierst aber den zeitlichen Bezug.
Nano schrieb: > Deswegen meine Frage nach einem Programm das gleiches sucht und das dann > kategorisiert und aufbereitet. Mir nicht bekannt > So dass wirklich nur die Änderungen übrig > bleiben. Warum auch immer die (usb)Maus war heute aus
1 | Z.B. zu Fuß |
2 | |
3 | diff \ |
4 | <(journalctl -b0 -p err -t kernel |cut -d ':' -f 4- |uniq) \ |
5 | <(journalctl -b1 -p err -t kernel |cut -d ':' -f 4- |uniq) |
6 | |
7 | 5,12d4 |
8 | < hub 3-2:1.0: hub_ext_port_status failed (err = -71) |
9 | < usb 3-2-port4: cannot reset (err = -71) |
10 | < usb 3-2-port4: Cannot enable. Maybe the USB cable is bad? |
11 | < usb 3-2-port4: cannot disable (err = -71) |
12 | < usb 3-2-port4: cannot reset (err = -71) |
13 | < usb 3-2-port4: Cannot enable. Maybe the USB cable is bad? |
14 | < usb 3-2-port4: cannot disable (err = -71) |
15 | < usb usb3-port2: disabled by hub (EMI?), re-enabling... |
16 | |
17 | |
18 | vs. |
19 | |
20 | journalctl -b -p err -t kernel |
21 | -- Logs begin at Thu 2021-02-04 11:15:21 CET, end at Fri 2021-02-05 14:54:19 CET. -- |
22 | Feb 05 00:17:12 slax kernel: ACPI Exception: AE_AML_NO_OPERAND, [DSDT] table load failed (20160831/tbxfload-198) |
23 | Feb 05 00:17:12 slax kernel: ACPI Error: 1 table load failures, 0 successful (20160831/tbxfload-246) |
24 | Feb 05 00:17:12 slax kernel: Spectre V2 : Spectre mitigation: LFENCE not serializing, switching to generic retpol |
25 | Feb 05 00:17:13 slax kernel: hub 3-2:1.0: hub_ext_port_status failed (err = -71) |
26 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71) |
27 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71) |
28 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71) |
29 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71) |
30 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: Cannot enable. Maybe the USB cable is bad? |
31 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot disable (err = -71) |
32 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71) |
33 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71) |
34 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71) |
35 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71) |
36 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71) |
37 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: Cannot enable. Maybe the USB cable is bad? |
38 | Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot disable (err = -71) |
39 | Feb 05 00:17:13 slax kernel: usb usb3-port2: disabled by hub (EMI?), re-enabling... |
Sheeva P. schrieb: >> Ich wuerde Perl nehmen und was Spezialisierte stricken. > > Den Timestamp kann man mit einfachsten Shellmitteln wegwerfen und die > Dateien dann mit kdiff3 schick vergleichen. Huch. Ich nutze für sowas "meld", kdiff3 kenne ich nicht. Wenn in den Logs ständig wechselnde Dinge (z.B. Timestamps oder Pointer) auftauchen, dann kann ich die per Regex vom Vergleich ausschließen. Und wenn Zeilen in unterschiedlicher Reihenfolge auftauchen, wird das auch halbwegs gebrauchbar angezeigt, weil untendrunter ein diff werkelt.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.