I am using rsync over ssh.The remote (ssh) user has its own rsyncd.conf in its home directory defining the sync services. Whenever the "transfer logging = yes" option is used in one of them it will make the rsync server component segfault. Example rsyncd.conf of user 'syncsshuser': use chroot = false strict modes = false read only = true write only = false timeout = 120 [myshare] path = /srv/shares/myshare/ write only = true read only = false transfer logging = yes auth users = rsyncuser secrets file = rsyncd.secrets Of course it also needs rsyncd.secrets; eg. rsyncuser:mysecret Then run rsync on the remote system: export RSYNC_PASSWORD=mysecret rsync -e "ssh -i /path/to/id_rsy -l syncsshuser" /some/path/ rsyncsuser@remote-hostname::myshare/ This will result in a segmentation fault (SIGSEGV) when invoking rsync daemon on remote side. The client returns "rsync: didn't get server startup line" due to failed rsync daemon fork and broken communication. Removing the "transfer logging" option from the configuration resolves the issue. I found a potentially related topic on the mailing list: https://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg181658.html Reproducible: Always Steps to Reproduce: 1. Create SSH user to run the sync with on remote host. 2. Create rsyncd.conf service with "transfer logging" enabled within the home directory of the sync user 3. Run sync using the defined service Actual Results: Rsync fails: rsync: didn't get server startup line rsync error: error starting client-server protocol (code 5) at main.c(1777) [sender=3.2.0] Expected Results: Transfer starting and synchronization to be initiated. Not sure if this could be related to some communication issue with syslog or similar.
This should be fixed in 3.2.2. https://github.com/WayneD/rsync/commit/317beebef8b0f60eb36255b35cbea71c84f6ac38
Rainer, can you please test rsync-3.2.2 and report back your results?
I confirm rsync 3.2.2 is resolving the problem. Transfer logging with the default log format is working again and not segfaulting rsync.
Let's keep this bug open until a newer version has been stabilized.
