Bug#990177: starting a path-restricted .service unit un-idles a .automount

Luca Boccassi bluca at debian.org
Mon May 27 17:40:54 BST 2024


Control: tags -1 wontfix
Control: close -1

On Tue, 22 Jun 2021 08:32:12 +0200 Helmut Grohne <helmut at subdivi.de>
wrote:
> Package: systemd
> Version: 241-7~deb10u7
> Tags: upstream
> 
> Hi,
> 
> systemd provides a unit type .automount that is equipped with a
> parameter TimeoutIdleSec. What that time passed without anything
> accessing the relevant directory, the automount is umounted.
> 
> That behaviour mostly works except that there is one thing that keeps
> accessing all mounts: systemd. Every time a path-restricted unit
(i.e.
> one using InaccessiblePaths/ReadWritePaths/ReadOnlyPaths, e.g.
implied
> by DynamicUser=yes) is started, systemd calls statfs on every mount
> point. statfs in turn tells autofs that the filesystem is in use
(unless
> specifying the "strictexpire" option, see
> https://github.com/systemd/systemd/issues/18445). If services are
> started sufficiently frequently, automounts never expire.
> 
> A workaround can be listing all automount paths as InaccessiblePaths
for
> frequently started .service units.
> 
> In any case, this behaviour is far from ideal. We'll only see more
and
> more units making use of these kind of restrictions and with more
units
> using them, automount timeouts become completely useless. I think
this
> needs to be solved on the systemd side for good.
> 
> I wasn't able yet to reproduce this on a more recent version of
systemd.
> Therefore, I'm not reporting it upstream. I am reasonably confident
that
> this issue persists upstream.
> 
> Sketch for reproducing:
>  * Create an .automount unit with a TimeoutIdleSec of e.g. 5 minutes.
A
>    tmpfs should do.
>  * Create a Type=oneshot .service unit that e.g. runs /bin/true with
>    DynamicUser=true.
>  * Create a matching .timer unit that runs the previous unit once a
>    minute.
>  * Access the automount.
>  * Observe that it never gets umounted.
>  * Optionally strace -e trace=statfs -f -p 1 to see who keeps the
>    filesystem mounted.

This is tracked upstream, and also as mentioned there it can't really
be done because we lack the kernel APIs to check things without
triggering automounts.

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20240527/9f256646/attachment.sig>


More information about the Pkg-systemd-maintainers mailing list