plymouthd alive when umountroot runs (prevents clean unmount)

Bug #665195 reported by Dan Muresan on 2010-10-22
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)
kde-workspace (Ubuntu)

Bug Description

Binary package hint: plymouth

On my system,

* /etc/X11/default-display-manager is set to /usr/bin/xdm

* gdm is also installed

* the default runlevel is 2

* I boot in text mode (and optionally run startx later); i.e. no display manager is started from /etc/rc*.d

Since fsck runs on every reboot, I spawned a shell from /etc/init.d/umountroot. One of the processes preventing a clean umount of / seems to be

/sbin/plymouthd --mode=boot --attach-to-session --pid-file=/dev/.initramfs/

I guess this is what happens:

* /etc/init/gdm,conf starts and triggers /etc/init/plymouth-stop

* plymouth-stop starts (and remains started), but seeing that gdm is running, it does nothing

* gdm exits when it discovers that I use a different default manager

* I log in from the text console

* "status plymouth-stop" reports this pseudo-service is running; the plymouthd daemon is also alive

* when I shut down, nothing stops plymouthd

* /etc/init.d/umountroot cannot unmount / cleanly

Since the event dependencies between plymouth, gdm, kdb, rc*.d are so complex, I don't know what to suggest.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: plymouth 0.8.2-2ubuntu2
ProcVersionSignature: Ubuntu 2.6.32-25.45-generic
Uname: Linux 2.6.32-25-generic i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Fri Oct 22 19:18:59 2010
DefaultPlymouth: /lib/plymouth/themes/xubuntu-logo/xubuntu-logo.plymouth
MachineType: Dell Inc. Inspiron 1520
ProcCmdLine: root=UUID=a7047dd8-61aa-4cbe-b36d-697a5e7ee64b ro
 PATH=(custom, no user)
ProcFB: 0 VGA16 VGA
SourcePackage: plymouth
TextPlymouth: /lib/plymouth/themes/ubuntu-text/ubuntu-text.plymouth 02/03/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A07 0UW306
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA07:bd02/03/2008:svnDellInc.:pnInspiron1520:pvr:rvnDellInc.:rn0UW306:rvr:cvnDellInc.:ct8:cvr: Inspiron 1520
dmi.sys.vendor: Dell Inc.

Dan Muresan (danmbox) wrote :
Steve Langasek (vorlon) wrote :

Sorry, but I think you've misunderstood the purpose of /etc/init.d/umountroot. This script is not supposed to *unmount* the root filesystem, it's supposed to remount it read-only. A plymouthd process running does not prevent this - and plymouthd is supposed to stay running up until the very end. Have you checked in your modified umountroot script what processes are holding the root filesystem open for *write* at this point? Those will be the processes preventing / from being remounted ro.

Changed in plymouth (Ubuntu):
status: New → Invalid
Dan Muresan (danmbox) wrote :

I know very well the ro-fsck-rw-killall-ro sequence and have performed it manually many times.

lsof shows that plymouth is writing to boot.log:

# lsof -p 352
plymouthd 352 root 12w REG 8,4 4944 280966 /var/log/boot.log

Is this an unusual configuration?

In any case, if plymouth is supposed to remain alive to the end, and NOT write to /, then perhaps /etc/init/plymouth-stop is misleading. To quote:

# This job ensures that only one service stops the plymouth splash screen

This comment seems to imply that plymouth needs to be stopped.

Steve Langasek (vorlon) on 2010-10-22
Changed in plymouth (Ubuntu):
status: Invalid → Incomplete
Steve Langasek (vorlon) wrote :

Ah, sorry for misreading. The thing is that plymouthd is supposed to be run *twice* on the system, once at startup and once at shutdown. I assumed that what you were seeing was a plymouthd process running at shutdown like it's supposed to; the open /var/log/boot.log (and the --mode=boot argument to plymouthd) show that this is actually the process that was started at boot time.

So it sounds like the problem here is actually the combination of

 * /etc/X11/default-display-manager is set to /usr/bin/xdm


 * gdm is also installed

Because the gdm job starts up, /etc/init/plymouth-stop.conf is triggered with JOB=gdm, so it exits without killing plymouthd. But then the gdm job looks at /etc/X11/default-display-manager and decides not to start, dropping the ball - nothing stops plymouthd in this case.

So the bug is in the gdm upstart job; reassigning to gdm.

affects: plymouth (Ubuntu) → gdm (Ubuntu)
Changed in gdm (Ubuntu):
status: Incomplete → Triaged
importance: Undecided → Medium
Steve Langasek (vorlon) wrote :

someone should check whether this also affects kdm - it probably does.

Dan Muresan (danmbox) wrote :

I'm getting the feeling that the mechanism used to keep plymouth up / down appropriately AND avoid a VT change all the while is brittle; there are too many unpredictable interactions between plymouth, plymouth-stop, [gkx]dm and "rc*.d stop".

That's why I filed against plymouth in the first place -- perhaps there could be a simpler design...

Steve Langasek (vorlon) wrote :

It's not unpredictable; it just requires that, once the gdm or kdm job starts, it takes care of stopping plymouth before it exits.

There is no simpler design that satisfies the boot-time requirements.

affects: kdebase-workspace (Ubuntu) → kde-workspace (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers