Bug 62676 - systemctl [reboot|shutdown] wronly believes root is still logged in on a tty
Summary: systemctl [reboot|shutdown] wronly believes root is still logged in on a tty
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium major
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-23 17:31 UTC by Peter Weber
Modified: 2016-06-07 10:43 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
logind.conf with HandleLidSwitch=ignore (GNOME dconf is buggy and can't do this) (819 bytes, text/plain)
2013-03-23 17:31 UTC, Peter Weber
Details
dump of journalctl (91.18 KB, text/plain)
2013-03-26 08:40 UTC, Peter Weber
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Weber 2013-03-23 17:31:51 UTC
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
Comment 2 Peter Weber 2013-03-25 16:59:00 UTC
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??
Comment 3 Peter Weber 2013-03-25 17:12:51 UTC
Sorry! Of course it is not NULL it is the address of "sessions" variable.
Comment 4 Peter Weber 2013-03-25 17:42:57 UTC
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.
Comment 5 Lennart Poettering 2013-03-25 17:47:27 UTC
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?
Comment 6 Peter Weber 2013-03-25 18:31:50 UTC
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.
Comment 7 Peter Weber 2013-03-25 18:33:33 UTC
But this should be normal?
Comment 8 Peter Weber 2013-03-25 18:44:49 UTC
I should answer or first question also: No there is noting, I just login and immediately "logout". No screen or other background jobs.
Comment 9 Lennart Poettering 2013-03-25 19:11:25 UTC
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...
Comment 10 Peter Weber 2013-03-26 08:22:08 UTC
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.
Comment 11 Peter Weber 2013-03-26 08:40:26 UTC
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.
Comment 13 Leonid Isaev 2013-03-27 18:40:19 UTC
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.
Comment 14 Leonid Isaev 2013-03-28 22:24:25 UTC
Just an FYI: this is _not_ fixed in systemd-199.
Comment 15 Peter Weber 2013-04-07 13:23:14 UTC
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.
Comment 16 Peter Weber 2013-04-13 13:59:42 UTC
this_is_not_fixed in systemd-201
Comment 18 Peter Weber 2013-04-13 15:21:22 UTC
Thank you!
Comment 19 Leonid Isaev 2013-04-17 20:41:41 UTC
Confirmed, the above patch resolves the issue... Thanks!

I'll mark this bug as RESOLVED, please reopen if appropriate.
Comment 20 Alad Wenter 2015-02-26 16:18:24 UTC
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.
Comment 21 Lennart Poettering 2016-06-07 10:43:35 UTC
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.