From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timothy Sample Subject: bug#35509: Stopping gdm-service results in an unresponsive system Date: Thu, 02 May 2019 15:45:25 -0400 Message-ID: <87ef5gprmy.fsf@ngyro.com> References: <877ebbmdhc.fsf@netris.org> <87imuupd0h.fsf@ngyro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:45697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMHed-00046L-SC for bug-guix@gnu.org; Thu, 02 May 2019 15:46:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMHec-0003vD-T1 for bug-guix@gnu.org; Thu, 02 May 2019 15:46:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:33513) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMHec-0003v5-Mw for bug-guix@gnu.org; Thu, 02 May 2019 15:46:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hMHec-0006e6-FJ for bug-guix@gnu.org; Thu, 02 May 2019 15:46:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87imuupd0h.fsf@ngyro.com> (Timothy Sample's message of "Wed, 01 May 2019 08:36:46 -0400") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mark H Weaver Cc: 35509@debbugs.gnu.org Hi again, Timothy Sample writes: > Mark H Weaver 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=E2=80=99s not entirely deterministic (but it fails most of the time). = I > don=E2=80=99t 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 =E2=80=9Cc1=E2=80=9D, 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=E2=80=99m guessing it does some magic= with the VT_* set of ioctl requests (see =E2=80=9Csrc/basic/terminal-util.c=E2= =80=9D from elogind). I=E2=80=99m not sure how to get GDM to clean up after itself, th= ough. It might be expecting things of elogind that it doesn=E2=80=99t provide (si= nce it is not exactly like the original logind from systemd). -- Tim