Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Hello the interesting line in my crontab looks like this: (edited & saved it by running crontab -e)

23 *    * * *   rsync -av --delete root@example.de:/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 root@example.com:/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 root@example.com:/var/www/ /home/niklas/server4you_www >> /home/niklas/scripts/logfile

to

/usr/bin/rsync -av --delete root@example.com:/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 root@example.com without entering a password. Is it possible to send rsync the password of the ssh key?

share|improve this question
    
You keep mentioning pgp key, but maybe you really mean an SSH keypair? –  ptman Nov 1 at 10:12

4 Answers 4

up vote 3 down vote accepted

Put full path to rsync even to your /usr/bin/backup, so the line in that file would start

/usr/bin/rsync <your other options>

And try to put a line like

logger -t my_backup Hello from /usr/bin/backup

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

echo "Hello from /usr/bin/backup" >/tmp/backuptest

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

/usr/bin/rsync <your options> || echo "rsync died with error code $?" >> your_log

Perhaps we'll catch why rsync is so upset.

YET ANOTHER EDIT: OK, rsync error code 5. That means

rsync error: error starting client-server protocol

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:

export RSYNC_PASSWORD="myprecioussssssss"

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.

share|improve this answer
    
I am using ubuntu –  niklasfi Aug 1 '10 at 13:49
    
OK, edited my reply a bit :) –  Janne Pikkarainen Aug 1 '10 at 14:24
    
rsync died with error code 5 –  niklasfi Aug 1 '10 at 14:31
    
Soooooo I edited again. –  Janne Pikkarainen Aug 1 '10 at 14:35
    
in deed running rsync manually works like a charm! –  niklasfi Aug 1 '10 at 14:37

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 with crontab -e. So edit the crontab with crontab -e as user niklas, and make the contents

23 *    * * *    rsync -av --delete root@example.de:/var/www/ /home/niklas >> /home/niklas/scripts/logfile

The user you ran crontab -e as should have received a mail with an error message (complaining that niklas is not a valid command). If it didn't, there may be a problem in your mail setup.

share|improve this answer

You might need the full path for the rsync command.

For example, on Fedora 13 you would replace rsync with /usr/bin/rsync

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.