inetutils-syslogd hängt mit mark

[etron770]

Debian Buster VM auf Proxmox
Plattenplatz noch 20 Gb frei

Das Logsystem hängt sich von Zeit zu Zeit auf und bringt beim Syslog nur die Zeile: -- MARK --

Auch ein Neustart des Servers bringt da keine Abhilfe. Das fatale daran ist, dass dann fail2ban keine Daten mehr bekommt und der Server mit Anfragen geflutet wird, und die Auslastung sehr stark ansteigt.
Die Neuinstallation von inetutils-syslogd löst das Problem für Wochen wieder.

Ich weiß einfach nicht wo ich suchen soll, vor allem weil das nur sporadisch auftritt. Das merke ich dann nur wenn der Server langsam wird und dann ist der Fehler schon vorhanden.

[DeletedUserReAsG]

›-- MARK --‹ ist ein Platzhalter und besagt, dass eine Weile nix passiert ist, was loggenswert wäre. Eine kurze Suche dazu hätte beispielsweise diese Seite finden können. Hast du denn nicht gesucht?

Ich weiß einfach nicht wo ich suchen soll

Das Journal wäre meine Anlaufstelle.

[etron770]

›-- MARK --‹ ist ein Platzhalter und besagt, dass eine Weile nix passiert ist, was loggenswert wäre. Eine kurze Suche dazu hätte beispielsweise diese Seite finden können. Hast du denn nicht gesucht?

Sicher habe ich gesucht - lange und ausführlich ...

Wenn es so einfach wäre ...
Das Problem ist eben dass das Journal stoppt und außer --MARK-- nichts mehr ankommt. Und das stimmt definitv nicht, denn ich kann Webseiten aufrufen, der Webserver läuft also noch und wenn ich z.B eine Grafik anzeigen lasse, die auf dem Server nicht vorhanden ist, kommt im Syslog eben keine Fehlermeldung. Und da müsste ein "https://www.URL.com|1666259073|page not found|www.xxx.yyy.zzz|..." kommen
Diese kommt aber sofort wieder nachdem inetutils-syslogd neu installiert wurde.

Vor dem ersten --MARK-- sind ganz normale Syslogeinträge und ohne Fehlermeldung kommt im Syslog plötzlich nichts mehr an.

[MSfree]

der Webserver läuft also noch und wenn ich z.B eine Grafik anzeigen lasse, die auf dem Server nicht vorhanden ist, kommt im Syslog eben keine Fehlermeldung.

Der Webserver malt nicht ins Systemlog. Der hat seine eigenen Logdateien, der apache2 logt beispielsweise nach /var/log/apache2.

[etron770]

der Webserver läuft also noch und wenn ich z.B eine Grafik anzeigen lasse, die auf dem Server nicht vorhanden ist, kommt im Syslog eben keine Fehlermeldung.

Der Webserver malt nicht ins Systemlog. Der hat seine eigenen Logdateien, der apache2 logt beispielsweise nach /var/log/apache2.

Das war eventuell unklar von mir:

Ich habe ja nicht geschrieben, dass ich die Fehlermeldungen vom Apache im syslog bekomme. Ich bekomme sie vom einem CMS ins syslog.
Das ist auch nicht der Punkt. Es kommt nichts im Syslog an und es kommt auch nichts in anderen logfiles an, die in der /etc/syslog.conf konfiguriert sind.
Und ich verstehe nicht, warum dann trotzdem im Syslog --MARK-- kommt.

Und warum nur eine Neuinstallation hilft. Ich denke, wenn es trivial wäre hätte ich schon was darüber gefunden.

[MSfree]

Und warum nur eine Neuinstallation hilft.

SSD, Festplatte oder RAM kaputt.

[etron770]

Das war auf dem alten Rootserver auch so. Der neue hat Enterprise Festplatten ohne Fehler eingebaut. Und die anderen VM haben keine Probleme.

[DeletedUserReAsG]

Und was steht nun für den betreffenden Zeitraum im Journal (davon ausgehend, dass es eine Maschine mit systemd und entsprechend journald ist, wie’s bei Buster ja schon Standard war – eine abweichende Konfiguration hättest du ja sicher aufgeführt)?
Was steht im Ringbuffer des Kernels (dmesg) nach Auftreten des Fehlers?

Zusätzliche Frage: wird spezifische Funktionalität von inetutils-syslogd tatsächlich gebraucht, oder wird das nur wegen „hab ich schon immer so gemacht!“ noch genutzt?

