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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
