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 22:15:12 -0400 Message-ID: <87bm0kz3kf.fsf@ngyro.com> References: <877ebbmdhc.fsf@netris.org> <87imuupd0h.fsf@ngyro.com> <87ef5gprmy.fsf@ngyro.com> <877eb8o7fx.fsf@netris.org> 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]:52122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMNk3-0001EA-Sa for bug-guix@gnu.org; Thu, 02 May 2019 22:16:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMNk2-0003ti-Gp for bug-guix@gnu.org; Thu, 02 May 2019 22:16:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:33902) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMNk2-0003tY-9g for bug-guix@gnu.org; Thu, 02 May 2019 22:16:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hMNk2-0007PD-0V for bug-guix@gnu.org; Thu, 02 May 2019 22:16:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <877eb8o7fx.fsf@netris.org> (Mark H. Weaver's message of "Thu, 02 May 2019 17:46:31 -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 Mark, Mark H Weaver writes: > Timothy Sample 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 =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 ma= gic 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,= though. >> It might be expecting things of elogind that it doesn=E2=80=99t 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 =E2=80=9CVT_ACTIVATE=E2=80=9D =E2=80=93 no magic there. = The loginctl command can be replaced with =E2=80=9Cchvt 1=E2=80=9D. The =E2=80=9CSysRq + r=E2= =80=9D 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/freedes= ktop/login1/session/c4'. (II) UnloadModule: "libinput" (II) systemd-logind: releasing fd for 13:68 (EE) systemd-logind: failed to release device: Unknown object '/org/freedes= ktop/login1/session/c4'. (II) UnloadModule: "libinput" (II) systemd-logind: releasing fd for 13:65 (EE) systemd-logind: failed to release device: Unknown object '/org/freedes= ktop/login1/session/c4'. (II) UnloadModule: "libinput" (II) systemd-logind: releasing fd for 13:64 (EE) systemd-logind: failed to release device: Unknown object '/org/freedes= ktop/login1/session/c4'. (EE) systemd-logind: ReleaseControl failed: Unknown object '/org/freedeskto= p/login1/session/c4'. (II) Server terminated successfully (0). Closing log file. -------------------------------- I wonder if GDM is destroying the session before X can call its =E2=80=9CReleaseControl=E2=80=9D 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 installe= d (see: > # #747292) > if [ ! -d /run/systemd/system ] && [ -x /lib/systemd/systemd-logind-l= aunch ]; then > dbus-send --system --print-reply --dest=3Dorg.freedesktop.DBus /org= /freedesktop/DBus \ > org.freedesktop.DBus.StartServiceByName string:org.freedesktop.lo= gin1 uint32:0 2>&1 > /dev/null > fi > } > > The Debian start script is debian/gdm3.init in > . > > The Debian bug referenced above is . > > Might be worth a try, but admittedly I'm grasping at straws here :) I gave this a try and... it didn=E2=80=99t help. :( Looking a little closer at the systemd source, I found out that they have logic to reset terminal settings when a service becomes =E2=80=9Cdead= =E2=80=9D (see =E2=80=9Cexec_context_revert_tty=E2=80=9D as called from =E2=80=9Cservice_e= nter_dead=E2=80=9D in the file =E2=80=9Csrc/core/service.c=E2=80=9D). I wonder if GDM relies on that. -- Tim