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

[Helmut Grohne]

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.

Helmut