[etron770]

dmesg

Code: Alles auswählen

[Do Okt 20 11:41:29 2022] vmbr0: port 2(veth106i0) entered disabled state
[Do Okt 20 11:41:29 2022] vmbr0: port 2(veth106i0) entered disabled state
[Do Okt 20 11:41:29 2022] device veth106i0 left promiscuous mode
[Do Okt 20 11:41:29 2022] vmbr0: port 2(veth106i0) entered disabled state
[Do Okt 20 11:41:29 2022] audit: type=1400 audit(1666258890.034:42): apparmor="STATUS" operation="profile_remove" profile="/usr/bin/lxc-start" name="lxc-106_</var/lib/lxc>" pid=3889579 comm="apparmor_parser"
[Do Okt 20 11:41:31 2022] loop2: detected capacity change from 0 to 734003200
[Do Okt 20 11:41:31 2022] EXT4-fs (loop2): mounted filesystem with ordered data mode. Opts: usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0. Quota mode: journalled.
[Do Okt 20 11:41:32 2022] audit: type=1400 audit(1666258892.434:43): apparmor="STATUS" operation="profile_load" profile="/usr/bin/lxc-start" name="lxc-106_</var/lib/lxc>" pid=3889612 comm="apparmor_parser"
[Do Okt 20 11:41:32 2022] vmbr0: port 2(veth106i0) entered blocking state
[Do Okt 20 11:41:32 2022] vmbr0: port 2(veth106i0) entered disabled state
[Do Okt 20 11:41:32 2022] device veth106i0 entered promiscuous mode
[Do Okt 20 11:41:32 2022] eth0: renamed from vethDbWQ1w
[Do Okt 20 11:41:33 2022] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[Do Okt 20 11:41:33 2022] vmbr0: port 2(veth106i0) entered blocking state
[Do Okt 20 11:41:33 2022] vmbr0: port 2(veth106i0) entered forwarding state
[Do Okt 20 11:45:01 2022] nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead.
[Do Okt 20 14:35:00 2022] vmbr0: port 2(veth106i0) entered disabled state
[Do Okt 20 14:35:00 2022] vmbr0: port 2(veth106i0) entered disabled state
[Do Okt 20 14:35:00 2022] device veth106i0 left promiscuous mode
[Do Okt 20 14:35:00 2022] vmbr0: port 2(veth106i0) entered disabled state
[Do Okt 20 14:35:01 2022] audit: type=1400 audit(1666269301.639:44): apparmor="STATUS" operation="profile_remove" profile="/usr/bin/lxc-start" name="lxc-106_</var/lib/lxc>" pid=4050752 comm="apparmor_parser"
[Do Okt 20 14:35:03 2022] loop2: detected capacity change from 0 to 734003200
[Do Okt 20 14:35:03 2022] EXT4-fs (loop2): mounted filesystem with ordered data mode. Opts: usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0. Quota mode: journalled.
[Do Okt 20 14:35:03 2022] audit: type=1400 audit(1666269304.179:45): apparmor="STATUS" operation="profile_load" profile="/usr/bin/lxc-start" name="lxc-106_</var/lib/lxc>" pid=4051103 comm="apparmor_parser"
[Do Okt 20 14:35:04 2022] vmbr0: port 2(veth106i0) entered blocking state
[Do Okt 20 14:35:04 2022] vmbr0: port 2(veth106i0) entered disabled state
[Do Okt 20 14:35:04 2022] device veth106i0 entered promiscuous mode
[...]

syslog:

Code: Alles auswählen

Oct 20 11:44:13 web2 drupal: https://www.any-webpage.com|1666259053|page not found|vv.ww.xx.yy|https://www.any-webpage.com/files/js/blank.png|https://www.any-webpage.com/de/page2|0||files/js/blank.png
Oct 20 11:44:33 web2 drupal: https://www.any-webpage.com|1666259073|page not found|50.41.7.58|https://www.any-webpage.com/files/js/blank.png|https://www.any-webpage.com/en/page1|0||files/js/blank.png
Oct 20 12:01:35 web2 -- MARK --
Oct 20 12:21:35 web2 -- MARK --
Oct 20 12:41:35 web2 -- MARK --
Oct 20 13:01:35 web2 -- MARK --
Oct 20 13:21:35 web2 -- MARK --
Oct 20 13:41:35 web2 -- MARK --
Oct 20 14:01:35 web2 -- MARK --
Oct 20 14:21:35 web2 -- MARK --
Oct 20 14:34:56 web2 syslogd: exiting on signal 15
Oct 20 14:35:06 web2 syslogd (GNU inetutils 1.9.4): restart
[...]

