I've setup a couple of "at" jobs to execute at specific times on CentOS 5. This morning I don't see these commands in the queue ("atq"), as expected, but I also don't see were can I check whether the daemon responsible to execute them did this on time or had any issues. Unfortunately I didn't log enough info from the scripts themselves. Any ideas?
-
To those who marked this as a duplicate - the pointed answer was about setting up logging before the command is executed. My question is about digging up logs after the fact. – Amos Shapira Apr 10 '19 at 03:54
1 Answers
From looking at the source of the 'at' program (from the CentOS 5.3 source repository) , it looks like it is indeed logging to syslog, but only fatal errors regarding the at daemon itself are logged (for example, if you try to run 2 at daemons at the same time).
However, process executions, resulting return code and standard error/output are not logged to syslog at all. Even when turning on debug (which requires recompilation) the log messages are not very informative (for end users) and write something like :
atd[24116]: pid 24121 exited with status 0.
Which will not help you a lot in identifying which command was ran, by which user or what was its standard output/error.
atd does send an email notification to the user who requested the command, in case the command had failed, or produced anything in it's standard output/error. But for commands that succeed without any output , no mail is sent. You can change that using the -m flag.
From at(1):
-m Send mail to the user when the job has completed even if there was no output.
Borrowed from Tom Feiner's answer from almost an identical question.
- 3,409
- 3
- 21
- 38
-
At typically logs to syslog on all *nix systems I've encountered. The facility may vary: there isn't a dedicated one. I've seen `daemon` and `cron` used – voretaq7 Aug 18 '11 at 03:31
-
Thanks for both of you for your answers. You confirmed what I suspected - if my commands don't have extra-logging then at's own logging isn't going to help. However - grep'ing for "atd" through the compressed "/var/log/messages*.gz" I found hints for the execution happening by form of PAM logs at the expected times. Although this isn't conclusive at least something happened when it was expected. – Amos Shapira Aug 19 '11 at 05:00