possibly problem with rawhide (systemd-217?): "Found ordering cycle on basic.target/start"

Matthew Miller mattdm at fedoraproject.org
Fri Oct 31 13:30:35 UTC 2014

On Fri, Oct 31, 2014 at 02:15:45PM +0100, Michal Schmidt wrote:
> Maybe you already had an ordering cycle on Oct 26, but different units
> were chosen for deletion when breaking the cycle, and by luck it had
> fewer directly observable consequences.
> Could you check older logs for ordering cycles?

Yeah, I was just doing that, and there's no ordering cycle logged
before late last night (e.g. the ill-fated reboot).

That said, as you expected, disabling nfs-client.target does make the
system boot successfully. I'm still getting a problem with
dev-mqueue.mount, though:

Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount: Directory /dev/mqueue to mount over is not empty, mounting anyway.
Oct 31 09:19:46 ubik mount[4484]: mount: mount point /dev/mqueue does not exist
Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount mount process exited, code=exited status=32
Oct 31 09:19:46 ubik systemd[1]: Failed to mount POSIX Message Queue File System.

On a related but different note — is there a way to detect potential
ordering cycles from a set of RPMs on disk (possibly installed in a
chroot or something) _without_ actually booting? Maybe we could add a
taskotron check for that for packages with changes to systemd unit
files. (I realize that what is enabled on people's systems will have an
impact, but we could check against a set of defaults at least.)

Matthew Miller
<mattdm at fedoraproject.org>
Fedora Project Leader

More information about the devel mailing list