Kennt ihr ein intelligentes Logeinträge Vergleichsprogramm für Linux?

[Nano (Gast)]

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?

[Andreas B. (bitverdreher)]

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

[Scherzkeks (Gast)]

"Da hilft nur Brain 2.0"
ISt das Freeware? Google findet keinen Download

[Nano (Gast)]

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.

[Andreas B. (bitverdreher)]

Scherzkeks schrieb:
> ISt das Freeware?
Gab es bei Mami umsonst und als Erweiterung in der Schule.
Also schon irgendwie Freeware.

[Hendrik L. (hlipka)]

systemd-analyze und systemd-bootchart, bzw. auch bootchart2 könnten 
weiterhelfen. (je nachdem was Du eigentlich erreichen möchtest)

[Wolfgang (Gast)]

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?

[Frank M. (ukw) (Moderator)]

Ich sehe da nur einen Weg:

1. Log der Session 1 und Session 2 separieren
2. Diff drauf loslassen

[leo (Gast)]

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

[Frank M. (ukw) (Moderator)]

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.

[Nano (Gast)]

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.

[just visiting (Gast)]

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

[Nano (Gast)]

root@##########:~# journalctl -b -p err -t kernel
-- Logs begin at Thu 2021-02-04 10:39:51 CET, end at Thu 2021-02-04 18:17:01 CET. --
-- No entries --
root@##########:~# journalctl -b -1 -p err -t kernel 
Specifying boot ID or boot offset has no effect, no persistent journal was found.

[just visiting (Gast)]

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

[Nano (Gast)]

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.

[Huckel (Gast)]

Das Windows-Programm WinMerge könnte hilfreich sein. Vielleicht gibt es 
eine Linux-Version.

[just visiting (Gast)]

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

[Nano (Gast)]

just visiting schrieb:
> Nano schrieb:
>
>> Erfahrungen damit gemacht. Dennoch nutze ich heute lieber Debian.
>
> Dat hat kein systemD...

Ähm doch.

systemctl status
● ########
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2021-02-04 11:39:51 CET; 8h ago
   CGroup: /
           ├─user.slice
           │ └─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

[just visiting (Gast)]

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

[Nano (Gast)]

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.

[just visiting (Gast)]

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.

[just visiting (Gast)]

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

[Sheeva P. (sheevaplug)]

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.

[Nano (Gast)]

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.

[Frank M. (ukw) (Moderator)]

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.

[Nano (Gast)]

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.

[Hendrik L. (hlipka)]

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.

[just visiting (Gast)]

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

Z.B. zu Fuß

diff \
<(journalctl -b0  -p err -t kernel |cut -d ':' -f 4- |uniq) \
<(journalctl -b1  -p err -t kernel |cut -d ':' -f 4- |uniq)    

5,12d4
<  hub 3-2:1.0: hub_ext_port_status failed (err = -71)
<  usb 3-2-port4: cannot reset (err = -71)
<  usb 3-2-port4: Cannot enable. Maybe the USB cable is bad?
<  usb 3-2-port4: cannot disable (err = -71)
<  usb 3-2-port4: cannot reset (err = -71)
<  usb 3-2-port4: Cannot enable. Maybe the USB cable is bad?
<  usb 3-2-port4: cannot disable (err = -71)
<  usb usb3-port2: disabled by hub (EMI?), re-enabling...


vs.

journalctl -b  -p err -t kernel
-- Logs begin at Thu 2021-02-04 11:15:21 CET, end at Fri 2021-02-05 14:54:19 CET. --
Feb 05 00:17:12 slax kernel: ACPI Exception: AE_AML_NO_OPERAND, [DSDT] table load failed (20160831/tbxfload-198)
Feb 05 00:17:12 slax kernel: ACPI Error: 1 table load failures, 0 successful (20160831/tbxfload-246)
Feb 05 00:17:12 slax kernel: Spectre V2 : Spectre mitigation: LFENCE not serializing, switching to generic retpol
Feb 05 00:17:13 slax kernel: hub 3-2:1.0: hub_ext_port_status failed (err = -71)
Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71)
Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71)
Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71)
Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71)
Feb 05 00:17:13 slax kernel: usb 3-2-port4: Cannot enable. Maybe the USB cable is bad?
Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot disable (err = -71)
Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71)
Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71)
Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71)
Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71)
Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot reset (err = -71)
Feb 05 00:17:13 slax kernel: usb 3-2-port4: Cannot enable. Maybe the USB cable is bad?
Feb 05 00:17:13 slax kernel: usb 3-2-port4: cannot disable (err = -71)
Feb 05 00:17:13 slax kernel: usb usb3-port2: disabled by hub (EMI?), re-enabling...

[S. R. (svenska)]

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.