nach dem letzten --MARK-- war ein Restart der VM
und in dmesg ist in dem --MARK-- Zeitraum auch kein Eintrag

Trotzdem werden Webseiten ausgeliefert, ich kann über den Rootserver in den LXC Container
Unter anderem werden Mails nicht mehr ausgeliefert, ssh Zugriff mit Keyfile hängt nach dem Passwort.

[...] hab ich schon immer so gemacht!“ noch genutzt? [...]
das ist eine gute Frage: Der Server ist von squeeze immer upgdatet worden und ich weiß ehrlich gesagt nicht mehr was ich auf diesem Server alles manuell verändert habe ...

[DeletedUserReAsG]

Du könntest nun dazuschreiben, woher und in welchem Kontext die jeweilige Ausgabe ist, und ob der Fehler da aufgetreten ist (weil du ja schriebst, dass du das Paket neu installieren würdest – das hätte ja auch wieder recht eindeutige Logeinträge hinterlassen – ist das hier nicht passiert?)

Anyway: statt beim syslogd zu suchen, der für den Fehler möglicherweise gar nicht ursächlich ist, sondern dessen Aussteigen eine Folge eines anderen Fehlers sein könnte, würde ich beim Vorliegen des Fehlers gucken, was da in dem Moment schiefläuft. Ein erster Überblick könnte beispielsweise mit atop gewonnen werden – schauen, ob da irgendwas jenseits der normalen Werte ist.
Auch kann’s sinnvoll sein, den inetutils-syslogd mal wegzumachen, wenn eh nicht klar ist, warum der überhaupt noch genutzt wird, und stattdessen den sowieso vorhandenen journald zu verwenden. Aufpassen: so Konfiguration von etwa fail2ban müsste u.U. entsprechend angepasst werden.

[etron770]

Du könntest nun dazuschreiben, woher und in welchem Kontext die jeweilige Ausgabe ist, und ob der Fehler da aufgetreten ist (weil du ja schriebst, dass du das Paket neu installieren würdest – das hätte ja auch wieder recht eindeutige Logeinträge hinterlassen – ist das hier nicht passiert?)

Sorry ich weiß jetzt nicht was du mit Kontext damit meinst. Das ist die Zeit in der das Syslog Mark bring und das dmesg dazu
Und die Einträge der Neuinstallation können ja erst nach der fertigen Installation angezeigt werden, da davor ja nichts in den logs kommt.

Anyway: statt beim syslogd zu suchen, der für den Fehler möglicherweise gar nicht ursächlich ist, sondern dessen Aussteigen eine Folge eines anderen Fehlers sein könnte, würde ich beim Vorliegen des Fehlers gucken, was da in dem Moment schiefläuft. Ein erster Überblick könnte beispielsweise mit atop gewonnen werden – schauen, ob da irgendwas jenseits der normalen Werte ist.

Wenn das alle paar Wochen nur passiert, dann ist das ziemlich unmöglich - das ist ja gerade eines der große Problem. Es ist nicht reproduzierbar, es kommt sporadisch und in den Syslogs ist dann nichts. Noch nicht einmal in dmesg.
Ich suche da schon Monate ...

[DeletedUserReAsG]

Das ist die Zeit in der das Syslog Mark bring und das dmesg dazu
Und die Einträge der Neuinstallation können ja erst nach der fertigen Installation angezeigt werden, da davor ja nichts in den logs kommt.

Da weiß ich nun wieder nicht, was du damit meinst: das ›-- MARK --‹ wurde ja nun schon erklärt: es ist nix angefallen, was der syslogd loggen könnte. Sei’s aufgrund seiner Konfiguration, sei’s, weil kein Prozess ihm was zum Loggen übermittelt. Die Ausgabe von dmesg sehe ich da hingegen nicht – die sieht üblicherweise anders aus, und beinhaltet insbesondere keine Daten von vor einem Reboot – oder war damit nur der Container gemeint?

Was im Journal steht, behälst du leider weiterhin für dich …

Wenn das alle paar Wochen nur passiert, dann ist das ziemlich unmöglich

Ich denke, dass dir irgendwann auffällt, dass das Problem vorliegt, und du dann vom Host aus in den Container schauen kannst? Dann kannst du doch auch gucken, was da los ist? Apropos: hast du denn mal im Journal des Hosts geschaut, ob da irgendwas zum Problem mit dem Container zu finden ist?

