rsyslog protokolliert nicht

Dies ist ein merkwürdiges Problem.

Ich habe die chrony / ntp-Dienste auf einer RHEL7-VM getestet und deren Zeit sowie die des Hosts zurückgesetzt. Als ich damit zufrieden war, überprüfte ich /var/log/messagesund stellte fest, dass es eine Weile nicht mehr geändert worden war.

Unabhängig davon, was ich tue, wird nichts protokolliert, außer wenn ich den rsyslog-Dienst selbst neu starte. wenn ich das tue, bekomme ich das:

Apr 15 13:59:43 mymachine1 rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="2847" x-info="http://www.rsyslog.com"] exiting on signal 2.

Apr 15 13:59:59 mymachine1 rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="2853" x-info="http://www.rsyslog.com"] start

Apr 15 14:00:11 mymachine1 rsyslogd-3000: sd_journal_get_cursor() failed: 'Cannot assign requested address'

Versuche Dinge wie logger testnicht protokollieren, nichts anderes als die eigenen Nachrichten von rsyslog. Wenn ich rsyslog manuell mit folgenden -n -N1Argumenten ausführe, erhalte ich:

rsyslogd: version 7.4.2, config validation run (level 1), master config /etc/rsyslog.conf

rsyslogd: End of config validation run. Bye

Es scheint nur so, als könne sich aus irgendeinem Grund nichts über rsyslog anmelden. Und eine zweite identische VM auf demselben Host (die nicht den gleichen Kreis von wiederholtem Deaktivieren von ntp durchlief, wobei das Datum mehrmals geändert und neu gestartet wurde) mit derselben rsyslog.conf-Datei protokolliert einwandfrei.

Zu diesem Zeitpunkt ist das Datum / die Uhrzeit korrekt, Chronik ist aktiviert und läuft, und ich habe mehrmals neu gestartet - nach 30 Sekunden Kernelmeldungen wird nichts anderes mehr protokolliert.

Gedanken?

systemd syslog rsyslog

— Arkandel
quelle

Ich habe RHEL7 noch nie benutzt, aber ich würde es /etc/rsyslog.confund die /etc/rsyslog.dVerzeichnisse überprüfen . Es hört sich so an, als ob Sie nichts konfiguriert haben, um an eine bestimmte Protokolldatei weitergeleitet zu werden. Sie können auch versuchen, eine Syslog-Nachricht mit EMERGPriorität anzugeben, um festzustellen , ob dies erfolgreich ist. Beispiel:logger -p EMERG not really an emergency

— Bratchley

/etc/rsyslog.conf enthält Folgendes: * .info; mail.none; authpriv.none; cron.none; local0.none / var / log / messages : $ SystemLogSocketName / run / systemd / journal / syslog und rate-unlimit.conf dies: $ SystemLogRateLimitInterval 0 $ SystemLogRateLimitBurst 0 Wie für die EMERG-Priorität wird es auch nicht protokolliert.

— Arkandel

Sie sollten wahrscheinlich entweder Ihre Antwort oder Ihren Pastebin aktualisieren, da wir dort die Zeilenumbrüche verloren haben.

— Bratchley

Das tut mir leid. Aus irgendeinem Grund werden Zeilenvorschübe in Kommentaren nicht analysiert. Wenn ich dies in rsyslog.conf auskommentiere, ist die Protokollierung wieder aktiviert: $ OmitLocalLogging on. Auf meiner anderen identischen VM auf demselben Host ist sie jedoch nicht auskommentiert und die Protokollierung funktioniert einwandfrei.

— Arkandel

Anscheinend ist dies eine Option für systemd(auf die RHEL7 migriert ist, IIRC). Können Sie überprüfen journalctl -b, ob Ihre Protokolle in das systemd-Journal geschrieben werden?

— Bratchley

Antworten:

Keine direkte Lösung, aber ich würde das Debuggen aktivieren, um zu sehen, was hinter den Kulissen passiert.

Idee Nr. 1 - Debugging von Loggern

Für den Anfang, wenn Sie Ihre loggerBefehle ausführen, können Sie diese wie folgt ausführen und Nachrichten an STDERR ausgeben.

$ logger -s "hi"
saml: hi

Idee Nr. 2 - Überprüfen Sie Ihre Konfigurationsdatei

Sie können auch versuchen, Ihre rsyslog-Konfigurationsdatei zu überprüfen:

$ sudo rsyslogd -N6 | head -10
rsyslogd: version 7.2.6, config validation run (level 6), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

6921.173842409:7f8b11df2780: rsyslogd 7.2.6 startup, module path '', cwd:/root
6921.175241008:7f8b11df2780: caller requested object 'net', not found (iRet -3003)
6921.175261977:7f8b11df2780: Requested to load module 'lmnet'
6921.175272711:7f8b11df2780: loading module '/lib64/rsyslog/lmnet.so'
6921.175505384:7f8b11df2780: module lmnet of type 2 being loaded (keepType=0).
6921.175520208:7f8b11df2780: entry point 'isCompatibleWithFeature' not present in module
6921.175528413:7f8b11df2780: entry point 'setModCnf' not present in module
6921.175535294:7f8b11df2780: entry point 'getModCnfName' not present in module
6921.175541502:7f8b11df2780: entry point 'beginCnfLoad' not present in module

Idee 3 - Aktivieren Sie das rsyslogd-Debugging

Außerdem würde ich versuchen, das Debuggen des rsyslogdDämons zu aktivieren, um weitere Informationen zu erhalten.

$ sudo -i
$ export RSYSLOG_DEBUGLOG="/tmp/debuglog"
$ export RSYSLOG_DEBUG="Debug"

