LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 09-01-2012, 11:44 AM   #1
Barcoboy
LQ Newbie
 
Registered: May 2010
Distribution: Slackware
Posts: 27

Rep: Reputation: Disabled
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.
 
Old 09-06-2012, 01:38 PM   #2
Barcoboy
LQ Newbie
 
Registered: May 2010
Distribution: Slackware
Posts: 27

Original Poster
Rep: Reputation: Disabled
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.
 
Old 09-06-2012, 02:26 PM   #3
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,251

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
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.
 
Old 09-06-2012, 02:31 PM   #4
GazL
Senior Member
 
Registered: May 2008
Posts: 3,231

Rep: Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828
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?
Code:
--- run-parts.orig      2012-09-06 20:15:20.149169417 +0100
+++ run-parts   2012-09-06 20:24:04.202435688 +0100
@@ -39,7 +39,9 @@
   fi
   # If we've made it this far, then run the script if it's executable:
   if [ -x $SCRIPT ]; then
-    $SCRIPT 1>&2 || echo "$SCRIPT failed."
+    OUTPUT="$(mktemp /tmp/run-parts.XXXXXX)"
+    $SCRIPT > "$OUTPUT" 2>&1 || { echo "$SCRIPT failed." ; cat "$OUTPUT" ; } >&2
+    rm "$OUTPUT"
   fi
 done
... 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.

Last edited by GazL; 09-06-2012 at 03:14 PM. Reason: reverted to first version.
 
Old 09-06-2012, 03:19 PM   #5
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,251

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
Looks like you have discovered the difference in behavior.

I diffed run-parts from 13.1 and 14:

Code:
--- 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 @@
   fi
   # If we've made it this far, then run the script if it's executable:
   if [ -x $SCRIPT ]; then
-    echo "$SCRIPT:"
-    echo
-    $SCRIPT 2>&1
-    echo
+    $SCRIPT 1>&2 || echo "$SCRIPT failed."
   fi
 done
Possibly

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

is a typing transposition error and should be

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

like previous releases?
 
Old 09-06-2012, 03:59 PM   #6
GazL
Senior Member
 
Registered: May 2008
Posts: 3,231

Rep: Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828
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.
 
Old 09-06-2012, 06:36 PM   #7
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,251

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
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.
 
Old 09-07-2012, 02:46 AM   #8
NoStressHQ
Member
 
Registered: Apr 2010
Location: Lausanne - Switzerland ( Bordeaux - France / Montreal - QC - Canada)
Distribution: Slackware Leet - 32/64bit
Posts: 271

Rep: Reputation: 87
No it should be

Code:
$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.

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).

Last edited by NoStressHQ; 09-07-2012 at 04:14 AM.
 
Old 09-07-2012, 10:38 AM   #9
Barcoboy
LQ Newbie
 
Registered: May 2010
Distribution: Slackware
Posts: 27

Original Poster
Rep: Reputation: Disabled
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.
 
Old 09-07-2012, 10:41 AM   #10
Barcoboy
LQ Newbie
 
Registered: May 2010
Distribution: Slackware
Posts: 27

Original Poster
Rep: Reputation: Disabled
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"?
 
Old 09-08-2012, 11:49 AM   #11
Barcoboy
LQ Newbie
 
Registered: May 2010
Distribution: Slackware
Posts: 27

Original Poster
Rep: Reputation: Disabled
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:

Code:
$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!

Last edited by Barcoboy; 09-08-2012 at 11:52 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
dcron - run script last friday of month cotton213 Linux - Software 7 06-25-2012 04:03 PM
What does the run-parts mean in crontab? mTorbin Linux - Newbie 15 04-27-2012 03:53 PM
need run-parts run in reverse. jukemann Linux - General 4 01-10-2007 09:41 AM
run-parts not reading all possible scripts merana Debian 6 12-28-2005 09:40 AM
crontab and run-parts gavinbeatty Slackware 4 09-13-2005 06:56 PM


All times are GMT -5. The time now is 12:08 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration