Which means, it "requires" nfs-server.service AND it is stopped as soon nfs-server.service is stopped. Judging by this upstream commit: http://paste.ubuntu.com/23940610/
"""
So while I think it is valid to use rpcbind.target for ordering
(before/after) it shouldn't be used for dependencies (Wants/Requires).
The rpcbind.target file included in systemd does not "Require" the
actual service, so requiring rpcbind.target itself is pointless.
"""
This race condition might be happening because of the ".target" choice for rpcbind dependency - on nfs-server - instead of the "lack" of dependency in nfs-mountd. My only doubt is that developer preferred to depend on "rpcbind.socket" instead of "rpcbind.service". I'll go ahead and give it a try by testing ".socket", based on upstream commits, and ask for you to test it.
Just one thing that I'm trying to figure out:
nfs-mountd.service already has:
[Unit] nfs-server. service
...
BindsTo=
Which means, it "requires" nfs-server.service AND it is stopped as soon nfs-server.service is stopped. Judging by this upstream commit: http:// paste.ubuntu. com/23940610/
"""
So while I think it is valid to use rpcbind.target for ordering
(before/after) it shouldn't be used for dependencies (Wants/Requires).
The rpcbind.target file included in systemd does not "Require" the
actual service, so requiring rpcbind.target itself is pointless.
"""
This race condition might be happening because of the ".target" choice for rpcbind dependency - on nfs-server - instead of the "lack" of dependency in nfs-mountd. My only doubt is that developer preferred to depend on "rpcbind.socket" instead of "rpcbind.service". I'll go ahead and give it a try by testing ".socket", based on upstream commits, and ask for you to test it.
Thank you
Rafael