bug#35509: Stopping gdm-service results in an unresponsive system

[Timothy Sample]

Hi Mark,

Mark H Weaver <address@hidden> writes:

> Timothy Sample <address@hidden> writes:
>
>> I have a lead now!  At least, I have a way to stop GDM and return to a
>> working TTY.  Assuming that you are working on a TTY with elogind
>> session “c1”, you can run
>>
>>     herd stop xorg-server & (sleep 5; loginctl activate c1)
>>
>> When GDM exits, it leaves the display in a non-working state.  It turns
>> out elogind knows how to fix this.  I’m guessing it does some magic with
>> the VT_* set of ioctl requests (see “src/basic/terminal-util.c” from
>> elogind).  I’m not sure how to get GDM to clean up after itself, though.
>> It might be expecting things of elogind that it doesn’t provide (since
>> it is not exactly like the original logind from systemd).
>
> Thanks for investigating!
>
> My first guess is that when GDM is killed, it's leaving the keyboard
> in RAW mode.  Running "kbd_mode -a" might be another way to recover.
> "Alt + SysRq + r" might be another way.  I'll try again after I finish
> building my post-staging-merge system.
>
>   https://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-9.html

Indeed.  I saw this earlier today.  I looked at the source for elogind,
and all it does is “VT_ACTIVATE” – no magic there.  The loginctl command
can be replaced with “chvt 1”.  The “SysRq + r” trick works too.  In
fact, I saw this in the X.org logs:

--------------------------------
(II) UnloadModule: "libinput"
(II) systemd-logind: releasing fd for 13:67
(EE) systemd-logind: failed to release device: Unknown object 
'/org/freedesktop/login1/session/c4'.
(II) UnloadModule: "libinput"
(II) systemd-logind: releasing fd for 13:68
(EE) systemd-logind: failed to release device: Unknown object 
'/org/freedesktop/login1/session/c4'.
(II) UnloadModule: "libinput"
(II) systemd-logind: releasing fd for 13:65
(EE) systemd-logind: failed to release device: Unknown object 
'/org/freedesktop/login1/session/c4'.
(II) UnloadModule: "libinput"
(II) systemd-logind: releasing fd for 13:64
(EE) systemd-logind: failed to release device: Unknown object 
'/org/freedesktop/login1/session/c4'.
(EE) systemd-logind: ReleaseControl failed: Unknown object 
'/org/freedesktop/login1/session/c4'.
(II) Server terminated successfully (0). Closing log file.
--------------------------------

I wonder if GDM is destroying the session before X can call its
“ReleaseControl” method.  Maybe this keeps X from restoring the terminal
properly.

> I notice that in Debian's start script for gdm3, it runs activate_logind
> just before launching GDM, where activate_logind is the following Bash
> function:
>
>   activate_logind() {
>     # Try to dbus activate logind to avoid a race conditions if we are not
>     # running systemd as PID1 and we have systemd << 204 package installed 
> (see:
>     # #747292)
>     if [ ! -d /run/systemd/system ] && [ -x 
> /lib/systemd/systemd-logind-launch ]; then
>       dbus-send --system --print-reply --dest=org.freedesktop.DBus 
> /org/freedesktop/DBus \
>         org.freedesktop.DBus.StartServiceByName string:org.freedesktop.login1 
> uint32:0 2>&1 > /dev/null
>     fi
>   }
>
> The Debian start script is debian/gdm3.init in
> <http://deb.debian.org/debian/pool/main/g/gdm3/gdm3_3.22.3-3+deb9u2.debian.tar.xz>.
>
> The Debian bug referenced above is <https://bugs.debian.org/747292>.
>
> Might be worth a try, but admittedly I'm grasping at straws here :)

I gave this a try and... it didn’t help.  :(

Looking a little closer at the systemd source, I found out that they
have logic to reset terminal settings when a service becomes “dead” (see
“exec_context_revert_tty” as called from “service_enter_dead” in the
file “src/core/service.c”).  I wonder if GDM relies on that.


-- Tim