Hello systemd maintainers,
please CC me in your e-mails, I'm not subscribed to this list.
Am 20.11.2014 um 17:31 schrieb Simon McVittie:
It seems to me as though your dependency cycle is caused by
vmware-tools.service. Please try removing the X-Start-Before from it
and see whether that helps. If further analysis of your dependency
cycle indicates that there is in fact some problem with
rpcbind.service, I think it would make most sense for that to be a
separate bug.
Right, it is working without the X-Start-Before line.
Names=vmware-tools.service
...
Before=ntp.service postfix.service bacula-fd.service
nagios-nrpe-server.service bacula-director.service graphical.target
shutdown.target network-online.target bacula-sd.service
fail2ban.service sysstat.service multi-user.target
After=local-fs.target systemd-journald.socket basic.target
system.slice
Because of the X-Start-Before: $network, this wants to start before
network-online.target, which approximately corresponds to
/etc/init.d/networking in sysv-land; yet it is a rc2 service, so it
wants to start after basic.target.
In conjunction with basic.target (i.e. rcS) services like
rpcbind.service that apparently want to start *after*
network-online.target, this presents a problem. Consider the Before and
After ordering:
sysinit.target (must start before)
basic.target (which must start before)
vmware-tools.service (etc.)
network-online.target
rpcbind.service
sysinit.target (! back where we started)
There's no way that can work well.
The sysvinit scripts were presumably able to resolve this less
destructively by breaking the cycle in a different place, because they
didn't even think about rc2 until they had brought up rcS, by which
point it was too late for vmware-tools' X-Start-Before to take effect;
so it was simply ignored (I think). However, systemd doesn't force all
of rcS to happen before any of rc2 starts: it has a single large
dependency graph that covers both.
I think it's fairly clear that this is neither rpcbind's fault, nor the
same issue that I originally reported (which was wrong anyway).
ACK
It would seem reasonable to report a non-RC bug against systemd
(probably wishlist) for either or both of these:
- logging the whole path around the cycle(s) that it found, not just
one of the units involved;
- a cleverer heuristic for where to break cycles, perhaps preferring
to break them at a unit that has DefaultDependencies=no because those
are less likely to be something important during early boot
It's entirely possible that one or both of those has been tried and
turned out not to be feasible, though.
S
Thanks for your analyse of this problem. I think there should be a
better solution, since this bug will be triggered on every VMware
virtualized platform (since normaly you have to install their
corresponding vmware-tools).
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
