This is a class[1] of bugs for which we cannot come up with a general solution that will safely and sanely apply to all scenarios. For such cases, local configuration changes should be made to accommodate the intended behavior in each case.
We believe that, in this particular case, since the configuration was explicitly changed to use a specific IP, you should continue with the changes and adjust the systemd unit file for rsync to cope with that. Be it adjust the target to be network-online, or something else that explicitly waits for that very interface to come up. systemd offers mechanisms for such overrides, and it's described in more detail in comment #2. Regarding the "systemctl start rsync" exit status, it's the way it work with Type=simple systemd services. From the systemd.service manpage: """ If set to simple (the default if ExecStart= is specified but neither Type= nor BusName= are) the service manager will consider the unit started immediately after the main service process has been forked off. (...) Note that this means systemctl start command lines for simple services will report success even if the service's binary cannot be invoked successfully """ I tried Type=exec, but it still behaved in the same way (as the error happens after rsync starts up, i.e., the binary was executed). With Type=forking I got a bit further, but the timeout needs tuning: root@j1-rsyncd:~# time systemctl start rsync Job for rsync.service failed because a timeout was exceeded. See "systemctl status rsync.service" and "journalctl -xeu rsync.service" for details. real 1m30.246s With TimeoutStartSec=5 in the unit file it's better: root@j1-rsyncd:~# time systemctl start rsync Job for rsync.service failed because a timeout was exceeded. See "systemctl status rsync.service" and "journalctl -xeu rsync.service" for details. real 0m5.287s I think the most reliably way would be Type=notify, but that requires rsync code changes to support systemd's notify mechanism. In summary, for the specific case of this bug, we believe that systemd overrides are the best answer for now. To detect startup errors immediately, I'm willing to file a separate bug. 1. https://bugs.launchpad.net/ubuntu/+bugs?field.tag=network-online-ordering ** Changed in: rsync (Ubuntu) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1774788 Title: Daemon won't start at boot up (18LTS fully patched) To manage notifications about this bug go to: https://bugs.launchpad.net/rsync/+bug/1774788/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
