plymouthd alive when umountroot runs (prevents clean unmount)

[danmb]

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/plymouth.pid

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 2.6.32.21+drm33.7
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
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 VGA16 VGA
SourcePackage: plymouth
TextPlymouth: /lib/plymouth/themes/ubuntu-text/ubuntu-text.plymouth
dmi.bios.date: 02/03/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A07
dmi.board.name: 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:
dmi.product.name: Inspiron 1520
dmi.sys.vendor: Dell Inc.

[Steve Langasek (vorlon)]

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.

[danmb (danmbox)]

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)]

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

and

 * 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.

[Steve Langasek (vorlon)]

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

[danmb (danmbox)]

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)]

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.