Logged out session still tracked by logind #26744
Comments
|
Experiencing this as well. Same system configuration. |
|
Same problem with Fedora 38, systemd-253.2-1.fc38.x86_64 |
|
I think this problem has been around for a while; see bug #14850. I'm noticing it on a system with systemd 245.4. |
|
An easy way to reproduce this using |
|
After some dbus-monitor and strace commands, I find that systemd isn't emitting the I tried to figure out why the signal isn't sent, but I wrongly pressed Ctrl-C at |
|
|
@venkatkchandra sorry, but 239 is simply too old. This code has changed a lot since then. Issues with such old versions should be reported to the downstream distro, not here upstream |
|
@hexchain is this a cgroupsv2 system? |
Yes. |
|
Any chance you can check if #27968 helps? |
|
I tried to reproduce the bug in a VM via the machinectl command, but that alone does not trigger the issue. If I can (more or less reliably) reproduce it in the VM, I can try the patch One observation that suggests that the patch might not be the complete solution: |
Had the same experience with the CentOS 239-58. Once sessions get into closing, further sessions do not get cleaned up and you empty the quota of 8192 connections, duration depending on the load on the system. This is a long standing issue, I believe. I was unable to reproduce with The following is the evidence that it gets into the |
This is correct with 239-58 also. |
This is the upstream bug tracker of systemd. We only track recent versions of systemd here, i.e. v252+v253 here. v239 is waaaaaaaaaay too old. Please do not add noise to bug reports here. Also, centos 8 afaik still uses cgroupsv1, where cgroup empty events are unreliable to the point of uselessness. there it is pretty likely pid1 won't notice when a cgroup runs empty, which might cause the issue at hand here. |
Given that it was merged, I built and installed the current master (fcc0668), but after rebooting I was unable to log into the Plasma Wayland session.
I'll be running this build for a few days and see if the logind issue still happens. |
|
I am not familiar with kde but when I searched i don't remember seeing it in the list of things shipping user units with sandboxing, where is it coming from? Ie can you show the user unit that is running that session? |
|
Here are the logs of |
|
I don't see any sandboxing there, are you sure that's the right unit? |
|
Pretty sure it is. Looking at Service override: Journal: PID 1: |
|
Then what you posted cannot be the full list of settings, something is missing. Try with systemctl cat |
|
|
what about the per-user systemd instance? i.e. |
|
The user service looks like this: |
|
I've added some log outputs to |
|
Ah, good find, that was changed from boolean to tristate concurrently so it was completely missed - are you able to send a PR? The fix is simply to check if it's > 0 |
|
Sure! Opened #28037. |
|
This issue doesn't seem to appear since I've switched to the main branch. I think we can call it fixed. However, now at 254rc1, EDIT: It gets a bit crazy over time: |
Follow-up for c26d783 waitpid() doesn't support WEXITED and returns -1 (EINVAL), which results in the intermediate close process not getting reaped. Fixes systemd#26744 (comment)
Follow-up for c26d783 waitpid() doesn't support WEXITED and returns -1 (EINVAL), which results in the intermediate close process not getting reaped. Fixes systemd#26744 (comment)
Closing then :)
Just opened #28348, hope that helps. But that's off-topic here. |
Follow-up for c26d783 waitpid() doesn't support WEXITED and returns -1 (EINVAL), which results in the intermediate close process not getting reaped. Fixes systemd#26744 (comment)
At the same time, 8b6c039 is reverted, i.e. session state is removed from the output. It was added to workaround systemd#26744, and doesn't really make too much sense after the issue is properly fixed.
At the same time, 8b6c039 is reverted, i.e. session state is removed from the output. It was added to workaround systemd#26744, and doesn't really make too much sense after the issue is properly fixed.
At the same time, 8b6c039 is reverted, i.e. session state is removed from the output. It was added to workaround systemd#26744, and doesn't really make too much sense after the issue is properly fixed.
At the same time, 8b6c039 is reverted, i.e. session state is removed from the output. It was added to workaround systemd#26744, and doesn't really make too much sense after the issue is properly fixed.
At the same time, 8b6c039 is reverted, i.e. session state is removed from the output. It was added to workaround systemd#26744, and doesn't really make too much sense after the issue is properly fixed.
At the same time, 8b6c039 is reverted, i.e. session state is removed from the output. It was added to workaround systemd#26744, and doesn't really make too much sense after the issue is properly fixed.
At the same time, 8b6c039 is reverted, i.e. session state is removed from the output. It was added to workaround systemd#26744, and doesn't really make too much sense after the issue is properly fixed.
At the same time, 8b6c039 is reverted, i.e. session state is removed from the output. It was added to workaround systemd#26744, and doesn't really make too much sense after the issue is properly fixed.
At the same time, 8b6c039 is reverted, i.e. session state is removed from the output. It was added to workaround systemd#26744, and doesn't really make too much sense after the issue is properly fixed.
Despite multiple attempts/claims at fixing this, logind still often has empty "State: closing" sessions after logout, without any processes in it [1]. Our generic nondestructive test cleanup in testlib's terminate_sessions() has a workaround for this (restarting logind). Do the same in this test. Only do this when waiting for the session to go away; starting new sessions should work fine. Fixes cockpit-project#20379 [1] systemd/systemd#26744
|
We still see this in our CI on latest systemd 256-rc1, and with all systemd versions before. Our workaround is to run |
Despite multiple attempts/claims at fixing this, logind still often has empty "State: closing" sessions after logout, without any processes in it [1]. Our generic nondestructive test cleanup in testlib's terminate_sessions() has a workaround for this (restarting logind). Do the same in this test. Only do this when waiting for the session to go away; starting new sessions should work fine. Fixes #20379 [1] systemd/systemd#26744
systemd version the issue has been seen with
253.1
Used distribution
Arch Linux
Linux kernel version used
6.2.1-arch1-1
CPU architectures issue was seen on
x86_64
Component
systemd-logind
Expected behaviour you didn't see
After a session has been logged out and all tasks are stopped, that session should no longer exist in
loginctl.Unexpected behaviour you saw
Logged out sessions still show up in
loginctl.In the following example, sessions 8, 10, and c3 are already logged out. Session 8 is a Plasma Wayland session, logged in through SDDM. Session 10 is a TTY session, created by C-A-F4 and logging in there.
Steps to reproduce the problem
I haven't figured out a stable way to reproduce, sorry.
The desktop manager in use is sddm/sddm@5341b06.
Additional program output to the terminal or log subsystem illustrating the issue
The text was updated successfully, but these errors were encountered: