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

[Colin Guthrie]

Steve Dickson wrote on 13/01/15 16:29:
>>>> 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.
> I guess I'm not such a systemd purist ;-) but it feels ok to me! :-) 

:)

>> 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.
> I see the deadlock... in theory... but that assumes the first 
> "Before=rpc-statd.service" never completes which is very 
> unlikely.

Well, what I was meaning was the the process that is
"Before=rpc-statd.service" is actually the parent of the one that
ultimately tries do the mount.

Ultimately the deadlock is there, but systemd will timeout the jobs (by
default after 1m 30s), so it's not a real deadlock, but it is still
something that could technically happen and delay boot.

>>>> 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.
> Again, I do see your point. In this particular I'm not sure there
> is much else we can do.

Yeah, that's somewhat my own conclusion so far too sadly... :s

>> Thanks for your input here. Domain knowledge is invaluable!
> That's how we *all* learn! :-)

Indeed :)

All the best

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/