After system reboot rsync starts but no lock file is created, therefore when rsync on a remote machine tries to get a directory for backup it fails with
@ERROR: failed to open lock file rsync error: error starting client-server protocol (code 5) at main.c(1534) [Receiver=3.0.9]
When restarted by hand the lock file is successfully created and the problem goes away until the next reboot of the server/source.
Rsyncd is started from /etc/rc.local:
/usr/bin/rsync --daemon --config /etc/rsyncd/rsyncd.conf
There is nothing particularly interesting in logs. Here's /var/log/rsyncd.log:
2016/04/28 06:23:34  connect from <remote client> (<remote ip>) 2016/04/28 06:23:34  rsync: failed to open lock file /var/lock/rsyncd: Permission denied (13)
And the rsyncd config:
# cat /etc/rsyncd/rsyncd.conf log file=/var/log/rsyncd.log use chroot = yes max connections=3 lock file = /var/lock/rsyncd list = yes uid = root gid = root secrets file = /etc/rsyncd.secrets strict modes = yes ignore errors = no ignore nonreadable = yes transfer logging = no timeout = 600 refuse options = checksum dry-run dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz [backup dir config]
The system on the server host is CentOS (not sure about the version as it shows RedHat release number):
# cat /etc/centos-release Red Hat Enterprise Linux AS release 4 (Nahant Update 5) # uname -a Linux <hostname> 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
# yum info rsync Installed Packages Name : rsync Arch : x86_64 Version : 3.0.6 Release : 12.el6
What could be the reason for this behavior?
UPD: tried starting rsyncd with xinetd and init script, in both cases behavior was the same as described earlier. When started with xinetd lock creation failed in any case with denied permission; same for init script when starting on boot - doing 'service rsync restart' manually makes the problem go away.