Your message dated Thu, 20 Nov 2014 16:31:39 +0000 with message-id <[email protected]> and subject line Re: rpcbind: LSB headers should provide $portmap virtual facility has caused the Debian Bug report #768548, regarding rpcbind: LSB headers should provide $portmap virtual facility to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 768548: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768548 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: rpcbind Version: 0.2.1-6 Severity: important X-Debbugs-Cc: [email protected] X-Debbugs-Cc: Matthew Grant <[email protected]> On 08/11/14 01:16, Ben Hutchings wrote: > On Sat, 2014-11-08 at 00:37 +0000, Simon McVittie wrote: >> On 07/11/14 20:23, Simon McVittie wrote: >>> Bug M2, reported by Matthew Grant, present in 1:1.2.8-6: "NFS >>> exports also fail due to rpcbind not starting before nfs-common >>> and nfs- kernel-server". >> >> I have not been able to reproduce this, with or without native >> systemd units. >> >> One possible reason why this could happen sometimes is that >> /etc/init.d/rpcbind has "Provides: rpcbind", which seems ... >> redundant. I would expect it to have "Provides: $portmap" in >> order to be ordered before nfs-common, which has "Required-Start: >> $portmap". > > So would I. But this should result in breakage under sysvinit > too. Opening this as a separate bug in rpcbind. It should maybe be considered RC... but I couldn't reproduce the failure, and as Ben points out, we'd expect this to have caused breakage under sysvinit already. So perhaps there's something I haven't spotted that mitigates this. Regards, S
--- End Message ---
--- Begin Message ---On 20/11/14 15:00, Patrick Matthäi wrote: > Names=rpcbind.target > Requires=rpcbind.service > WantedBy=rpcbind.service > Conflicts=shutdown.target > Before=nfs-common.service nfs-kernel-server.service > After=rpcbind.service This is evidence that my original bug report was wrong, so I'm closing it. /etc/insserv.conf.d/rpcbind causes the correct dependencies to be inserted; $portmap doesn't need to be in the LSB headers. 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. > 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). 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
--- End Message ---
