Summarizing
>From systemd.special we have:
sockets.target:
A special target unit that sets up all socket units (see systemd.socket(5) for
details) that shall be active after boot. Services that can be socket-activated
shall add Wants= dependencies to this unit for their socket unit during
installation. This is best configured via a WantedBy=sockets.target in the
socket unit's "[Install]" section.
Lets see who is starting rpcbind.socket:
[Install]
WantedBy=sockets.target
Unit file will be linked as "wanted" by "sockets.target".
$ systemctl list-dependencies sockets.target
sockets.target
● ├─acpid.socket
● ├─apport-forward.socket
● ├─dbus.socket
● ├─dm-event.socket
● ├─rpcbind.socket
... <many others>
$ systemctl --reverse list-dependencies sockets.target
sockets.target
● └─basic.target
● └─multi-user.target
● └─graphical.target
basic.target starts the sockets.target.
sockets.target start rpcbind.socket.
rpcbind.target doesn't start rpcbind.service.
Lets who starts rpcbind.service:
[Install]
Also=rpcbind.socket
rpcbind.{socket,service} are enabled/disabled together (not started).
$ systemctl list-dependencies rpcbind.service
rpcbind.service
● ├─rpcbind.socket
● ├─system.slice
● ├─remote-fs-pre.target
● └─rpcbind.target
└─...
rpcbind.service depends on rpcbind.target (not with my patch) AND
rpcbind.socket (started by basic.target with the sockets.target). Lets
see rpcbind.target (its a special target made by a generator, its unit
file doesn't contain anything):
rpcbind.target:
The portmapper/rpcbind pulls in this target and orders itself before it, to
indicate its availability. systemd automatically adds dependencies of type
After= for this target unit to all SysV init script service units with an LSB
header referring to the "$portmap" facility.
So, systemd puts an After=rpcbind.target in all SysV scripts with LSB
header containing "$portmap" as facility (insserv style):
$ systemctl status rpcbind.target
● rpcbind.target - RPC Port Mapper
Loaded: loaded (/etc/insserv.conf.d/rpcbind; static; vendor preset: enabled)
Drop-In: /run/systemd/generator/rpcbind.target.d
└─50-hard-dependency-rpcbind-$portmap.conf
/etc/insserv.conf.d/rpcbind contains "rpcbind".
/run/systemd/generator/rpcbind.service.d/50-rpcbind-\$portmap.conf contains:
[Unit]
Wants=rpcbind.target
Before=rpcbind.target
So rpcbind.target doesn't start "rpcbind.service" and any
"rpcbind.target" usage seems broken to me. rpcbind was ever started by
nfs-{kernel-server,mountd}.service (since they were relying on the
rpcbind.target). rpcbind (the portmap) was being activated by a
connection to the rpc socket.
But NOT the NETWORK socket, the LOCAL socket:
[Socket]
ListenStream=/run/rpcbind.sock
You can test this by stopping the "rpcbind.service" and trying:
$ rpcinfo -T tcp 127.0.0.1
rpcinfo: can't contact rpcbind: RPC: Remote system error - Connection refused
$ NETPATH=/run/rpcbind.sock rpcinfo
program version netid address service owner
100000 4 tcp6 ::.0.111 portmapper superuser
100000 3 tcp6 ::.0.111 portmapper superuser
100000 4 udp6 ::.0.111 portmapper superuser
100000 3 udp6 ::.0.111 portmapper superuser
100000 4 tcp 0.0.0.0.0.111 portmapper superuser
So accessing "/run/rpcbind.sock" is what "started" the rpcbind and the
race condition seen was born there, for sure. We have to make sure
rpcbind is loaded BEFORE any service depending on it. Lets analyze next
if my change (based only on backporting upstream code/fix) accomplishes
that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1590799
Title:
nfs-kernel-server does not start because of dependency failure
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1590799/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
