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

[Timothy Sample <samplet@ngyro.com>]

Hi again,

Timothy Sample <samplet@ngyro.com> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> On my x86_64-linux system running the Guix system, when I include
>> gdm-service in my system services, 'herd stop xorg-server' results in a
>> state where I seemingly cannot recover except by rebooting.  I'm left in
>> what appears to be an empty Linux text console with a cursor in the top
>> left corner, but the keyboard is unresponsive, and I'm not able to
>> switch VTs.  Perhaps there is some SysRq key combination that could be
>> used to recover, but I haven't yet tried.
>
> This has been an issue with GDM since I started working on it.  IIRC,
> it’s not entirely deterministic (but it fails most of the time).  I
> don’t have any leads on this yet.

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).


-- Tim