CRON problem: (rsync: Failed to exec ssh: Permission denied (13))
FedoraThis forum is for the discussion of the Fedora Project.
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.
(I asume that I do not have to convince you guys that vars are correct? ;-) )
as stated, this work good when I run it manualy from prompt.
But it does not works when executed from cron. What is wrong with this script? What did I forgot, of what I am NOT aware of?
As I use Webmin to administer my server, lazy ass I am, I know, when I run this job there manualy I get:
Output from command /some_correct_path/rsync.sh ..
rsync: Failed to exec ssh: Permission denied (13)
rsync error: error in IPC code (code 14) at pipe.c(86) [receiver=2.6.9]
rsync: writefd_unbuffered failed to write 4 bytes [receiver]: Broken pipe (32)
rsync error: error in IPC code (code 14) at io.c(1122) [receiver=2.6.9]
Is there anyone who could assist on this? All help is more then welcome :-)
Jobs in cron don't have the same environment variables that ones you run from the command line do. This is because it isn't really "logged in" so runs a minimally configured environment.
The most common cause of problems is PATH. If your script doesn't know where "rsync" and "ssh" are it can't execute them. Try specifying full path to each of these commands in the script or setting them up as variables that have the full pathname so you just use the variable in the command line.
Is the cron job being run as the same user you run from at command line. (i.e. is it the root user when you're running from command line and is this in root's crontab?) ssh trusts are typically done per user.
Also you might want to add an echo line to verify all your variables are what you think they are in the script. Perhaps one of them isn't being set the way you think it is? (SOURCESRV, SOURCEDIR etc...)
This may be making things redundant, and I'll be the first to admit I don't know exactly what is and isn't allowed to be listed as a cron event, but what if you created a text file, added the line of your command to it, made that file executable (a "script," even though it's a one-liner) and then called THAT from cron?
That is, make a text file, perhaps called "rsyncjob" with just this in it:
rsync -e "ssh -i $SSHKEY" $SOURCESRV/$SOURCEDIR $DESTDIR/$DESTDIR
Then "chmod +x rsyncjob."
Then in your crontab instead of the big drawn-out command, simply do:
15 12 * * 1-5 /home/path/to/rsyncjob
Again, if that's making things redundant and I am just showing my cron/script naivete, forgive me, but that's probably what I would try if I were faced with a similar situation.
Edited: Part of the reason I think this way is that I run rsnapshot, which is basically an rsync wrapper, and the script I have cron run also includes writing the date out to a log file, then running rsnapshot, then writing to the log file that it has finished, if that makes any sense...
First of all I would like to thank you for all advice.
Even all sugestions I see here are more or less familiar for me it looks like it is still something else that I overlooked.
Last aproach sugested by griffey is mine preferd aproach to solve a problem: minimize as possible to locate problem faster. jlightner says what I was kinda aware of and I totaly follow his path, I still not there...
Other problem I have with testing it, that it is a cron job so it runs now and then. and bigest problem is that it works manualy... ;-) So I will try to do some other tricks and see whats it wil lrusult in. I will keep you informed guys
You can temporarily set it in cron to run 'soon', then comment it out in crontab whilst you analyse the results eg if it's now 10:23, set crontab
30 10 * * * mytest.sh >/home/me/mytest.out 2>&1
let it run, then comment it out.
At the 2nd line of the shell file, use
which will display all vars as they are used and their translations.
As mentioned, which user it runs as is also significant.