After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 746023 - if gdm fails for any reason, plymouth-quit.service does not run and gettys do not appear
if gdm fails for any reason, plymouth-quit.service does not run and gettys do...
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2015-03-11 11:48 UTC by Simon McVittie
Modified: 2015-03-12 11:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
systemd: call plymouth-quit if gdm fails (1.65 KB, patch)
2015-03-11 11:50 UTC, Simon McVittie
none Details | Review
systemd: call plymouth-quit if gdm fails (1.89 KB, patch)
2015-03-11 12:05 UTC, Simon McVittie
committed Details | Review

Description Simon McVittie 2015-03-11 11:48:49 UTC
Steps to reproduce:

* make sure you have ssh access (or use an expendable VM) before proceeding!
* start with a systemd-booted system
* install plymouth and enable it (e.g. in Debian,
  edit /etc/default/grub and add splash to the kernel command-line)
* install gdm (Debian: gdm3) and configure it as the default DM if necessary
* do something that completely breaks gdm (e.g. in my expendable Debian VM,
  I deleted /usr/lib/*/libXdmcp.so.6)

Expected (or at least preferred) result:

* plymouth-quit.service runs
* getty appears on tty1

Actual result:

* gdm.service Conflicts with plymouth-quit.service, so it does not run
  "naturally" (because GDM wants to handle the handover from plymouth
  to X11 itself)
* gdm failed to start (in this case because I deleted one of its libraries)
  so plymouth is never stopped
* plymouth-quit-wait.service never finishes
* ... so getty@tty*.service, which is After it, never starts
* there is no way to log in locally and fix the problem

If this could happen under normal circumstances, it would be a very serious bug. In reality it isn't a problem unless gdm is broken in some way (e.g. in the steps to reproduce, I simulated a GDM bug by deleting one of its libraries) but it still seems like something that should be avoided.

Debian's gdm currently has a workaround for the packaging of some of our other DM implementations (kdm, wdm) not having been properly migrated to systemd yet, which makes this more likely to happen in practice; this is not relevant for upstream, but the same change fixes that too.
Comment 1 Simon McVittie 2015-03-11 11:50:35 UTC
Created attachment 299091 [details] [review]
systemd: call plymouth-quit if gdm fails

gdm.service Conflicts with plymouth-quit.service, so it does not run
when it normally would (because GDM wants to handle the handover from
plymouth to X11 itself). This means that if gdm fails to start for whatever
reason, plymouth is never stopped, so plymouth-quit-wait.service
never finishes. This, in turn, means that getty@tty*.service, which is
After plymouth-wait-quit.service, never starts, and there is no way to
log in locally and fix the problem (Debian bug #780257, but not
Debian-specific).

In Debian 8, not all display managers have been migrated to
participate in managing the display-manager.service symlink yet
(in particular, kdm and wdm have not), so gdm has a transitional
ExecStartPre that stops it from running if kdm or wdm is selected
as the active DM. This has the same effect of preventing plymouth
from running (Debian-specific bug #766462).

It's easy to avoid both of those situations by scheduling
plymouth-quit.service to run if gdm fails.

Bug-Debian: https://bugs.debian.org/766462
Bug-Debian: https://bugs.debian.org/780257
Comment 2 Simon McVittie 2015-03-11 12:05:49 UTC
Created attachment 299093 [details] [review]
systemd: call plymouth-quit if gdm fails

---

a version of the above patch that applies cleanly to gdm master (sorry, I'm having some trouble with unfuzzing diffs relative to Debian's patched gdm)
Comment 3 Ray Strode [halfline] 2015-03-11 15:01:51 UTC
Review of attachment 299093 [details] [review]:

sounds reasonable to me.  I think at some point i toyed with having it isolate to multi-user.target on failure, but that ended up getting in the way. This seems like a less invasive change with good upsides.
Comment 4 Simon McVittie 2015-03-12 11:16:53 UTC
Review of attachment 299093 [details] [review]:

master: 234fbc8 for 3.15.91.3 (or whatever the next release after 3.15.91.2 is called)

3.14: c565346 for 3.14.2