[SOLVED] logind 222 fails to remove session on tty1 after logout

Trilby · 2015-07-27 22:53:23

(EDIT: this has been fixed in systemd 224.)

I've found that as of systemd 222-1 logind fails to remove the session when I log out of a tty - but only on tty1. Everything works as expected on other ttys, and I've confirmed that a downgrade to 221 resolves the problem. This failure to remove the session leads to a failure to create a new session and a laundry list of other issues described below.

Full History

I've set up all my machines to auto-login to the tty, and from there start X at login each following the linked wiki sections. Here is my bash_profile:

[[ -z $DISPLAY && $XDG_VTNR -eq 1 && $(tty) == "/dev/tty1" ]] && exec xinit -- vt1 -nolisten tcp

[[ -f ~/.bashrc ]] && . ~/.bashrc

The tty check is to prevent the condition form matching from within tmux - but the same problem (below) occurs without that.

I have used this set up on three different machines for quite a while, but quite recently it has been consistently failing to restart X if I logout (e.g., `killall xinit` from a terminal). It first became clear that when I logged out of X, I was in a new tty session, but it seemed bash_profile may not have been read. I tested this by putting some echo strings in bash_profile, and it was read, but the conditional failed.

Through more testing with similar echo commands in the bash_profile I discovered that on the first login to tty1 XDG_VTNR was properly set, but on subsequent logins it was not set. I verified that XDG_VTNR was not present in the environment (via `env`) but I also notices XDG_SESSION_ID, XDG_SEAT, and a few others were missing. This lead me to suspect a login session issue. But `loginctl` shows the same output regardless:

   SESSION        UID USER             SEAT
        c4       1000 username         seat0
        c1       1000 username         seat0

2 sessions listed.

I then switched to a different tty, logged in, logged out, and logged back in, and all the right environment variables were still present. So it seems the problem is only occurring on tty1 with the autologin setup, but not on tty3 with a regular username/password login.

I figured this was likely a problem with the autologin settings - perhaps something changed with a recent update and the wiki may be out of date. To test this, I disabled autologin on tty1. Upon reboot I logged into tty1 with my username and password. X started as expected and when I logged out of X I was returned to a new login screen as expected. I entered my username and password again and found that the XDG_VTNR and other variables were again absent from the environment. So - to my surprise - this is not a problem with auto starting of X or autologin to the tty; this is a problem with my TTY1.

To simplify further, I removed my bashrc. Yet the problem persisted, the first login to tty1 works, subsequent logins lack the XDG_VTNR and other variables.

Along the way of exploring this issue I found another very odd symptom. If, from this terminal that lacks XDG_VTNR I try to start X by filling in the number myself as follows, I get a frozen X session:

xinit -- vt1 -nolisten tcp

Within that X session, I get my terminal which is started from xinitrc, but I cannot interact with it. No keys do anything. I can't even change tty's with Ctrl-Alt-F#. All I can do is a hard poweroff. I don't know what to make of this symptom, but perhaps it will mean something to someone else. I think figuring out why the XDG_* variables are missing makes a better attack surface for the problem.

I've compared the tails of journalctl output after several repreated login/logouts in both a working tty3 and the malfunctioning tty1. Here's the working one (editted only with a sed replacement of my username with 'username'):

Jul 27 18:27:40 Think login[478]: pam_unix(login:session): session closed for user username
Jul 27 18:27:40 Think systemd[1]: getty@tty3.service: Service has no hold-off time, scheduling restart.
Jul 27 18:27:40 Think systemd-logind[287]: Removed session c2.
Jul 27 18:27:40 Think systemd[1]: Started Getty on tty3.
Jul 27 18:27:40 Think systemd[1]: Starting Getty on tty3...
Jul 27 18:27:45 Think login[489]: pam_unix(login:session): session opened for user username by LOGIN(uid=0)
Jul 27 18:27:45 Think systemd-logind[287]: New session c3 of user username.
Jul 27 18:27:45 Think systemd[1]: Started Session c3 of user username.
Jul 27 18:27:45 Think systemd[1]: Starting Session c3 of user username.
Jul 27 18:27:45 Think login[489]: LOGIN ON tty3 BY username

And the malfunctioning tty1 (similarly edited only for username):

Jul 27 18:28:37 Think login[507]: pam_unix(login:session): session closed for user username
Jul 27 18:28:37 Think systemd[1]: getty@tty1.service: Service has no hold-off time, scheduling restart.
Jul 27 18:28:37 Think systemd[1]: Started Getty on tty1.
Jul 27 18:28:37 Think systemd[1]: Starting Getty on tty1...
Jul 27 18:28:41 Think login[517]: pam_unix(login:session): session opened for user username by LOGIN(uid=0)
Jul 27 18:28:41 Think login[517]: pam_systemd(login:session): Cannot create session: Already occupied by a session
Jul 27 18:28:41 Think login[517]: LOGIN ON tty1 BY username

The first difference, that likely leads to the others, is the *absence* of systemd-logind removing the session in the malfunctioning tty. It makes sense that this leads to the failure of the creation of a new session. And this would lead to the failure to autostart X. I don't know how this would lead to the "frozen" X, but if I can fix it I don't so much care about why that symptom occurred.

