Consider the following service: [root@localhost ~]# cat /lib/systemd/system/foo-bar-baz.service [Unit] Description=Touch the baz in foobar Requires=foo-bar.mount [Service] Type=oneshot RemainAfterExit=true ExecStart=/bin/touch /foo/bar/baz [Install] WantedBy=multi-user.target The unit foo-bar.mount doesn't exist (it's supposed to exist, but I had made a typo which resulted in my encounter with this bug). Now, trying to start the service: [root@localhost ~]# systemctl start foo-bar-baz.service Failed to issue method call: Unit foo-bar.mount failed to load: No such file or directory. See system logs and 'systemctl status foo-bar.mount' for details. So far, this is expected. Now enable foo-bar-baz.service and reboot. Once the system came up: [root@localhost ~]# systemctl status foo-bar{.mount,-baz.service} foo-bar.mount - /foo/bar Loaded: error (Reason: No such file or directory) Active: inactive (dead) Where: /foo/bar CGroup: name=systemd:/system/foo-bar.mount foo-bar-baz.service - Touch the baz in foobar Loaded: loaded (/lib/systemd/system/foo-bar-baz.service; enabled) Active: active (exited) since Fri, 06 Jan 2012 13:39:28 +0800; 38s ago Process: 810 ExecStart=/bin/touch /foo/bar/baz (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/foo-bar-baz.service This time, foo-bar-baz.service was happily started, even though its dependency is not satisfied. It is 100% reproducible, and this is on Fedora 16 with systemd-37-3.fc16.x86_64
So, this is actually a local configuration problem: Requires= needs to be combined with After= to be race-free. Note that requirement and ordering dependencies are orthogonal in systemd, and hence if a unit is required but not ordered against the job for the required unit might or might not complete first, and hence the effective result of it is not defined. This is actually documented in the man pages very explicitly these days. Closing hence. (And sorry for letting this hang in bugzilla for so long)
I don't think this is an ordering issue. As I mentioned in the original description, the .mount unit does not exist at all on the system. Therefore, I would expect a service which Requires it to not get started. As I mentioned, this is what happens when manually starting the service, but not when the service gets started at boot time. Of course, this was a long time ago and maybe now it works. I'll have to test it again with a more recent systemd version. I'll try and do it ASAP.
Yeah, please test an file a new bug on github if this is still an issue, even if combined with After=. Thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.