Created attachment 396590 [details, diff] Add code to display script name for cron.{h,d,w,m}* If there are a lot of scripts in the hourly/daily/weekly/monthly cron directories, it can become very difficult to hunt down which script a particular message comes from. This patch prefixes script output with the name and exit status of the script that was run. This also changes behavior fro scripts that exit with non-zero status but no output. Previously, there would be no message indicating the (possible) failure. To recreate that behaviour (and only send messages on output being non-empty), those scripts can be amended with an unconditional "exit 0" or similar.
Comment on attachment 396590 [details, diff] Add code to display script name for cron.{h,d,w,m}* this doesn't actually send output to the syslog that i can see, and it relies on the non-standard `tempfile` from debianutils, and the tempfile handling looks racy (security), and the stat call is not needed if we don't handle the no-output scenario, it makes the code much easier: $SCRIPT |& logger -i -p cron.info -t "run-crons.$SCRIPT" ret=${PIPESTATUS[0]} if [[ ${ret} -ne 0 ]] ; then logger -i -p cron.info -t run-crons "(`whoami`) EXIT ${ret} ($SCRIPT)" fi
(In reply to SpanKY from comment #1) > Comment on attachment 396590 [details, diff] [details, diff] > Add code to display script name for cron.{h,d,w,m}* > > this doesn't actually send output to the syslog that i can see, and it > relies on the non-standard `tempfile` from debianutils, and the tempfile > handling looks racy (security), and the stat call is not needed Tempfile itself is not racy. And the &> redirect/truncate is atomic, so I don't see where the race would happen. But the dep on debianutils would be bad, yes. > if we don't handle the no-output scenario, it makes the code much easier: > $SCRIPT |& logger -i -p cron.info -t "run-crons.$SCRIPT" > ret=${PIPESTATUS[0]} > if [[ ${ret} -ne 0 ]] ; then > logger -i -p cron.info -t run-crons "(`whoami`) EXIT ${ret} ($SCRIPT)" > fi This would write to some logfile, whereas usually, failing cron jobs generate mails. I know I don't browse cron log files for failures and I'd rather not have to set up another logwatcher. Note that there is also the short solution of bug 553294, which may be the best compromise.
(In reply to Tobias Klausmann from comment #2) one command creates the file while another opens/writes while another opens/reads it. those are not atomic operations. i forgot about the e-mail aspect as i focus on logging personally. i thought of doing a sed on the output directly but didn't feel like getting into handling the escape character correctly (bug 553294 fails when the script contains a | for example). but if that satisfies your request, we can go that route as it is better as it maintains the streaming aspect and doesn't require any tempfile usage. we can also carry over the PIPESTATUS check: $SCRIPT 2>&1 | sed -e "s/^/${SCRIPT##*/}: /" ret=${PIPESTATUS[0]} if [[ ${ret} -ne 0 ]] ; then logger -i -p cron.info -t run-crons "(`whoami`) EXIT ${ret} ($SCRIPT)" echo "run-crons: $SCRIPT exited with ${ret}" fi
cronbase-0.3.5 now does a syslog for each failing script, so there's at least some visibility now
Created attachment 407374 [details, diff] Use appropriate priority when logging through logger I would suggest to *not* hard code syslog's severity level in the new log() function because a failure should probably use cron.err instead of cron.info which allows the user to use the correct log filter mechanism when looking for failures/problems.
Commit message: Use err level when logging failed scripts http://sources.gentoo.org/sys-process/cronbase/cronbase-0.3.5-r1.ebuild?rev=1.1 http://sources.gentoo.org/sys-process/cronbase/files/run-crons-0.3.5?r1=1.1&r2=1.2
*** Bug 553294 has been marked as a duplicate of this bug. ***
[taken from bug 553294] it would be nice to just do: $SCRIPT 2>&1 | sed "1i${SCRIPT}:" if $SCRIPT produces no output, then sed won't do anything, but as soon as it produces at least one line, sed will add a header like: /etc/cron.daily/foo: unfortunately though, this now conflicts with bug 491520 where we track the exit status and bug 530416 where we use POSIX shell (so we can't check PIPESTATUS).
Can't we provide a useflag depending on bash by which script would be patched?
There's also a POSIX solution for the problem: http://stackoverflow.com/a/8925688 although it's ugly.
