Hello the interesting line in my crontab looks like this: (edited & saved it by running crontab -e)
23 * * * * rsync -av --delete [email protected]:/var/www/ /home/niklas >> /home/niklas/scripts/logfile
but .. this line does nothing (at the 24th minute no bandwidth is used, no output is in the logfile) can someone tell me what is wrong?
BTW: the authentification for the server works via a passwordless pgp key. that is why the user needs to be 'niklas'
EDIT:
ran type rsync
which returned /usr/bin/rsync
but that is already on the path:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
EDIT2:
created /usr/bin/backup containing:
rsync -av --delete [email protected]:/var/www/ /home/niklas/server4you_www >> /home/niklas/scripts/logfile
chmod +x'ed it and changed the entry in chrontab to
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
16 * * * * /usr/bin/backup
still... its not working, though /var/log/syslog sais:
Aug 1 15:16:01 niklas-desktop CRON[9421]: (niklas) CMD (/usr/bin/backup)
please help
EDIT3:
Changing
rsync -av --delete [email protected]:/var/www/ /home/niklas/server4you_www >> /home/niklas/scripts/logfile
to
/usr/bin/rsync -av --delete [email protected]:/var/www/ /home/niklas/server4you_www >> /home/niklas/scripts/logfile
as expected does not alter the (unsatisfying) result. however `putting echo 'xyz' > log writes xyz into the log file
so... as you might guess... my issue is still not resolved.
adding a || echo "rsync died with error code $?"
to the backup script returned:
rsync died with error code 5
which as http://wpkg.org/Rsync_exit_codes suggests means "Error starting client-server protocol" so i guess something is fishy about ssh. again i am using a pgp key with a password but that password is by default unlocked by the keyring on startup so that i can ssh [email protected] without entering a password. Is it possible to send rsync the password of the ssh key?
You included a user name field in your crontab. But that field only exists in the system crontab (
/etc/crontab
), not in the per-user crontab that you edit withcrontab -e
. So edit the crontab withcrontab -e
as userniklas
, and make the contentsThe user you ran
crontab -e
as should have received a mail with an error message (complaining thatniklas
is not a valid command). If it didn't, there may be a problem in your mail setup.Put full path to rsync even to your /usr/bin/backup, so the line in that file would start
And try to put a line like
to your /usr/bin/backup script and see if anything gets logged to /var/log/messages (or other log file, depending on your syslog setup). Alternatively you might replace the logger with
Oh, sometimes SELinux might cause problems like you have encountered. Is it in use?
Hope this helps.
EDIT: Make your /usr/bin/backup rsync line be like
Perhaps we'll catch why rsync is so upset.
YET ANOTHER EDIT: OK, rsync error code 5. That means
Most of the time that happens due the wrong password, even though the message looks more cryptic.
If you manually run your rsync script as niklas, that works, right?
EDIT 3: Spotted your mention about keyring. I think cron doesn't use the same keyring than the user niklas during your login. That's why the login goes p00f when trying to run it from cron. Could you use a passwordless RSA key for this instead and just restrict it to run rsync?
EDIT 4: Use RSYNC_PASSWORD environment variable. That can be done by putting this to top of your backup script:
or if you would like to store the password in a textfile, create a file and provide a --password-file option to rsync.
If that doesn't work, you may provide -e 'ssh -o IdentityFile=/path/to/your_file option to rsync.
You might need the full path for the rsync command.
For example, on Fedora 13 you would replace rsync with /usr/bin/rsync
in my case (ubuntu) creating a shellscript and put there rsync command instead of running it from crontab as command did the trick. Now syncing working as charm.