[systemd-devel] Running system services required for certain filesystems

[Colin Guthrie]

Steve Dickson wrote on 12/01/15 20:31:
> Hello
> 
> On 01/12/2015 05:37 AM, Colin Guthrie wrote:
>> Hi,
>>
>> On a related note to my previous message (subject "systemctl status not
>> showing still running processes in inactive .mount unit cgroups (NFS
>> specifically)"), when mount.nfs runs to mount NFS filesystems, it shells
>> out to /usr/sbin/start-statd which in turn calls sytemctl to start
>> rpc.statd service. This feels ugly.
> Why? This is why rpc.statd does not need to be started 
> on the client default any more. 

Yes but it requires the shelling out to bash script to do some
modification of a pre-calculate set of transactions and dynamically
adjusts the systemd jobs.

It feels very un-systemd to use systemctl during the initial transaction
of start jobs to modify things.

Generally speaking you also have to be really, really careful doing such
things as they can be called at unexpected times and result in deadlocks
(protected by a timeout thankfully) due to ordering cycles.

e.g. say something in early boot that has "Before=rpc-statd.service" is
run, that somehow triggers, e.g. an automount, that in turn calls
mount.nfs, which in turn calls "systemctl start rpc-statd.service", then
that systemctl job will block because the job it creates is waiting for
the job with "Before=rpc-statd.service" in it to complete.

So calling systemctl during the initial transaction is really something
to strongly discourage IMO. Ideally all information would be available
after all the generators are run to calculate the initial transaction
right at the beginning without any of dynamic modification in the middle.

>> We have a sync point for this in the form of remote-fs-pre.target, but
>> for some reason upstream nfs-utils people still deem that
>> /usr/sbin/start-statd is a required component.
> I'm not seeing how remote-fs-pre.target is a sync point. Its only
> used by the nfs-client.target... 

Well, it's original intention was as as a sync point, but it doesn't
seem to be getting used that way now.... (and there are some good
reasons which I'll cover in a reply to Andrei).

>> But it did get me thinking about how "clean" remote-fs-pre.target really
>> is. We do need to make sure rpc.statd is running before any NFS
>> filesystems are mounted and and relying on the blunt instrument of
>> remote-fs-pre.target seems kinda wrong. It should be more "on demand"
>> e.g. when I start an nfs mount, it should be able to specify that
>> rpc.statd service is a prerequisite.
>>
>> So my question is, is there a cleaner way to have dependencies like this
>> specified for particular FS types? With the goal being that before
>> systemd will try and mount any NFS filesystems it will make sure that
>> nfs-lock.service (or statd.service or nfs-statd.service or whatever it's
>> name really should be) is running?
>>
>> I kinda want a Requires=nfs-lock.service and After=nfs-lock.service
>> definitions to go into all my *.mount units for any nfs filesystem, but
>> it a way that means I don't have to actually specify this manually in my
>> fstab.
> Why spread out the pain? I think the sync point we have right now
> mount.nfs calling start-statd works and keeps everything in one place.

Shelling out to start-statd definitely isn't a sync point and as I've
outlined above, calling systemctl mid-transaction is really something we
should avoid.

I do like that it solves the case of calling "mount /mountpoint" command
manually as a sysadmin and it will start the necessary service but I
still thing it's ugly if called via "systemctl start /mountpoint" - we
should be able to handle this kind of dep without such shelling out.

>> Something like a pseudo service - systemd-fstype at nfs.service with
>> Type=oneshot+RemainAfterExit=true+Exec=/usr/bin/true that is run by
>> systemd before it does it mounting to act as a sync point (thus allowing
>> nfs-lock.service to just put
>> RequiredBy=systemd-fstype at nfs.service+Before=systemd-fstype at nfs.service
>> and all is well) - there shouldn't really be a strong need for any
>> actual changes to systemd-fstype at .service (or any
>> systemd-fstype at nfs.service.d dropins) here, as it can all be specified
>> "the other way around" in nfs-lock.service.
> WOW.. Granted I'm no systemd expert... what did you say?? :-) 
> My apologies but I'm unable to parse the above paragraph at all!
> 
> In the end, I'm all for making things go smoother but I've
> never been a fan of fixing something that's not broken... 

To be fair, I could probably word it better, and (being totally fair)
 I'm suggesting a similar abuse of a ".service" unit that the current
nfs-utils.service does (which we really shouldn't do!)

But ultimately, what the above would do is allow all the deps for the
initial transaction to be pre-calculated right at the start without the
need to shell out to something that calls "systemctl start
rpc-statd.service". Sadly, we'd still need a way to know that this was
happening (i.e. being called from within systemd, not via "mount ..."
directly) as a problem scenario would be that the machine was booted
without any NFS mounts (and thus rpc-statd.service is not running) and
the sysadmin simply ran "mount /my/nfs/share" manually. In this case you
*would* want the mount command to trigger the starting of
rpc-statd.service for you (and your current mechanism for that is
reasonable.

Overall, I can see why things are working they way they do just now!!
But it still doesn't feel right from a "clean boot" perspective.

This is something I'll bring up at the hackfest on the 30th to see if
some proper infrastructure can be added here.

Thanks for your input here. Domain knowledge is invaluable!

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/