On Thu, 20 Nov 2014 at 13:30:58 +0100, Patrick Matthäi wrote:
> I can reproduce it on a system, nfs- is not starting on boot.
This might actually be more relevant to nfs-common's existing RC bug
(since you presumably need to have nfs-common installed for this
configuration), but I would rather not attach yet more to that bug
since I think it's already mixing up somewhere between 3 and 5 related
issues.
Please specify your systemd, nfs-common and rpcbind versions,
the output of:
systemctl status nfs-common.service
systemctl show nfs-common.service
and the same for rpcbind.service, rpcbind.target, paths.target and
basic.target (i.e. the stuff implicated in your dependency loop).
If the "systemctl status" calls list any "Drop-In" files, please also
provide those.
If you have local modifications to /etc/init.d/nfs-common,
/etc/init.d/rpcbind and/or /etc/insserv.conf{,.d} please attach those too.
The output of "reportbug --template systemd" might also be interesting,
but is rather long and hopefully unnecessary.
I would also like to know whether you have a non-unified /usr (i.e.
not on the rootfs), or any networked or otherwise unusual filesystems
in fstab. (Just a wild guess, it might not be relevant at all.)
> Nov 20 13:23:56 backup-lvl3 systemd[1]: Cannot add dependency job for unit
> display-manager.service, ignoring: Unit display-manager.service failed to
> load: No such file or directory.
> Nov 20 13:23:56 backup-lvl3 systemd[1]: Found ordering cycle on
> basic.target/start
> Nov 20 13:23:56 backup-lvl3 systemd[1]: Breaking ordering cycle by deleting
> job paths.target/start
> Nov 20 13:23:56 backup-lvl3 systemd[1]: Job paths.target/start deleted to
> break ordering cycle starting with basic.target/start
> Nov 20 13:23:56 backup-lvl3 systemd[1]: Found ordering cycle on
> basic.target/start
> Nov 20 13:23:56 backup-lvl3 systemd[1]: Breaking ordering cycle by deleting
> job rpcbind.service/start
> Nov 20 13:23:56 backup-lvl3 systemd[1]: Job rpcbind.service/start deleted to
> break ordering cycle starting with basic.target/start
So this is Very Bad: systemd has found a dependency loop in early boot
(basic.target is approximately equivalent to the earlier parts of rcS.d),
and broken it in an essentially random place because that's somewhat
more likely to succeed than just refusing to continue.
The question is why this dependency loop exists. Presumably, one of
the dependencies is unnecessary or wrong.
I think I might actually have been wrong with the initial report of this
bug: /etc/init.d/rpcbind does not provide $portmap, but
/etc/insserv.conf.d/rpcbind does, and recent(ish) systemd is meant to
respect both. So systemd *should* have already realised that
rpcbind.service (i.e. /etc/init.d/rpcbind) is necessary for rpcbind.target
(i.e. $portmap)... but perhaps "help! I don't know how to disentangle
this dependency loop" trumps that.
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
