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@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@nfs.service+Before=systemd-fstype@nfs.service >>> and all is well) - there shouldn't really be a strong need for any >>> actual changes to systemd-fstype@.service (or any >>> systemd-fstype@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
