Bug 9982

I have to say I don't completely grasp the intended relationships between e.g. nfs.target and nfs-server.service. Can either of you explain it? (if not, I'll just dig deeper)

Of course the actual needed scripts in the rpm depend a bit on that...

I'm not sure it's as simple as running some scriplets, as running systemctl daemon-reload still does not make systemd see these units.  I looked on an up-to-date Cauldron VM, and this affects some other services too.  Running drakxservices in a terminal gives this output:
Failed to issue method call: Unit atd.service is not loaded.
Failed to issue method call: Unit avahi-daemon.service is not loaded.
Failed to issue method call: Unit avahi-dnsconfd.service is not loaded.
Failed to issue method call: Unit httpd.service is not loaded.
Failed to issue method call: Unit nfs-blkmap.service is not loaded.
Failed to issue method call: Unit nfs-lock.service is not loaded.
Failed to issue method call: Unit nfs-secure.service is not loaded.
Failed to issue method call: Unit nfs-secure-server.service is not loaded.
Failed to issue method call: Unit nfs-server.service is not loaded.
Failed to issue method call: Unit rpcbind.service is not loaded.
Failed to issue method call: Unit rtkit-daemon.service is not loaded.
Failed to issue method call: Unit shorewall.service is not loaded.
Failed to issue method call: Unit udisksd.service is not loaded.
Failed to issue method call: Unit xinetd.service is not loaded.

Why are those services not loaded!?  None of them show up in systemctl --all, but luckily drakxservices still shows them in the GUI at least.

CC: (none) => luigiwalser

@David: If the units are not enabled then there is often no reason to load the unit. systemctl --all will not necessarily show all units on disk, it just shows the ones systemd is tracking (which might include some inactive units but depending on garbage collection, it might not). To show all the unit files on disk, "systemctl list-unit-files" should be used. drakxservices uses this call itself to get a full list of all units.

I'll comment on the wider issue shortly.

(In reply to Colin Guthrie from comment #3)
> @David: If the units are not enabled then there is often no reason to load
> the unit. systemctl --all will not necessarily show all units on disk, it
> just shows the ones systemd is tracking (which might include some inactive
> units but depending on garbage collection, it might not). To show all the
> unit files on disk, "systemctl list-unit-files" should be used.
> drakxservices uses this call itself to get a full list of all units.

When did this change happen?  Can it be fixed?  This is really bad.

Please don't say this behavior is OK.  It conflicts with all of the documentation I have read on systemd over the last couple of years, it's confusing, it's unintuitive, and it's just plain silly.

@David, this is not a change, it's always been like that. This is why drakxservices was written to use list-unit-files. Nothing has changed here. But it's off topic, so lets discuss it elsewhere if possible?

OK, so looking at things, it seesm the following services only start when nfs.target is started:
 nfs-idmap.service
 nfs-rquotad.service 
 nfs-mountd.service 

Forgive my ignorance but I thought idmap was needed on client machines? If nfs.target is "Network File System Server" then I can't help but feel that idmap should NOT be part of nfs.target.

I know these come from Fedora, but it just doesn't seem to make sense to me.

I'd have something like the following.

At the top level:
nfs-client.target
nfs-server.target

Each of the components should have install sections referring to one of these targets. That way enabling or disabling either of the targets will be approximately the same as enabling or disabling nfs-common and nfs-server in the past. In fact, perhaps nfs-client.target should just be called nfs-common.target?

We should also try and push this change to fedora (and anyone else using those units) and eventually upstream.

But as things stand the nfs.target seems wrong.

Hmm, OK, so it seems:
nfs-server.service:Requires=nfs-idmap.service nfs-mountd.service nfs-rquotad.service

So these services should be started by the single nfs-server.service. That's good and sensible I think.

Sadly nfs-rquotad.service is somewhat useless as we apparently don't actually ship a /usr/sbin/rpc.rquotad. Looks like there is a missing require on the quota package which contains the binary. Very odd to have the units split up such that unit was in one package and binary in another... better to call the unit rpc-rstatd.service and ship it instead in the quota package.

idmap (idmapd, actually) is indeed needed both sides. The only server/client specific daemons are svcgssd/gssd, but only for secure (kerberos, mainly) NFS, and they are already managed by distinct services (nfs-secure-server, nfs-secure). I agree having distinct top-level targets for client and server case would be clearer:
nfs-client.target
nfs-server.target
nfs-secure-client.unit
nfs-secure-server.unit

Regarding the missing quota binary, Fedora solves it with a dependency on quota package in its nfs-utils package.

OK, I've done tidyups.

They seems to work for me on a server and a client.

nfs.target is basically the same as the old nfs-common under sysvinit. If you enable nfs-server.service it will be wanted by nfs.target so this still needs to be enabled also. I was going to use Also= in the units but it seems there may be a slight bug/thinko about the handling of this when disabling units that makes it a bad idea.

I tried to put code in that should migrate nicely from sysvinit...

A review of the changes would be nice :)

Anyone get a chance to test these changes? I'd like to push this if we're good for now. More dev/tidyup can happen in due course.

 nfs-utils-1.2.7-3.mga3 pushed to release

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED