plymouthd alive when umountroot runs (prevents clean unmount)

Bug #665195 reported by danmb
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.

Revision history for this message
danmb (danmbox) wrote :
Revision history for this message
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
Revision history for this message
danmb (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)
Changed in plymouth (Ubuntu):
status: Invalid → Incomplete
Revision history for this message
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
Revision history for this message
Steve Langasek (vorlon) wrote :

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

Revision history for this message
danmb (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...

Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.