[etron770]

Das ist die Zeit in der das Syslog Mark bring und das dmesg dazu
Und die Einträge der Neuinstallation können ja erst nach der fertigen Installation angezeigt werden, da davor ja nichts in den logs kommt.

Da weiß ich nun wieder nicht, was du damit meinst: das ›-- MARK --‹ wurde ja nun schon erklärt: es ist nix angefallen, was der syslogd loggen könnte. Sei’s aufgrund seiner Konfiguration, sei’s, weil kein Prozess ihm was zum Loggen übermittelt. Die Ausgabe von dmesg sehe ich da hingegen nicht – die sieht üblicherweise anders aus, und beinhaltet insbesondere keine Daten von vor einem Reboot – oder war damit nur der Container gemeint?

Fangen wir doch mal da an, weil wir da aneinader vorbeireden.
diese Fehlermeldung

Code: Alles auswählen

Oct 20 11:44:33 web2 drupal: https://www.any-webpage.com|1666259073|page not found|50.41.7.58|https://www.any-webpage.com/files/js/blank.png|https://www.any-webpage.com/en/page1|0||files/js/blank.png

Ist ein Workaround für einen Bug in einem CMS, dass die Seiten unrichtig dargestellt werden, wenn die Datei vorhanden ist. (wird ohnehin jetzt neu designed)
Das ist eine Webseite die mehr als 50% des Traffics ausmacht und diese Meldungen kommen sehr oft.

Wenn Mark erscheint funktioniert der Webserver trotzdem noch. Ich rufe probehalber eine der Seiten mit dem blank.png auf und es kommt kein Eintrag im Syslog
Dann ist die Frage warum nichts zum loggen übermittlet wird und warum vieles außer dem Webserver komplett hängt und dieser langsam ist und warum dmesg genau in dieser Zeit auch keine Daten hat.

Und das Journal fängt ja beim Neustart an. Da müsste ich erst beim Auftreten des Fehlers vor dem Neustart nachschauen. Bzw. umstellen, dass es mehrere Neustarts mitprotokolliert. Stand heute ist da nichts drin.

Ich versuche gerne alles mitzuteilen, aber über dieses Verhalten findet man einfach nichts ... also ich zumindestens nichts

[etron770]

Die Ausgabe von dmesg sehe ich da hingegen nicht – die sieht üblicherweise anders aus, und beinhaltet insbesondere keine Daten von vor einem Reboot – oder war damit nur der Container gemeint?

reboot des Containers und er steht in dmsg: [...]profile="/usr/bin/lxc-start"[...]

das root journal durchsuche ich noch und editiere es hier

[DeletedUserReAsG]

Ich rufe probehalber eine der Seiten mit dem blank.png auf und es kommt kein Eintrag im Syslog

Du hast dein System so konfiguriert, dass fehlgeschlagene Webseitenaufrufe im Syslog erscheinen sollen? Das erscheint mir nicht ganz durchdacht …

Wie angedeutet: wenn im Container nix mehr zu machen ist, wäre der Host und seine Logs im Mittelpunkt des Interesses. atop hab ich schon erwähnt, das würde auch dort für einen schnellen Überblick sorgen können.

[etron770]

Du hast dein System so konfiguriert, dass fehlgeschlagene Webseitenaufrufe im Syslog erscheinen sollen? Das erscheint mir nicht ganz durchdacht …

Da frag mal die Drupal Entwickler warum sie ins Syslog posten

[oln]

Moin,

Da frag mal die Drupal Entwickler warum sie ins Syslog posten

das hat nichts mir Drupal zu tun. Sondern ist eine Konfiguration deines Webservers.
Beim Apachen solltest du in deinen Vhost folgende Zeilen einfügen. Dann bekommst du auch gesonderte Logfiles:

Code: Alles auswählen

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

[etron770]

Das kommt schon von Drupal (Version 7) da gab es ein Modul syslog.
Das ist/war die einzige Möglichkeit über fail2ban hacking usw. von Drupal Seiten zu erkennen.
Da kann man nur logging an und abschalten. Und dann landet Honeypot Meldungen und file not found, Anmeldeversuche usw. im syslog...

Die Apache Website logs landen in andern Logfiles getrennt nach Website, so wie es in der vhost eingetragen ist.
Und da kommen die Drupal spezifischen Meldungen nicht an.