Re: Why does stopping mount units kill user sessions?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 16.05.23 22:20, Frank Steiner (fsteiner-mail1@xxxxxxxxxxxxxx) wrote:

> Hi,
>
> after Don gave me the hint about the automounter problem in the
> other mail I still didn't understand why stopping a mount unit
> should kill the user's session, so I tried that manually.

systemd implements a dependency system. If you explicitly tell systemd
you want some unit gone it will comply – within the logic of the
dependenc tree, and hence shut down depending units too.

> And indeed, with
>
> <server>:/b /home/b nfs4 defaults,noauto,x-systemd.automount 0 0
>
> in /etc/fstab, /home/b will be mounted if user biouser with
> /home/b/biouser logs in via ssh.
>
> Then, calling "systemctl stop home-b.mount" as root afterwards
> will kill this ssh session of biouser.
>
> Is that how it should be? Why? Shouldn't stopping the unit
> fail because /home/b/ is busy? Just like it happens when
> calling "umount /home/b" (=> "umount.nfs4: /home/b: device is busy")

If we did that we could never shut down the system, because there's
always something that keep our units busy...

>
> journal shows this for the stop command:
> May 16 22:08:03 bioserver3 systemd[1]: home-b.mount: Trying to enqueue job home-b.mount/stop/replace
> May 16 22:08:03 bioserver3 systemd[1]: session-73.scope: Installed new job session-73.scope/stop as 15216
> May 16 22:08:03 bioserver3 systemd[1]: home-b.mount: Installed new job home-b.mount/stop as 15215
> ...
>
> So a stop job for the user session is installed and kills all
> the processes of the ssh login of biouser.
>
> This also happens when the mounting was done by someone else,
> e.g. root, by "ls /home/b", so that it is already mounted when
> biousers logs in with ssh. But still the ssh session is killed
> when stopping the mount unit. So systemd is not killing the session
> of the user who invoked the mount of /home/b, but of the user
> who is currently using it.

systemd-logind installs a dependency between the homedir mount and
logged in sessions of a user. This conversely means that homedirs that
are unmounted also take to down the sessions of the user.

> When logging in as root and then calling "su -l biouser", then
> "systemctl stop home-b.mount" returns 'Job failed. See "journalctl -xe"
> for details.' and the reason is "umount.nfs4: /home/b: device is busy".
> And the journal shows no tryentry about stopping a session.scope/

logind creates the arforementioned dep and that's what pid 1 then
operates with. if you keep the mount busy some otherwise pid1 won't be
aware and even if it wanted it couldn't terminate the offending
process, since it doesn't know which one that would be.

> So, can someone explain
> a)  why the ssh session of biouser is killed when stopping the mount
>     unit of his home dir?

Conceptually that's the only thing that makes sense: a session doesn't
really make sense without the user's homedir being mounted. Much of
the user's exec context (.e. various env vars) reference the home dir
directly, and generally session processes are invoked with the cwd set
to the home dir, hence a session without the user's home dir mounted
doesn't really make any sense conceptually.

Hence: if you ask us to take down the home dir of user X we'll also
have to take down the sessions of user X since we are happy to
comply with your requests but the deps encode what the deps encode and
we follow.

> b) why the session is not killed when invoked with "su -l biouser"?

That doesn't open a new session. It just changes user ids.

> And is there a way I can change a) so that the ssh session stays
> and the stop job returns "device busy" just as in b)?

No, there is not. And it doesn't really make sense.

For the original issue at hand: clearly autofs is borked here, as it
doesn't consider other mount namespaces than the main for idle
detetcion. They should fix that, but that's not really a systemd
problem so much than a kernel problem.

That said, I think we probably should change systemd-logind to
implicitly and unconditionally keep an open fd to the home dir of a
user around as long as there's at least one session of them around,
simply to make clear that sessions keep home dirs busy. This, as side
effect would then also mean that autofs wouldn#t be tempted to
consider the home dir idle as long as there's a session.

Lennart

--
Lennart Poettering, Berlin