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 Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1774788 Title: Daemon won't start at boot up (18LTS fully patched) Status in rsync: Unknown Status in rsync package in Ubuntu: Won't Fix Bug description: By adding the 'address=' option to the /etc/rsyncd.conf file, the daemon fails at boot. Once the NIC(s) is/are up, it will start fine when executed via systemctl start rsync ● rsync.service - fast remote file copy program daemon Loaded: loaded (/lib/systemd/system/rsync.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2018-06-02 08:01:31 CST; 52min ago Process: 851 ExecStart=/usr/bin/rsync --daemon --no-detach (code=exited, status=10) Main PID: 851 (code=exited, status=10) Jun 02 08:01:31 billlaptop.private.ycc systemd[1]: Started fast remote file copy program daemon. Jun 02 08:01:31 billlaptop.private.ycc rsyncd[851]: rsyncd version 3.1.2 starting, listening on port 873 Jun 02 08:01:31 billlaptop.private.ycc rsyncd[851]: bind() failed: Cannot assign requested address (address-family 2) Jun 02 08:01:31 billlaptop.private.ycc systemd[1]: rsync.service: Main process exited, code=exited, status=10/n/a Jun 02 08:01:31 billlaptop.private.ycc rsyncd[851]: unable to bind any inbound sockets on port 873 Jun 02 08:01:31 billlaptop.private.ycc systemd[1]: rsync.service: Failed with result 'exit-code'. Jun 02 08:01:31 billlaptop.private.ycc rsyncd[851]: rsync error: error in socket IO (code 10) at socket.c(555) [Receiver=3.1.2] ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: rsync 3.1.2-2.1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17 Uname: Linux 4.15.0-22-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.1 Architecture: amd64 CurrentDesktop: GNOME Date: Sat Jun 2 08:48:15 2018 InstallationDate: Installed on 2018-06-01 (0 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: rsync UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/rsync/+bug/1774788/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
