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

[Steve Dickson]

On 01/12/2015 05:40 PM, Colin Guthrie wrote:
> 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.
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.

> 
> 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).
OK.

> 
>>> 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.
 
> 
> 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.
Again, suggestions are always welcomed!

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

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

steved.