rpcbind: LSB headers should provide $portmap virtual facility

[Patrick Matthäi]

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: pmatthaei at debian.org
         patrick at linux-dev.org
*/