Protokollieren von atd-Meldungen über Syslog

Protokollieren von atd-Meldungen über Syslog

Ich verwende CentOS 5.3 und möchte alle Nachrichten vom "at"-Daemon protokollieren. Meine syslog.conf enthält den folgenden Eintrag:

cron.* /var/log/cron

Ich bin davon ausgegangen, dass sich die Cron-Zeile im Syslog auf die gesamte Familie von „cron, anacron, at und batch“ bezieht. Während Cron- und Anacron-Aktionen jedoch protokolliert zu werden scheinen, werden „at“-Aktionen nicht protokolliert. Wie protokolliere ich atd-Aktionen?

Danke für Ihre Aufmerksamkeit

(Hinzugefügt) Ich möchte den Inhalt meiner syslog.conf hinzufügen, nur für den Fall, dass ein Fehler auftritt:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                         /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none        /var/log/messages

# The authpriv file has restricted access.
authpriv.*                      /var/log/secure

# Log all the mail messages in one place.
mail.*                          -/var/log/maillog


# Log cron stuff
cron.*                          /var/log/cron

# Everybody gets emergency messages
*.emerg                         *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                      /var/log/spooler

# Save boot messages also to boot.log
local7.*                        /var/log/boot.log

Antwort1

Aus der Betrachtung der Quelle des 'at'-Programms (aus dem CentOS 5.3 Quell-Repository) sieht es so aus, als ob es tatsächlich ins Syslog protokolliert wird, aber es werden nur schwerwiegende Fehler in Bezug auf den At-Daemon selbst protokolliert (z. B. wenn Sie versuchen, zwei At-Daemons gleichzeitig auszuführen).

Prozessausführungen, resultierende Rückgabecodes und Standardfehler/-ausgaben werden jedoch überhaupt nicht in Syslog protokolliert. Selbst wenn Debug aktiviert wird (was eine Neukompilierung erfordert), sind die Protokollmeldungen nicht sehr informativ (für Endbenutzer) und enthalten etwa Folgendes:

atd[24116]: pid 24121 exited with status 0.

Dies hilft Ihnen jedoch nicht viel dabei, herauszufinden, welcher Befehl von welchem ​​Benutzer ausgeführt wurde oder was die Standardausgabe/der Standardfehler war.

atdtutSenden Sie eine E-Mail-Benachrichtigung an den Benutzer, der den Befehl angefordert hat, falls der Befehl fehlgeschlagen ist oder etwas in seiner Standardausgabe/Fehlermeldung erzeugt hat. Für Befehle, die erfolgreich sind, ohne eine Ausgabe zu erhalten, wird jedoch keine E-Mail gesendet. Sie können dies mit dem Flag -m ändern.

Ausum 1):

-m Senden Sie dem Benutzer eine E-Mail, wenn der Job abgeschlossen ist, auch wenn keine Ausgabe erfolgte.

Antwort2

In solchen Fällen verwende ich einen Wrapper um den Befehl, der ins Syslog protokolliert. Beispiel:

#!/bin/bash
logger -i -t mycmd Starting
/bin/somecommand
logger -i -t mycmd Completed
exit 0

Dann rufe ich stattdessen von cron, at usw. das Wrapper-Skript auf.

Ich weiß, dass dies eher ein Workaround als eine Lösung ist, aber es erfüllt seinen Zweck.

Antwort3

/var/log/sicher(RHEL)

atd protokolliert über PAM. Überprüfen Sie Ihre syslog.conf, um herauszufinden, wohin PAM protokolliert.

Antwort4

Entsprechendatd(8), es protokolliert bereits in Syslog, Sie müssen nur sicherstellen, dass Sie keine fehlerhaften Syslog-Regeln haben.

Posten Sie Ihre syslog.confDatei vielleicht zuerst hier.

Beachten Sie auch, dass atddie Festlegung einer bestimmten Protokollfunktion nicht konfigurierbar ist. Dies sollte jedoch kein Problem darstellen. Sie müssen lediglich sicherstellen, dass Ihre Syslog-Konfiguration richtig ist.

verwandte Informationen