[Solved] Issues logging in with GDM

wsha · 2015-07-30 03:38:54

With a fully updated system, it is not possible for me to login via GDM. When the system is reverted back to systemd and libsystemd 221-2 (from 222-1), it is possible to login via GDM. Here is the behavior for the two cases:

systemd 221-2:
System boots to GDM login screen.
A user is selected and a password entered.
The user name selection elements disappear as they do for a normal login.
After a few seconds, the console is flashed on the screen and then the initial GDM login screen is shown again.
A user is selected and a password entered.
The selected desktop environment session begins as expected.

systemd 222-1:
System boots to GDM login screen.
A user is selected and a password entered.
The user name selection elements disappear as they do for a normal login.
After a few seconds, the console is flashed on the screen and then the initial GDM login screen is shown again.
A user is selected and a password entered.
Immediately, the initial GDM login screen is shown again.
Repeated login attempts continue to return to the initial login screen immediately.

I can post more logs if it's helpful (it would be nice to figure out the first login failure that occurs even for 221-2), but for now I will focus on the repeated login failure in 222. The relevant contents of journalctl for login attempts after the first seem to be (I cut out lots of normal-looking gdm-x-seesion messages):

Jul 29 07:08:49 mysystem gdm-password][838]: pam_unix(gdm-password:session): session opened for user myuser by (uid=0)
Jul 29 07:08:49 mysystem gdm-password][838]: pam_systemd(gdm-password:session): Cannot create session: Already occupied by a session
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE) systemd-logind: failed to get session: PID 855 does not belong to any known session
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (++) using VT number 2
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE)
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: Fatal server error:
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE) xf86OpenConsole: Cannot open virtual console 2 (Permission denied)
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE)
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE) systemd-logind: failed to get session: PID 855 does not belong to any known session
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE)
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: Fatal server error:
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE) xf86OpenConsole: Cannot open virtual console 2 (Permission denied)
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE)
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE)
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: Please consult the The X.Org Foundation support
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: at http://wiki.x.org
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: for help.
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE) Please also check the log file at "/home/myuser/.local/share/xorg/Xorg.0.log" for additional information.
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE)
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: (EE) Server terminated with error (1). Closing log file.
Jul 29 07:08:49 mysystem gdm-password][838]: pam_unix(gdm-password:session): session closed for user myuser
Jul 29 07:08:49 mysystem gdm[473]: GdmDisplay: display lasted 0.027368 seconds
Jul 29 07:08:49 mysystem /usr/lib/gdm/gdm-x-session[853]: Unable to run X server

With systemd 222, I opened a second terminal with Ctrl+Alt+F2 from the GDM login screen and logged in successfully. The log output for that login is below. Even after logging in this way, it was not possible to login via GDM.

Jul 29 07:09:07 mysystem systemd[1]: Started Getty on tty2.
-- Subject: Unit getty@tty2.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit getty@tty2.service has finished starting up.
--
-- The start-up result is done.
Jul 29 07:09:07 mysystem systemd[1]: Starting Getty on tty2...
-- Subject: Unit getty@tty2.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit getty@tty2.service has begun starting up.
Jul 29 07:09:13 mysystem login[891]: pam_unix(login:session): session opened for user myuser by LOGIN(uid=0)
Jul 29 07:09:13 mysystem login[891]: pam_systemd(login:session): Cannot create session: Already occupied by a session
Jul 29 07:09:13 mysystem login[891]: LOGIN ON tty2 BY myuser
Jul 29 07:10:38 mysystem systemd-logind[471]: Removed session c2.
-- Subject: Session c2 has been terminated
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: http://www.freedesktop.org/wiki/Software/systemd/multiseat
--
-- A session with the ID c2 has been terminated.
Jul 29 07:10:38 mysystem systemd[1]: Stopping User Manager for UID 1000...
-- Subject: Unit user@1000.service has begun shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit user@1000.service has begun shutting down.
Jul 29 07:10:39 mysystem systemd[783]: Removed slice -.slice.
-- Subject: Unit UNIT has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Last edited by wsha (2015-08-22 13:45:19)

berbae · 2015-07-30 08:37:42

If you disable Wayland, does it change something?
See the 'Use Xorg backend' at the end of the page https://wiki.archlinux.org/index.php/GDM

It would be better to see the entire log, rather than selected parts (I prefer without the -x option of journalctl).
You can use an external link towards the log file, if it is very long.

City-busz · 2015-07-30 20:24:42

I don't know why the first login fails for you, but the second login failure is caused by leftover processes (especially ssh-agent) from the first login. I reported this problem to upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=753076

A workaround is to add 'KillUserProcesses=yes' to '/etc/systemd/logind.conf'.

wsha · 2015-08-01 03:54:32

Thanks for the replies. I tried both of your suggestions but the problem did not go away. Then I tried creating a new user account and found that I could log in to that accout with GDM on the first try, so my problem was localized to my account's configuration. After some testing, I narrowed the cause down to my '~/.config/systemd/user' folder. The only contents of that folder are a service and a timer for running a daily backup with tarsnap.

Here is the service:

[Unit]
Description=tarsnap backup
Wants=tarsnap.timer

[Service]
Type=oneshot
ExecStart=/usr/bin/sleep 20 ; /usr/bin/python3 %h/bin/tarsnap_update %h/Documents

[Install]
WantedBy=timers.target

and the timer:

[Unit]
Description=Tarsnap Timer

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

tarsnap_update is a Python script I wrote that calls tarsnap. It runs fine when I invoke it on the command line as presented in the service file. I tried removing the '/usr/bin/sleep 20' command from ExecStart in the service file and now I can log in again. I need to study more to see if my ExecStart line should be valid or not. The strangest part to me is that I was seeing this behavior with systemd 222-1 but not 221-2.

berbae · 2015-08-01 09:02:44

What is the reason of this '/usr/bin/sleep 20' at the start of the ExecStart= line?

And I don't see why you put:

[Install]
WantedBy=timers.target

in the service file, as it is not a timer.

wsha · 2015-08-01 13:12:39

The reason for the sleep was to delay the start of the backup for a little bit to give the system time to establish an internet connection first (because this is a user service it can't require network.target). It's not necessary any more because I put the tarsnap command inside a try/except block in the Python script so that it waits five minutes and then retries if it fails the first time.

I am not sure wabout the timers.target line in the service. I probably put there due to confusion when learning about how to set up a timed service with systemd and then left it because it wasn't throwing an error. Thanks for pointing it out.

Edit: Strangely my faulty service and timer files worked okay under systemd 222 after I removed that sleep command. However, with systemd 224, they broke GDM login once again. Removing the unnecessary timers.target part of the service file as berbae suggested allowed GDM login to work once again under systemd 224. Not sure why different versions of systemd are more or less sensitive to these errors in the configuration files.

Last edited by wsha (2015-08-22 13:50:17)

Arch Linux

#1 2015-07-30 03:38:54

[Solved] Issues logging in with GDM

#2 2015-07-30 08:37:42

Re: [Solved] Issues logging in with GDM

#3 2015-07-30 20:24:42

Re: [Solved] Issues logging in with GDM

#4 2015-08-01 03:54:32

Re: [Solved] Issues logging in with GDM

#5 2015-08-01 09:02:44

Re: [Solved] Issues logging in with GDM

#6 2015-08-01 13:12:39

Re: [Solved] Issues logging in with GDM

Board footer