You are not logged in.
Login on virtual console, run startx, quit Xfce and logout. After that login and run startx again. Now all input devices are dead and only a reset of the machine helps.
.xinitrc:
exec startxfce4
All other related config files are Arch vanilla. No changes in getty@tty1.service including drop-in snippets. Except of 'Option "XkbLayout" "de"' no tweaks in xorg.conf.d. .bashrc and .bash_profile are clean.
Downgrading to system-221-2 resolves this odd behaviour. Problem reproduced on three different machines (with Xfce).
Using .xinitrc with solely 'exec xterm' I was unable to reproduce the problem.
Is this a bug in Xfce or systemd? systemd git log shows some commits that could be related somehow...
Last edited by ctxfi-user (2015-08-07 10:36:38)
Offline
I can confirm that the sequence you describe also breaks here, but if I login on another vt and start xfce it works.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I can also confirm this breakage. The error after second login is probably associated with some changes to pam_systemd. Output from journalctl after second login:
login[995]: pam_unix(login:session): session opened for user aaa by LOGIN(uid=0)
login[995]: pam_systemd(login:session): Cannot create session: Already occupied by a session
login[995]: LOGIN ON tty1 BY aaa
Offline
I can confirm this as well. I run openbox via .xinitrc and I start it by typing startx after logging into tty1.
If I log out of openbox, log out of tty1, log back into tty1, and then type startx, X freezes. I can't even switch to another tty1; the only apparent remedy is a reboot.
Starting x on another tty works fine.
Offline
I think it was created by these commits in systemd:
https://github.com/systemd/systemd/comm … fdf7ab2084
https://github.com/systemd/systemd/comm … 5fde0d68c1
This seems to be a related issue: https://github.com/systemd/systemd/issues/536
However, I have no idea whether the fix there also solves the problem with startx. Will have to wait until systemd 223...
Last edited by madalu (2015-07-22 17:42:02)
Offline
I've been looking at this and I have found that the root of the problem may not be with systemd, just that the commits madalu links to expose the problem.
Try to login and startx on tty1 then logout, then login on tty2 and check if gpg-agent is still running on the session you started on tty1. Until you kill it you will not be able to start a new x session on tty1, this is due to the stricter check introduced in the commits madalu links to.
You have two options, either manually kill gpg-agent whatever keeps running after you logout or change KillUserProcesses to yes in /etc/systemd/logind.conf.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I have the same issue, and gpg-agent seems to be what's triggering it. I'll also note that you can use loginctl to fix it after the fact. Run "loginctl" to get a list of sessions, then, as root, run "loginctl terminate-session <session-id>". Log out and log back in, and your session should run properly.
Offline
I'm hitting this too, and since I'm working on a patch of xfwm4, i.e. need restarts, it is actually very annoying.
Offline
Thanks at everybody.
@R00KIE: Nice find. But where to fix? Assuming detaching from screen and relogin breaks too (not tested yet), then which fault is it? systemd or screen?
Offline
The "best" way to deal with this would be to have gpg-agent quit once you logout, although other things could still keep the session open and break things.
Regarding screen, if it stops once you logout then things are working as intended, see 'man logind.conf'. You can't have it both ways, either things can keep the session open or systemd will kill everything in the session once you logout.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Also add your experiences here: https://bugzilla.xfce.org/show_bug.cgi?id=11686
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
It seems this is not xfce-spefic - perhaps any backgrounded process could trigger it. A detached tmux session triggers this same problem for me as discovered here:
https://bbs.archlinux.org/viewtopic.php … 6#p1548346
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Simply
nohup sleep 3600 &>/dev/null &
and relogin is enough to reproduce missing input devices in Xorg. Regardless on which tty. And this could be the one and only start of Xorg (of this boot).
Unsure where the problem is, could be how rootless Xorg get started? Needs further investigations, if there is some time...
Offline
Offline
I can confirm it works here now with 224.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Same here, after the update to systemd 224 everything is back to normal.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline