dcron and run-parts
 

Can someone please explain to me the intended behavior of dcron and run-parts? Up until a few updates ago, Slackware-current had been only emailing me output of jobs under /etc/hourly, /etc/daily, etc. (pun intended) only if the job output something to stderr... now I'm getting all stdout output even though "crontab -e" shows run-parts running with stdout redirected to /dev/null.

Anybody?

I don't think this should be left in its current state without either fixing how run-parts outputs data (ie: go back to the old way it used to work), or changing the default crontab file comments at the top and removing all of the stdout redirects to /dev/null. I'm afraid though that it's probably to late to fix it for Slack 14.

I'm unsure we're discussing the same problem, but I confirm something different with email behavior. I have seen that different behavior on only one Slackware 14 system. I was receiving emails whereas with the same crontab on other Slackware systems (12.2, 13.1, 13.37, etc.) I never received emails.

I have four Slackware 14 systems, all used at the moment for testing (none yet used for production). On the one system that exhibited the behavior, I resolved the problem by changing in crontab all occurences of 1>/dev/null to &>/dev/null.

I don't know why the other three systems have not exhibited the same behavior. Possibly the emails I received had changed and were issued as stderr rather than stdout. I'll keep watch and post anything I discover.

I'm not really sure what Pat's intentions are with that $SCRIPT 1>&2 at the bottom of run-parts. It does feel wrong to me though to redirect stdout to stderr.

Maybe something like this is the way to go?
... if the script fails you get stdout and stderr sent to stderr. If it works you get nothing.


Update: Seems to work for a little noddy test script dropped in cron.hourly.

Looks like you have discovered the difference in behavior. :)

I diffed run-parts from 13.1 and 14:

Possibly

$SCRIPT 1>&2 || echo "$SCRIPT failed.

is a typing transposition error and should be

$SCRIPT 2>&1 || echo "$SCRIPT failed.

like previous releases?

Could be a transposition I suppose, but we're just guessing. Either way, that echo looks like it ought to have a >&2 on the end of it.


Anyway, I've decided I like the behaviour that my above patch implements so I think I'm going to leave that one in-place here.

I don't know the reason for the change. The Thu Aug 9 22:34:59 UTC 2012 change log records the change:

a/dcron-4.5-x86_64-2.txz: Rebuilt.
Fixed error handling in /usr/bin/run-parts.
Thanks to NoStressHQ.

I suspect the reason is discussed here:

https://www.linuxquestions.org/quest...ng-4175418742/

I contacted Pat about this thread. He is changing the script:

$SCRIPT 1> /dev/null || echo "$SCRIPT failed."

Watch the next change log. :)

No it should be

'$SCRIPT' output shouldn't be changed, only the additional message should be redirected to stderr...

After that it's up to the called script not to output stdin (&1) if there's no error.

That's all.

Edit: Sorry not to have seen this thread earlier, I was quite busy.

Edit2: Of course all this must be coherent with each tool/script return code, if a script fails it should return a code !=0 whereas if it succeed ==0...

Edit3: After some thoughts, redirecting stdout to /dev/null should fix part of the problem (but then we might lose some info, but says it's ok), anyway the 'echo' should be send to stderr AND in this case, the run parts should returns an error code maybe (unless we want silently handle error, but I guess it's not what we expect as a standard).

OK thanks everybody, that did the trick.

Now the only thing left to do at some point is to remove the "1> /dev/null" from the run-parts jobs in the default root crontab file, as they are no longer needed. I guess it doesn't hurt to leave them there though.

Also, the comments at the top of the crontab file will need to change to reflect the new behavior. What about something like:

# If you don't want the output of a cron job mailed to you, you have to direct
# all output to /dev/null. We don't do this here since these jobs should run
# properly on a newly installed system.

Again, it won't break anything if this isn't changed.

Hmmm... just re-reading my last post... probably shouldn't say "don't do". Maybe "won't do" would be better? Or "This isn't necessary here"?

And now I see Pat has updated the changelog saying that crontab is once again responsible for redirecting the output of run-parts:

a/dcron-4.5-i486-4.txz: Rebuilt.
After following the discussion about it on LQ, it seems better to not
direct script output in run-parts to /dev/null, since the default crontab
does that already. That way if someone wants to get cron job output
mailed to them it's easy to do by editing the crontab. Thanks to NoStressHQ.

Now the line in run-parts has changed to:

That does make the most sense to me, and is how I thought this system ran in the first place, which is why I posted my first post initially when it broke.

Guess I can mark this thread as solved. Thanks Pat!