Hi Mark,
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (24 lines)
> Timothy Sample <samplet@ngyro.com> 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.
Toggle quote (21 lines)
> 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
