| Summary: | systemctl [reboot|shutdown] wronly believes root is still logged in on a tty | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Peter Weber <peter.weber> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
| Severity: | major | ||
| Priority: | medium | CC: | lisaev |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
logind.conf with HandleLidSwitch=ignore (GNOME dconf is buggy and can't do this)
dump of journalctl |
||
|
Description
Peter Weber
2013-03-23 17:31:51 UTC
Relevant commit: http://cgit.freedesktop.org/systemd/systemd/commit/src/systemctl?id=59164be40e6b520315d87e1ef16a3be65c854224 from sd-login.h (didn't found implementation): /* Get all sessions, store in *sessions. Returns the number of * sessions. If sessions is NULL only returns number of sessions. */ int sd_get_sessions(char ***sessions); from systemctl.c: _cleanup_strv_free_ char **sessions = NULL; // it is NULL?? Sorry! Of course it is not NULL it is the address of "sessions" variable. http://cgit.freedesktop.org/systemd/systemd/tree/src/systemd/sd-login.h // from sd-login.h /* Get all sessions, store in *sessions. Returns the number of * sessions. If sessions is NULL only returns number of sessions. */ int sd_get_sessions(char ***sessions); http://cgit.freedesktop.org/systemd/systemd/tree/src/login/sd-login.c // from sd-login.c _public_ int sd_get_sessions(char ***sessions) { return get_files_in_directory("/run/systemd/sessions/", sessions); } This directory contains a ASCII-File and a PIPE, after "root" has logged out from the TTY the pipe is gone. But the ASCII-File is still there and contains: # This is private data. Do not parse. UID=0 USER=root ACTIVE=0 STATE=closing REMOTE=0 KILL_PROCESSES=0 TYPE=tty CLASS=user SEAT=seat0 TTY=tty2 SERVICE=login VTNR=2 LEADER=12877 AUDIT=3 Well. This file remains there. It doesn't go away. Is it possible that your session actually does stay around, for example because there is "screen" or something else forked into the background still running? Can you check if there are still any processes in the dead session's cgroup? Can you tell me how I should investigate the dead sessions cgroup? ps -je PID PGID SID TTY TIME CMD ... 2948 2948 2948 tty3 00:00:00 agetty # no one is logged in here anymore 3821 3821 3821 tty2 00:00:00 bash # here im logged in as user 3857 3857 3857 tty4 00:00:00 agetty # no one is logged in here anymore ... agetty seems to remain open, after i've logged out on every tty. But this should be normal? I should answer or first question also: No there is noting, I just login and immediately "logout". No screen or other background jobs. Hmm, weird. When you log in, "echo $XDG_SESSION_ID", which will tell you your session id. Then log out and check "cat /sys/fs/cgroup/systemd/user/ABC/XYZ/tasks" where you replace ABC by your username, and XYZ by the session ID you wrote down earlier. This will gvie you the list processes in your session... Good Morning! Thank you for your instructions! I've tested this with my regular user and root. If I'm a user the path "/sys/fs/cgroup/systemd/user/username" exists, but the directories under it offer only active sessions. The same happens as root, just with the difference that "/sys/fs/cgroup/systemd" is the dead-end, because root has no other parallel logins in use. Created attachment 77034 [details]
dump of journalctl
1. login as user peter on tty2
2. login as user peter on tty3
3. login as root on tty4
4. logout as user pter on tty2
Maybe this give a hint.
I have noticed this when systemd 198 was just released, but didn't have time to report... sorry. My system is fully up-to-date archlinux x86_64 with systemd 198-2. Here is what I sent to arch-general ML: https://mailman.archlinux.org/pipermail/arch-general/2013-March/033078.html Basically, systemd wrongly believes that there is an active inhibitor lock when root logs in, and then logs out on a tty. However, root has no running shells, loginctl shows only an unprivileged user session, and systemd-inhibit returns 0 inhibitors. Thanks, Leonid. Just an FYI: this is _not_ fixed in systemd-199. This is (also) not fixed with systemd-200. I've also tested this in the meanwhile on Fedora 18, with systemd-197. The bug does also exist there, the session-file are not removed! The only difference is, that sytemd-197 doesn't honor the inhibitors (because this feature was added with 198). So, this is a old bug. While Archlinux is merely upstream "GNU/Linux", this also proves that this is not a distribution-specific bug. this_is_not_fixed in systemd-201 This probably fixed it: http://cgit.freedesktop.org/systemd/systemd/commit/?id=50fb97935d689a520251b2d543599be14bdfd0ed Thank you! Confirmed, the above patch resolves the issue... Thanks! I'll mark this bug as RESOLVED, please reopen if appropriate. With systemd 218 on Arch Linux, the issue still appears to occur intermittently. I'll see if I can provide more details, but I had the message in the first post when root was no longer logged in tty2. Closing this. If this issue is still relevant on current systemd versions, please file a new bug on systemd github |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.