I don't know precisely when this started happening as I rarely restart X without also rebooting. But I know that restarting X with my current configuration *has* previously worked without issue. Given the difference in systemd-logind messages in the journals above, I tried downgrading from systemd 222-1 back to 221-1 which worked. So that leads me to the title of my post - but I'm at a loss at how to proceed further to get this working with systemd 222.

Last edited by Trilby (2015-07-27 23:36:06)

jasonwryan · 2015-07-27 23:07:59

See this thread (with a too-specific title): https://bbs.archlinux.org/viewtopic.php?id=200069

Trilby · 2015-07-27 23:35:15

Ah, that's exactly it, thanks. Sorry I missed that one.

It seems for me rather than gpg-agent discussed there, the culprit is tmux. As long as I kill tmux I can restart just fine. So it is not specific to tty1, it's just a coincidence that I furst start tmux on tty1. However, killing tmux is not a good solution in my book - it rather defeats the purpose of running it (I want my detached session to persist). So hopefully 223 will patch this up. Otherwise I may have to look into running tmux as a service ... I'd rather not.

But with the above information, the issue is solved an this level. It remains for upstream to hopefully patch this up.

jasonwryan · 2015-07-27 23:50:11

FWIW: it seems to be triggered by any process that is designed to persist across sessions: I see it with tmux and when running keychain.

Trilby · 2015-07-28 00:06:20

I've been doing some experimenting and found that dbus-launch is sufficient to trigger the problem. That makes me feel a bit better: sometimes we crazy minimalists can get overlooked, but if dbus-launch isn't working, that should get attention upstream.

ondoho · 2015-07-29 09:55:35

i just noticed the same.

i tried changing the files in /etc/systemd/system to autologin on tty2, but then i have the same problem on tty2...

would it be a sufficient workaround to change

[[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && exec startx

to

[[ -z $DISPLAY && $(tty) == "/dev/tty1" ]] && exec startx

in ~/.bash_profile?

i will try, but for now i'm tired of logging out & rebooting...

Trilby · 2015-07-29 10:39:54

Please read my OP in this thread. The condition you describe would pass - but the absence of the XDG_VTNR is merely a symptom, it is not the main problem.

dustmote · 2015-07-30 18:13:55

still broken on 223-1 ... Trilby, is there a *proper* place for us 'crazy minimialists' to voice this issue?

Trilby · 2015-07-30 21:53:45

The proper place would be an upstream bug report. But I haven't had the time to do the proper prep work for that. I think much of the content of my first post would be useful in an upstream bug report, but one would also need to check whether this was already reported.

There is a bug report linked from the other thread, but it was unfortunately focused just on this problem occurring with XFCE. But I haven't had time to read through the upstream bug thread to see where it is going or if there are similar reports. Feel free to look into that if you can - I'd appreciate it.

EDIT: oops - I just noticed the existing bug report is on the XFCE tracker. That's just completely the wrong place for it. So we should start a bug report for the systemd team (after also checking there to see if there is another one).

mauritiusdadd · 2015-07-30 22:56:50

It seems that it has already been reported: https://github.com/systemd/systemd/issues/792

Trilby · 2015-07-30 23:08:35

Is that an official systemd page ... on github?

Systemd uses bugzilla, not github comments, as far as I know. This one looks relevant:
https://bugs.freedesktop.org/show_bug.cgi?id=89834

Alad · 2015-07-31 00:01:50

Trilby wrote:

Is that an official systemd page ... on github?
Systemd uses bugzilla, not github comments, as far as I know. This one looks relevant:
https://bugs.freedesktop.org/show_bug.cgi?id=89834

http://lists.freedesktop.org/archives/s … 32652.html

Arch Linux

#1 2015-07-27 22:53:23

[SOLVED] logind 222 fails to remove session on tty1 after logout

#2 2015-07-27 23:07:59

Re: [SOLVED] logind 222 fails to remove session on tty1 after logout

#3 2015-07-27 23:35:15

Re: [SOLVED] logind 222 fails to remove session on tty1 after logout

#4 2015-07-27 23:50:11

Re: [SOLVED] logind 222 fails to remove session on tty1 after logout

#5 2015-07-28 00:06:20

Re: [SOLVED] logind 222 fails to remove session on tty1 after logout

#6 2015-07-29 09:55:35

Re: [SOLVED] logind 222 fails to remove session on tty1 after logout

#7 2015-07-29 10:39:54

Re: [SOLVED] logind 222 fails to remove session on tty1 after logout

#8 2015-07-30 18:13:55

Re: [SOLVED] logind 222 fails to remove session on tty1 after logout

#9 2015-07-30 21:53:45

Re: [SOLVED] logind 222 fails to remove session on tty1 after logout

#10 2015-07-30 22:56:50

Re: [SOLVED] logind 222 fails to remove session on tty1 after logout

#11 2015-07-30 23:08:35

Re: [SOLVED] logind 222 fails to remove session on tty1 after logout

#12 2015-07-31 00:01:50

Re: [SOLVED] logind 222 fails to remove session on tty1 after logout

Board footer