CentOS - Dec 2010 - difference between cron and shell invocation.

I have a fairly involved root cron task that I moved verbatim from
another server. On the original server, this task ran without
problem.  On the new server, when this task runs via cron, which I
confirm is happening by looking in the cron log, no files are
transferred and no error is reported.  However, if I copy cron
command from roots crontab and paste it into a terminal session on
the new server then the task runs to completion and the files are
transferred.

This task involves sshfs, fuse, and rsync and employs pki
certificates for authentication.  The fact that it works from the
shell without alteration and yet not from cron is the issue.

Does anyone have any idea where I would start to track down what is
going on?



-- 
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

James B. Byrne wrote:
>
> I have a fairly involved root cron task that I moved verbatim from
> another server. On the original server, this task ran without
> problem.  On the new server, when this task runs via cron, which I
> confirm is happening by looking in the cron log, no files are
> transferred and no error is reported.  However, if I copy cron
> command from roots crontab and paste it into a terminal session on
> the new server then the task runs to completion and the files are
> transferred.
>
> This task involves sshfs, fuse, and rsync and employs pki
> certificates for authentication.  The fact that it works from the
> shell without alteration and yet not from cron is the issue.
>
> Does anyone have any idea where I would start to track down what is
> going on?
Sure - it's pretty obvious that something in the environment is missing.
Try putting env in the cron job, or run the actual job as a shell script,
and in the script, put env and pipe that to a file, so that you can then
compare that with your env o/p as root.

          mark

On Tuesday 07 December 2010 14:34:33 James B. Byrne
wrote:
> I have a fairly involved root cron task that I moved verbatim from
> another server. On the original server, this task ran without
> problem.  On the new server, when this task runs via cron, which I
> confirm is happening by looking in the cron log, no files are
> transferred and no error is reported.  However, if I copy cron
> command from roots crontab and paste it into a terminal session on
> the new server then the task runs to completion and the files are
> transferred.
> 
> This task involves sshfs, fuse, and rsync and employs pki
> certificates for authentication.  The fact that it works from the
> shell without alteration and yet not from cron is the issue.
> 
> Does anyone have any idea where I would start to track down what is
> going on?
Check the paths in cron. They are not necessarly the same as the paths for the 
shell.

Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos/attachments/20101207/e37769e6/attachment-0002.html>

At Tue, 7 Dec 2010 09:34:33 -0500 (EST) CentOS mailing list <centos at
centos.org> wrote:
> 
> 
> I have a fairly involved root cron task that I moved verbatim from
> another server. On the original server, this task ran without
> problem.  On the new server, when this task runs via cron, which I
> confirm is happening by looking in the cron log, no files are
> transferred and no error is reported.  However, if I copy cron
> command from roots crontab and paste it into a terminal session on
> the new server then the task runs to completion and the files are
> transferred.
> 
> This task involves sshfs, fuse, and rsync and employs pki
> certificates for authentication.  The fact that it works from the
> shell without alteration and yet not from cron is the issue.
> 
> Does anyone have any idea where I would start to track down what is
> going on?
Things to check:

Environment issues: PATH, SHELL, etc.

I would put in calls to logger and/or echo to log what is going on. 
Adding a '-v' (verbose flag) to selected commands to generate additional
debug information can also help.

Is anything making use of stdin?

Does the script still work if you do something like from an interactive
shell?:

</dev/null ./script

Is anything dependent on having access to an actual console device (eg
/dev/tty)?  That is, are any of the programs trying to be interactive?

What are you doing about stderr's channel?  Does adding
'2>&1' to the
command in crontab prove enlightening?
> 
> 
> 
-- 
Robert Heller             -- 978-544-6933 / heller at deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

On Tue, December 7, 2010 09:49, Brent L. Bates wrote:
>      If you aren't already doing so, use the full path to the
> commands you are
I have done as you suggest and that indeed has solved the problem. 
Thank you very much.

Regards,

-- 
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Question.  In a chained cron job like this:

sshfs  .  .  . && /usr/bin/rsync .  .  . | /bin/mail -s .  .  .
&& .
 .  .

Is there anyway to get a failure message from the first part to be
emailed or logged?

Given the resolution of this problem I gather that sshfs must not
have been found and therefore I would expect an error to be reported
somewhere.  The chained commands evidently interfered with the
propagation of this error which would have immediately identified
the source of the problem. Is it possible to get errors from the
individual parts of such chained commands forwarded to an email
address, or logged in the system log, or both?

-- 
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3