$ service rsyslog stop
$ rsyslogd -d | head -10    
7160.005597645:7fae096a3780: rsyslogd 7.2.6 startup, module path '', cwd:/root
7160.005872662:7fae096a3780: caller requested object 'net', not found (iRet -3003)
7160.005895004:7fae096a3780: Requested to load module 'lmnet'
7160.005906331:7fae096a3780: loading module '/lib64/rsyslog/lmnet.so'
7160.006023505:7fae096a3780: module lmnet of type 2 being loaded (keepType=0).
7160.006030872:7fae096a3780: entry point 'isCompatibleWithFeature' not present in module
7160.006033780:7fae096a3780: entry point 'setModCnf' not present in module
7160.006036209:7fae096a3780: entry point 'getModCnfName' not present in module
7160.006038359:7fae096a3780: entry point 'beginCnfLoad' not present in module
...
...
7160.006063913:7fae096a3780: rsyslog runtime initialized, version 7.2.6, current users 1
7160.006102179:7fae096a3780: source file syslogd.c requested reference for module 'lmnet', reference count now 2
7160.006113657:7fae096a3780: GenerateLocalHostName uses 'greeneggs'

Versionsinformationen bestätigen

$ rsyslogd -version
rsyslogd 7.2.6, compiled with:
    FEATURE_REGEXP:             Yes
    FEATURE_LARGEFILE:          No
    GSSAPI Kerberos 5 support:      Yes
    FEATURE_DEBUG (debug build, slow code): No
    32bit Atomic operations supported:  Yes
    64bit Atomic operations supported:  Yes
    Runtime Instrumentation (slow code):    No
    uuid support:               Yes

See http://www.rsyslog.com for more information.

Bestätigter Fehler und eine Problemumgehung

Das OP reichte dies als Fehler bei Red Hat ein.

Fehler 1088021 - Durch Ändern der Uhrzeit eines VM-Hosts wird die Protokollierung von rsyslog-Dateien deaktiviert .

Der Fehler wurde wie folgt charakterisiert:

Sicher genug, wenn ich die eigene Zeit des Hosts einstellte, hatte die VM dieselbe falsche Zeit wie der Host. Zu diesem Zeitpunkt bemerkte ich, dass / var / log / messages nicht mehr aktualisiert wurde.

Es stellt sich heraus, dass nichts anderes als ein Neustart des rsyslog-Dienstes selbst zu diesem Zeitpunkt in Dateien protokolliert wird. Wenn ich das tue, wird dies protokolliert:
  ---
   Apr 15 16:39:39 rhel7time-dev rsyslogd-3000: sd_journal_get_cursor() failed: 'Cannot assign requested address'

  Apr 15 16:39:39 rhel7time-dev rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="574" x-info="http://www.rsyslog.com"] exiting on signal 15.
  Apr 15 16:39:39 rhel7time-dev rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="2117" x-info="http://www.rsyslog.com"] start
  ---
Andernfalls wird nichts in der Datei protokolliert, einschließlich des Protokollierers.

Wenn ich $ OmitLocalLogging in rsyslog.conf auskommentiere, wird die Dateiprotokollierung fortgesetzt (beachten Sie, dass ich rsyslog.conf bis dahin nicht geändert habe).

Die Protokollierung durch das Journal bleibt davon unberührt. journalctl -b zeigt die Protokollierung an, einschließlich aller vom Logger gesendeten Daten.

Auf die einer der Entwickler geantwortet hat:

Wenn dieses Problem auftritt, können Sie /var/lib/rsyslog/imjournal.stateden Dämon löschen und neu starten, um dieses Problem zu umgehen.

rsyslog verarbeitet das Datum nicht direkt, sondern nur über die systemd-API. Ich habe den Code vor einiger Zeit imjournal überprüft und dies scheint ein Problem in systemd zu sein.

Informationen hierzu finden Sie unter: https://github.com/rsyslog/rsyslog/issues/43

— slm
quelle

Ich brachte dies als Fehlerbericht auf und erhielt eine Antwort von RedHat. Details finden Sie unter bugzilla.redhat.com/show_bug.cgi?id=1088021 . Dies ist vorerst geschlossen, danke an alle für Ihre Hilfe. :)

— Arkandel

@Arkandel - danke, dass du die Schleife geschlossen hast. Ich habe Ihre Erkenntnisse und die Problemumgehung in dieses A aufgenommen, damit wir den Q & A-Zyklus als gelöst abschließen können (zumindest in dem Sinne, dass es sich um einen bestätigten Fehler mit einer Problemumgehung handelt). Bitte markieren Sie dieses A als akzeptiert, wenn Sie mit dieser Zusammenfassung einverstanden sind.

— SLM

In meinem Fall systemctl restart systemd-journaldgeholfen, weil

File /run/log/journal/29c32d60f93c42489aabb4ebeb593f5b/system.journal corrupted or uncleanly shut down, renaming and replacing.
[12274404.541271] systemd-journald[15492]: Deleted empty journal /run/log/journal/29c32d60f93c42489aabb4ebeb593f5b/system@0005317804680d96-e103c48634d16856.journal~ (4096 bytes).

— Valentina
quelle

Versuchen Sie, rsyslog conf zu überprüfen mit: rsyslogd -f /etc/rsyslog.conf -N 1
Wenn alles in Ordnung ist, versuchen Sie, systemd-journald.socket neu zu starten mit: systemctl restart systemd-journald.socket können
Sie den Befehl " logger " verwenden, um zu überprüfen ob rsyslog funktioniert oder nicht: logger "hallo"

— S.Bao
quelle