[systemd-devel] [EXT] Re: Why does stopping mount units kill user sessions?
Benjamin Godfrey
mr.benjamingodfrey at gmail.com
Thu May 25 17:47:31 UTC 2023
Windl Ulrich rebutted:
Actually I don't quite get it:
If some process is inside $HOME, $HOME shouldn't be unmounted (i-node busy,
or so).
But when there is no process inside $HOME (and no other fd opened on it),
when not allowing to unmount $HOME?
Where does opening an extra fd on $HOME help?
Benjamin Godfrey replied:
Perhaps, I don't understand your objection. Maybe, you are concerned about
a scenario wherein the situation below is true, i.e. there is an open fd in
the $HOME directory keeping the directory open for an active process, and
another fd is added by yet another process, stalling the unmount.
The file descriptor is used as a signal to systemd-login to stay mounted.
For example, User Ulrich is running a media player and/or a text editor
inside the home directory, and let’s say Ulrich’s system is also collecting
data from another server about an unexplained atmospheric phenomenon (UAP)
that needs to be processed on Ulrich’s computer because it has the fastest
processing time. This UAP data is collected via an automated process. In
this condition, the computer would keep an fd inside the $HOME directory to
make sure that the home directory stays mounted.
Ulrich forgets he has important UAP data coming in, and he notices his
system is running a little slow. Ulrich takes a break, turning off his
music, saving his work from the text editor, and logs out. Here, you
don’t want your system to unmount until after the UAP data is finished, so
it’s good to have an open fd in the $HOME directory. (Hopefully, when the
UAP data process is finished it closes the fd.) Once systemd-login spots
that the file descriptor is closed, then it can unmount the home
directory.
You don’t want signal interruptions that could cause data to be lost or
delayed, and: it is generally a good idea to keep an open fd in a user's
home directory, even if there are no processes currently accessing it. This
will help to prevent problems if a process needs access to the home
directory in the future.
On Wed, May 24, 2023 at 11:44 PM Windl, Ulrich <u.windl at ukr.de> wrote:
> Actually I don't quite get it:
> If some process is inside $HOME, $HOME shouldn't be unmounted (i-node
> busy, or so).
> But when there is no process inside $HOME (and no other fd opened on it),
> when not allowing to unmount $HOME?
> Where does opening an extra fd on $HOME help?
>
> -----Original Message-----
> From: systemd-devel <systemd-devel-bounces at lists.freedesktop.org> On
> Behalf Of Benjamin Godfrey
> Sent: Friday, May 19, 2023 4:59 PM
> To: systemd-devel at lists.freedesktop.org
> Subject: [EXT] Re: [systemd-devel] Why does stopping mount units kill user
> sessions?
>
> Lennart Poettering, wrote:
>
>
> 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.
>
>
>
> Benjamin Godfrey's reply:
>
>
> That seems like a good idea. This can be done simply by modifying the
> logind_handle_homedir_umount function to:
>
> C
> static void
> logind_handle_homedir_umount(struct logind_client *client,
> const char *homedir)### The function takes
> two arguments client and homedir. client points to a struct loginid_client
> object### and homedir is a string that points to the users homedir. {
> struct logind_session *session;
> bool active_sessions = false; ### This sets the variable to false by
> default
>
> session = logind_client_find_session_by_homedir(client, homedir);
> if (session) {
> active_sessions = true; ### There is an active session
> }
>
> if (active_sessions) {
> return; ### A session is active, don't shut
> down.
> }
>
> logind_session_kill(session); ### Shut it down because there is no
> active session by default.
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230525/f9495cb6/attachment.htm>
More information about the systemd-devel
mailing list