[systemd-devel] PartOf= Question

[Steve Dickson]

On 01/12/2015 05:20 PM, Colin Guthrie wrote:
> Hi Steve,
> 
> I think I maybe (coincidentally) partly answered some of this question
> (or at least outlined the problem) in my other reply on a different
> thread made just a moment ago.
I must a have missed it... I should watch this list closer than I do.

> 
> Steve Dickson wrote on 12/01/15 19:58:
>> Hello,
>>
>> The nfs-server service starts both the rpc-mountd service
>> and the rpc-idmapd service when the server is started.
>> But only brings down the rpc-mountd service when
>> the NFS server is stopped. 
>>
>> I want nfs-server service to bring both services when
>> the server is stopped. 
> 
> Do you mean nfs-mountd/idmapd.service here? That's the name I see in
> git, but perhaps you've renamed them locally to match their binary
> names? (I'm forever mixing up the rpc- vs. nfs- prefixes too FWIW!)
Yes... nfs-mountd and nfs-idmapd where the services I was talking about

> 
> Question: Are idmapd and mountd *only* required for the server? I
> thought that idmapd was at least needed for the client too (but this
> could easily be a problem with my understanding, so feel free to correct
> me).
Well if /usr/sbin/nfsidmap and  /etc/request-key.d/id_resolver.conf 
exists then the kernel keyrings are used to store the idmappings.
The kernel makes the upcall to nfsidmap via id_resolver.conf.

The caveat here is its hard coded in the kernel to always try the nfsidmap 
upcall first; If that fails then an upcall to rpc.idmapd is tried. 
So it makes sense to ensue the nfsidmap upcall exists (aka not making
two upcalls for every id binding). 

> 
> I'll assume I'm wrong for the sake of argument as you seem to what this
> behaviour! :)
> 
>> Looking at the difference between rpc-mountd and 
>> rpc-idmapd services, I noted the rpc-mountd service
>> had:
>>    PartOf=nfs-server.service
>>    PartOf=nfs-utils.service
> 
> I would strongly discourage the use of multiple PartOf= directives.
> 
> Note that as the man page describes PartOf is a one-way propagation.
> That is if nfs-server is stopped, started or restarted it will propagate
> to rpc-mountd.
> 
> But likewise is nfs-utils is stopped, started or restarted it too will
> propagate, but this might then go out of sync with nfs-server.
> 
> In these units, as nfs-mountd is required by nfs-server.service, if
> nfs-utils is restarted, then (I think this is correct) nfs-server will
> have to go down because it's requirement is no longer true (during the
> window when nfs-mountd.service restarting), but there is nothing that
> will then start nfs-server again after things are back up.
> 
> So by having two PartOf= directives here, issuing "systemctl restart
> nfs-utils" when nfs-server is started, will result in nfs-server being
> stopped. Now in this particular case, nfs-server is not really a daemon
> so things will physically work, but the state will be really confusing
> to a sysadmin!
This makes senses... 

> 
> 
> If rpc-mountd and rpc-idmap are essentially bound to nfs-server.service
> state, then I would remove both PartOf= lines and simply add a
> BindsTo=nfs-server.service line. Forget nfs-utils.service (which I think
> should be generally done anyway).
> 
> This binds both units state to that of nfs-server.service. If it's
> started, they will start, if it is stopped, they will stop. If they are
> individually stopped, so will nfs-server (it Requires= them).
> 
> They should thus continue to not have any [Install] section.
> 
> 
> PartOf is looser than BindTo. It was introduced to allow targets to be
> restarted and have all their units restart automatically (often this
> would be templated units), but to also allow the individual units that
> are part of that target to be restarted individually without affecting
> other units in the same target.
Got it.. 

> 
> Perhaps this is actually what you want here (e.g. to be able to restart
> idmap on it's own without having this propagate to the
> nfs-server.service too? If so, I believe you should use Wants= in
> nfs-server.service rather than Requires= as that way the individual
> units can be restarted without actually affecting the state of the
> nfs-server itself, but you do have to ensure they are enabled in some
> other way (as Wants= will not pull them in automatically).
I have a Wants=nfs-idmapd.service in nfs-server.service so I 
think that is good to go...

Here is what I have now in nfs-idmap.service:

[Unit]
Description=NFSv4 ID-name mapping service

BindTo=nfs-server.service

Wants=nfs-config.service
After=nfs-config.service

[Service]
EnvironmentFile=-/run/sysconfig/nfs-utils
Type=forking
ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS

And in nfs-server.service I have the lines:
Wants= nfs-idmapd.service
After= nfs-idmapd.service 

And still rpc.idmapd does not come down when server is stopped.
>
> 
> 
> I suspect it's required by something else perhaps? Does it's pid change
> (i.e. is it restarted)?
No. The pid stays the same on restarts.

> 
> Or dod you just modify the units on disk but forget to run "systemctl
> daemon-reload" to reread them?
After the changes I just reboot. A VM on a SSD makes a quick reboot!  

Thanks for the help!

steved.