Created attachment 76945 [details] logind.conf with HandleLidSwitch=ignore (GNOME dconf is buggy and can't do this) Hello! I'm using Systemd-198 on Archlinux. Today I've upgraded various packages on my box, including Systemd. Sadly it looks like, if "root" has logged in and *out* in on one off the tty's this prevents executing successfully "sytemctl reboot" or "sytemctl poweroff". Example: $ systemctl reboot # return-code 1 User root is logged in on tty4. User root is logged in on tty4. Please retry operation after closing inhibitors and logging out other users. Alternatively, ignore inhibitors and users with 'systemctl reboot -i'. In fact I logged in as root two times on tty4 and logged out, every time. But Systemd seems to believe this sessions still last. $ loginctl # this is just me regular user (tty2, tty3, gnome-terminal) SESSION UID USER SEAT 2 1000 peter seat0 3 1000 peter seat0 6 1000 peter seat0 3 sessions listed. $ systemd-inhibit --list # looks normal to me Who: root (UID 0, PID 299) What: sleep Why: inhibited Mode: delay Who: peter (UID 1000, PID 590) What: sleep Why: GNOME needs to lock the screen Mode: delay Who: peter (UID 1000, PID 590) What: handle-power-key:handle-suspend-key:handle-hibernate-key Why: GNOME handling keypresses Mode: block 3 inhibitors listed. Steps to reproduce: 1. power on system 2. login as regular user on a tty 3. login as root on a tty 4. logout as root 5. execute "sytemctl reboot" 6. fails with message from above Further resources (I'm not involved): https://bbs.archlinux.de/viewtopic.php?id=23634 # german, warning -> the get confused during discussion (e.g. sudo, mix old "poweroff" with "systemctl poweroff") http://www.mail-archive.com/arch-general@archlinux.org/msg32977.html # english (but server seem to be buggy, at time of writing) Bug maybe related with this new feature? > Inhibitors are now honored and listed by "systemctl > suspend", "systemctl poweroff" (and similar) too, not only > GNOME. These commands will also list active sessions by > other users. Thank you
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.
https://bbs.archlinux.org/viewtopic.php?id=159752
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.