On Tue, Aug 6, 2019 at 3:15 AM Michael Biebl <bi...@debian.org> wrote:
> Am 06.08.19 um 04:48 schrieb Debian Bug Tracking System: > > rpcbind (1.2.5-5) unstable; urgency=medium > > . > > * debian/rules: Add --no-restart-after-upgrade option to > > dh_installsystemd to avoid race condition at rpcbind.socket > > initialization (Closes: #933268) > > > https://salsa.debian.org/debian/rpcbind/commit/6bdd9256f811ed312173eeb9e9ca7f600720769b > > I don't think this is a proper fix. After all, you typically want a > daemon to be restarted after upgrades so (security) fixes are applied. > I also notice, that the above commit contains other (unrelated) changes > which are not mentioned in the changelog. > > > A quick test shows, that debhelper creates the following code and > executing that manually triggers the same error: > > # systemctl restart rpcbind.service rpcbind.socket > > Job for rpcbind.socket failed. > See "systemctl status rpcbind.socket" and "journalctl -xe" for details. > A dependency job for rpcbind.service failed. See 'journalctl -xe' for > details. > > This needs further investigation, where the underlying problem is. > For the time being, I would suggest a different workaround, ie. > restarting rpcbind.service and rpcbind.socket sequentially (or only > rpcbind.service, I think that should be sufficient) > > > So somehting like this: > override_dh_installsystemd: >  dh_installsystemd rpcbind.socket > dh_installsystemd rpcbind.service > > > I'm not yet sure if this is a bug in systemd itself, in rpcbind or > debhelper for generating such a code sequence, so CCing all affected > parties. > The idea was to let systemctl/systemd order the jobs in whatever way it saw fit, according to the ordering requirements of the units. If there is a bug somewhere, it is either in systemd, or in rpcbind where an ordering requirement is missing. Does the problem persist if you add After=rpcbind.socket to rpcbind.service? -- Saludos, Felipe Sateler
