SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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.
Looks like you have discovered the difference in behavior.
I diffed run-parts from 13.1 and 14:
--- 13.1/usr/bin/run-parts 2010-02-12 19:47:13.000000000 -0600
+++ 14.0/usr/bin/run-parts 2012-08-09 02:09:39.000000000 -0500
@@ -39,10 +39,7 @@
# If we've made it this far, then run the script if it's executable:
if [ -x $SCRIPT ]; then
- echo "$SCRIPT:"
- $SCRIPT 2>&1
+ $SCRIPT 1>&2 || echo "$SCRIPT failed."
Location: Lausanne - Switzerland ( Bordeaux - France / Montreal - QC - Canada)
Distribution: Slackware Leet - 32/64bit
No it should be
$SCRIPT || echo "$SCRIPT failed" 1>&2
# more 'explicitly' it should run as:
$SCRIPT || ( echo "$SCRIPT failed" 1>&2 )
'$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.
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).
Last edited by NoStressHQ; 09-07-2012 at 05:14 AM.
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.
And now I see Pat has updated the changelog saying that crontab is once again responsible for redirecting the output of run-parts:
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:
$SCRIPT || echo "$SCRIPT failed."
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!