[systemd-devel] Should automount units for network filesystems be Before=local-fs.target?

[Felipe Sateler]

On Thu, Apr 27, 2017 at 9:50 PM, Michael Chapman <mike at very.puzzling.org>
wrote:

> On Fri, 28 Apr 2017, Felipe Sateler wrote:
>
>> On Thu, 27 Apr 2017 15:53:51 +1000, Michael Chapman wrote:
>>
>> Hello all,
>>>
>>> At present, when systemd-fstab-generator creates an automount unit for
>>> an fstab entry, it applies the dependencies that would have been put
>>> into the mount unit into the automount unit instead.
>>>
>>> For a local filesystem, this automount unit would be
>>> Before=local-fs.target. For a network filesystem, it gets
>>> Before=remote-fs.target. If the mount is not noauto, it also gets a
>>> corresponding WantedBy= or RequiredBy= dependency.
>>>
>>> Would it make more sense for the automount unit to be ordered before
>>> (and,
>>> if not noauto, be pulled in by) local-fs.target, even for network
>>> filesystems?
>>>
>>> In a sense, the automount is a local filesystem, even though the thing
>>> that will eventually be mounted over the top of it isn't. Furthermore,
>>> this change would allow services that use automounted network filesystem
>>> to simply block until the filesystem has been mounted. Currently, for
>>> this to work correctly during boot, services need to be given explicit
>>> dependencies (e.g. After=remote-fs.target or RequiresMountsFor=...),
>>> since otherwise they may get started before the automount unit has
>>> started and thus be able to "see" the underlying filesystem.
>>>
>>> I'm trying to work out what might break with such a change. I suppose it
>>> is possible somebody has two automounted network filesystems nested
>>> within one another... the second automount would be dependent upon the
>>> first being mounted, but that mount won't happen until the network is
>>> brought up, which is after local-fs.target. This doesn't seem like a
>>> particularly likely configuration though.
>>>
>>> Is there any other reason this change wouldn't work?
>>>
>>
>>
>> I think the most likely failure point would be at shutdown:
>>
>> 1. foo.mount is unmounted, but foo.automount is still alive.
>> 2. some.service is not Requires/After foo.mount
>> 3. some.service tries to access /foo
>> 4. systemd tries to activate foo.mount
>> 5. boom
>>
>
> Well, the shutdown target is started irrevocably, so I suspect instead of
> "boom" the service will just block until it's stopped by systemd.


Well, I didn't test it, so "boom" was meant as "bad things happening" :)


>


> But yeah, you do raise a good issue.
>
> This is all a bit annoying. I've got a bunch of services (across multiple
> servers), but I don't necessarily know up front which services will be
> requiring access to network filesystems. I would prefer not to have to
> configure them all with After=remote-fs.target "just in case". I was hoping
> that by using automounts this wouldn't be necessary, but the services can
> end up being started _before_ those automounts.


> In a sense, this is a bit of a regression from sysv initscripts, because a
> lot of initscripts were shipped with "Required-Start: $remotefs" just as a
> precautionary measure, but most vendor-provided systemd units do _not_ have
> After=remote-fs.target.


> So is there any other way I could achieve what I want, or am I forced to
> drop in After=remote-fs.target wherever it might possibly be necessary?
>


It is my impression that the best course is to have your services have
RequiresMountsFor= the places they use. This way you ensure:

1. If mounts fail your service does not attempt to start.
2. Your service is stopped if the mount goes down.
3. Your service is started and stopped at the right time on boot/shutdown.

It's a bit more annoying, yes, but more precise. Failing that, you can add
After=remote-fs.target to all your services.

-- 

Saludos,
Felipe Sateler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170428/60bc4e74/attachment.html>