Users Not Logged Out Completely On Multi-User Install - SOLVED

[EvilSupahFly]

I'm running a clean install of Linux Mint 20.2 with Cinnamon 5.0.7 on Kernel 5.11.0-40-generic. Complete system specs at https://termbin.com/ew6i for the curious.

Here's the problem - or what I perceive to be a problem.

When a user logs in - say Tom - everything is fine, provided Tom is the first one to log in after a reboot. If Tom logs out completely, then Sam logs in after with his own ID, it starts lagging a little and resource usage is looking high. So I open a terminal and run ps aux. There, I can see that not all processes running for Tom were stopped when he logged out.

So I have to kill them myself. Then, when Sam logs out, the same thing happens. Someone else can log in, we see that there are still things running under "Sam" so we kill them, wash, rinse, repeat. After one such instance, I saved the terminal output to a file which is posted at https://pastebin.com/qXcmxrkL if you want to see what I'm talking about. I should note however that lines like root 52988 0.0 0.0 0 0 ? I 03:24 0:00 [kworker/7:1-events] were removed from the output, having been considered not relevant.

Is this is by design to facilitate faster logins, or a bug? Am I even in the right place for this issue?

I'm happy to provide any additional information you feel could help - just ask.

[mikeflan]

I think I see that %mem and %cpu for tom processes add to zero. Maybe this is not a problem??

Try this one-liner:

Code: Select all

ps hax -o rss,user | awk '{a[$2]+=$1;}END{for(i in a)print i" "int(a[i]/1024+0.5);}' | sort -rnk2

taken from here:
https://stackoverflow.com/questions/142 ... e-in-linux

[EvilSupahFly]

That's interesting. I hadn't realized that the other person's post-logout processes added to zero. Clearly, if they're zero, they can't be causing the lag.

I'm curious though why those processes are left running after a user logs out. That doesn't seem right... Or secure.

Here is the output from that command series, which I ran through a remote terminal (because the machine is physically inaccessible to me at the moment):

Code: Select all

seann on black-beast Mon Nov 29 08:41 PM
[~] $ ps hax -o rss,user | awk '{a[$2]+=$1;}END{for(i in a)print i" "int(a[i]/1024+0.5);}' | sort -rnk2
tom 4740
root 339
seann 45
colord 14
systemd-resolve 13
systemd-timesync 6
syslog 5
messagebus 5
avahi 4
rtkit 3
nvidia-persistenced 2
kernoops 1
seann on black-beast Mon Nov 29 08:41 PM
[~] $

[BeyondLies_MintForum]

Compare perhaps this bug report.

[EvilSupahFly]

Compare perhaps this bug report.

It's similar, but I don't experience any crashes. It lags a bit, but the system doesn't become completely unresponsive. I recently tested the limits of my percieved issue by logging in through multiple simultaneous SSH instances while at the same time running users in all the available TTYs. I determined that those sessions didn't have any problems. When logging out, nothing appeared to be left running after those sessions were logged out - they all logged out completely. It's just when using the GUI that I see the residual processes and experience the lag.

[mikeflan]

That doesn't seem right... Or secure.

It might not be right, but I wouldn't worry about the security. No known method to exploit the processes.

[karlchen]

Hello, EvilSupahFly.

The answer to your question might be found perhaps by reading the manpage on logind.conf.
Terminal command: man logind.conf
Most relevant section, the section on KillUserProcesses=.

Code: Select all

       KillUserProcesses=
           Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If
           true, the scope unit corresponding to the session and all processes inside that scope will be terminated. If false,
           the scope is "abandoned", see systemd.scope(5), and processes are not killed. Defaults to "yes", but see the options
           KillOnlyUsers= and KillExcludeUsers= below.

           In addition to session processes, user process may run under the user manager unit user@.service. Depending on the
           linger settings, this may allow users to run processes independent of their login sessions. See the description of
           enable-linger in loginctl(1).

           Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the
           session scope. See example in systemd-run(1).

On my system, user processes were only terminated, after the user had logged off from the GUI, once the commented entry #KillUserProcesses=yes had been uncommented, KillUserProcesses=yes, and systemd had been reloaded.

Regards,
Karl

[EvilSupahFly]

That doesn't seem right... Or secure.

It might not be right, but I wouldn't worry about the security. No known method to exploit the processes.

Yet.

Hello, EvilSupahFly.

The answer to your question might be found perhaps by reading the manpage on logind.conf.
Terminal command: man logind.conf
Most relevant section, the section on KillUserProcesses=.

Code: Select all

       KillUserProcesses=
           Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If
           true, the scope unit corresponding to the session and all processes inside that scope will be terminated. If false,
           the scope is "abandoned", see systemd.scope(5), and processes are not killed. Defaults to "yes", but see the options
           KillOnlyUsers= and KillExcludeUsers= below.

           In addition to session processes, user process may run under the user manager unit user@.service. Depending on the
           linger settings, this may allow users to run processes independent of their login sessions. See the description of
           enable-linger in loginctl(1).

           Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the
           session scope. See example in systemd-run(1).

On my system, user processes were only terminated, after the user had logged off from the GUI, once the commented entry #KillUserProcesses=yes had been uncommented, KillUserProcesses=yes, and systemd had been reloaded.

Regards,
Karl

And this is exactly what I was looking for. An explanation of the behaviour, insight as to whether or not it was by design, and a fix.

This is why I always come here first: everyone is always helpful and full of good suggestions and insights. And in this case, Karl gave me the answer I needed.

Thanks to everyone who offered insight and helped me learn a few new things, and thanks to Karl, I'm marking this 'solved.'

[Larry78723]

If you have found the solution to your initial post, please open your original post, click on the pencil, and add (Solved) to the Subject.