Hi, I have had a bit of a nightmare recently and lost 2 disks which ruined my backup strategy. Next step was to backup my server to an old PC I sometimes use which runs Fedora 23 – all good using the following script (IP add mangled) and cron:

Using that PC though is inconvenient as I have to switch it on purely for the backup. So, I decided to use my everyday PC (also F23) to receive the files. Now here comes a familiar problem – the script works from the CLI but not via cron.
I had a look at the journalctl file which tells me:

So the server closed the connection. Over at the server end though (Centos 6) there is nothing in /var/log/messages to explain this and I can't see any other logs which are getting me any closer to a solution.

Any ideas where I can look?

I have identified an adequate workaround but I would like to identify this problem.

Cheers

[EDIT] I have SSH keys to get me between each PC. Password authentication is switched off on the server.

Try to run rsync with more verbosity -v or -vv, then let's see the cron logs.

thanks, I normally include "-v" (F23 doesn't like -w). I am not sure why this slipped through the net however I am still struggling to find logs. At the Fedora end:
But I guess it is the Centos end which is going to contain the reason for the disconnect but nothing in /var/log/messages and /var/log/cron doesn't:
Actually though
I didn't see that before and will follow up

Cheers

Also, stop using variable names in all caps. The chances are WAY too high that you'll accidentally replace or set an environment variable you've never even heard of but can screw up the behavior of your script. Variables names in all caps are reserved for environment variables, use lower or mixed case for local variables in a script.

I'm not saying that's your problem, but it's a very bad habit to get into.

What tshikose wrote was "-vv", but in the standard font it looks like -w.

Does your cron use /bin/sh, /bin/bash, or another shell by default? I don't have a Fedora 23 box to compare, but from various sites it appears cron on F23 probably uses /bin/bash by default. Does your script work correctly when run using /bin/bash rather than /bin/sh?

Joanna

Also, I was just reading the rsync manpage again now, and noticed this part that might apply to your situation (if you are using the rsync daemon and a different user on one end vs the other):

"If you need to specify a different remote-shell user, keep in mind that the user@ prefix in front of the host is specifying the rsync-user value (for a module that requires user-based authentication). This means that you must give the '-l user' option to ssh when specifying the remote-shell, as in this example that uses the short version of the --rsh option:
rsync -av -e "ssh -l ssh-user" rsync-user@host::module /dest"

This is only for rsync daemon connections, however. It doesn't appear that is what you are using, so this may not apply at all.

According to askubuntu, you can also see that rsync error if the remote (or destination) path does not exist. However, if the script runs fine when you run it manually, then the path locations have to be correct and present. Does the user have read and write access to the directory? Is cron running the job as the same user that you used to run the command manually?

thanks for all the response everyone. As noted I have a workaround for this and other priorities at the moment.

Still, I would like to get to the bottom of this problem and will try to look at it over the weekend and update my status

Cheers

Once again thanks for all the assistance. I'll try and go through your points individually Joanne:

I am really not sure about the shells. I am assuming bash but it would be good to know how to find out. I tried /bin/bash but same problem

Yeah, I am pretty lazy and only one user on each computer so the username is the same across boxes. I gave the "-l" a whirl but no joy.

Thanks. I had a root around the net and everything pointed to something wrong at the remote end. There is nothing obvious leaping out at me though.

As the script works not only when invoked manually but also on another F23 box I have been digging around for differences between the 2 PCs. I noticed the privileges on the directory holding the script were different although the problematic box had more privileges. I changed to the privileges on the successful box (700). No difference

I'll keep plugging away as and when I get time.

Cheers