Re: [EXT] Re: Why does stopping mount units kill user sessions?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Benjamin Godfrey
Sent: Friday, May 19, 2023 4:59 PM
To: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [EXT] Re: 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. 
}

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux