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.
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?
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
