0

The following script sits in cron.daily and succeeds when called with run-parts but exits with code 1 when called with anacron -f on Ubuntu 20.04 LTS. I have had many problems with various versions of this script over the years, it seems to stop working every few months. The script is

#!/bin/sh
#
# MAKE SURE HAVE CORRECT REMOTE/AT-HOME LOGIN SETUP AND THAT TARGET IS TOTEMDOC and source is Documents
#
rsync -azvv -e "ssh -o CheckHostIP=no  -i /home/stefan/.ssh/id_rsa" /home/stefan/Documents/ totem@MouseHouse:/totembackup/totemdoc

I used to have problems with path, but I thought the quote marks fixed that. I am at a loss for why it doesn't work anymore.

  • what happens if you explicit add exit 0 –  Aug 30 '20 at 04:05
  • In that case cron.daily exists with exit code 0, but the script is still not being successfully run; some files are not being transferred that should be. – Stefan Dawydiak Aug 30 '20 at 04:44
  • Anacron is very fussy about script names. It expects letters and numbers only. That means script.sh will not work but scriptsh will – PonJar Aug 30 '20 at 09:59
  • You need to switch direction how rsync transfer the file. rsync needs sufficient rights to preserve permissions (....or give totem sufficient rights). –  Aug 30 '20 at 10:55
  • this may help 1 –  Aug 30 '20 at 11:03
  • @PonJar Thank you for your suggestion. The script is named document-script and (perhaps a version without a typo I haven't found yet) this script ran fine for years with this name, it's the same style as popularity-contest, for example. – Stefan Dawydiak Aug 30 '20 at 14:23
  • @bac0n Thank you for your suggestions. This script runs on the source machine and has worked in the past, and works when I run it with run-parts. Wouldn't this permission problem show up then? totem has sufficient rights; in fact, anyone can right to those directories as I am not worried about my home server being broken into. – Stefan Dawydiak Aug 30 '20 at 14:27

1 Answers1

0

I managed to work out what was wrong. Upon running run-parts cron.daily as root, I got one of those "The authenticity of host ***** can't be established" messages from ssh. What must have been happening is that this prompt was coming up, timing out, and then the whole script was failing. After saying "yes" manually to the prompt, the script now runs automatically correctly.