when lightdm is removed but not purged, plymouth is not stopped on boot

[Andy Lutomirski]

I have a more or less standard non-graphical Ubuntu 14.04 server installation. I boot with console=ttyS1,115200, and I have /etc/init/ttyS1.conf that's more or less the same as all the standard /etc/init/ttyN.conf files.

The serial console login doesn't work because plymouth seems to think it's showing its bootsplash and it locks the termios settings using TIOCSLCKTRMIOS. This completely breaks /bin/login, which *requires* working buffered mode.

I have no idea what mechanism is supposed to tell Plymouth to dismiss its splash screen when boot up is done, but it's clearly broken. What gives?

[Steve Langasek (vorlon)]

> I have /etc/init/ttyS1.conf that's more or less the same as all the standard /etc/init/ttyN.conf files.
What does "more or less the same" mean? What is the exact content of this file?

The /etc/init/ttyN.conf files are *not* all the same, precisely because plymouth and tty1 conflict with each other in the graphical VT case.

The answer to the question, "what is supposed to tell pymouth to dismiss its splash screen", is /etc/init/plymouth-stop.conf. Your /etc/init/ttyS1.conf probably has a race with this upstart job.

[Andy Lutomirski (luto-mit)]

The official docs [1] say to do:

--- cut here ---
# ttyS0 - getty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.

start on stopped rc or RUNLEVEL=[12345]
stop on runlevel [!12345]

respawn
exec /sbin/getty -L 115200 ttyS0 vt102
--- cut here ---

I have:

--- cut here ---
# ttyS1 - getty
#
# This service maintains a getty on ttyS1 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345] and (
            not-container or
            container CONTAINER=lxc or
            container CONTAINER=lxc-libvirt)

stop on runlevel [!2345]

respawn
exec /sbin/getty -8 115200 ttyS1
--- cut here ---

But this isn't a race -- IMO it really is a bug, if only a documentation bug perhaps. plymouth-stop.conf has:

start on (starting gdm
          or starting kdm
          or starting xdm
          or starting lxdm
          or starting lightdm
          or starting uxlaunch
          or starting ubiquity
          or starting oem-config
          or stopped rc RUNLEVEL=[2345]
          or starting rcS
          or starting mountall-shell)

It never runs at all on a non-graphical system. Heck, I don't even see why console=tty1 or perhaps no console arg at all works correctly if there's no graphical greeter in that list. This isn't a race -- it's just completely broken in these configurations.

IMO plymouth should stop whenever a getty starts on the tty that plymouth is in charge of.

Please reopen.

[Steve Langasek (vorlon)]

On Fri, Apr 10, 2015 at 01:40:13AM -0000, Andy Lutomirski wrote:
> The official docs [1] say to do:

Dangling reference here; I don't know which doc you got this from.

> --- cut here ---
> # ttyS0 - getty
> #
> # This service maintains a getty on ttyS0 from the point the system is
> # started until it is shut down again.
>
> start on stopped rc or RUNLEVEL=[12345]

That is certainly incorrect. There should be no 'or' here.

> --- cut here ---
> # ttyS1 - getty
> #
> # This service maintains a getty on ttyS1 from the point the system is
> # started until it is shut down again.

> start on stopped rc RUNLEVEL=[2345] and (
> not-container or
> container CONTAINER=lxc or
> container CONTAINER=lxc-libvirt)

Your version does look correct.

> But this isn't a race -- IMO it really is a bug, if only a documentation
> bug perhaps. plymouth-stop.conf has:

> start on (starting gdm
> or starting kdm
> or starting xdm
> or starting lxdm
> or starting lightdm
> or starting uxlaunch
> or starting ubiquity
> or starting oem-config
> or stopped rc RUNLEVEL=[2345]
> or starting rcS
> or starting mountall-shell)

> It never runs at all on a non-graphical system.

Why do you say that it doesn't? The 'stopped rc RUNLEVEL=2' event, when
emitted, should trigger this job to be called. This is the same event that
triggers the start of your tty job, so it certainly is being emitted.

You definitely don't have any of the gdm, lightdm, ubiquity, or oem-config
services installed, correct?

Do you have a /var/log/upstart/plymouth-stop.log on the affected system? If
so, please attach it.

Please also show the output of 'sudo initctl list | grep plymouth' on this
system.

> Please reopen.

The bug is not closed.

[Andy Lutomirski (luto-mit)]

>> The official docs [1] say to do:
>
> Dangling reference here; I don't know which doc you got this from.

Whoops.

https://help.ubuntu.com/community/SerialConsoleHowto

> Why do you say that it doesn't? The 'stopped rc RUNLEVEL=2' event, when
> emitted, should trigger this job to be called. This is the same event that
> triggers the start of your tty job, so it certainly is being emitted.

Sorry, I read that wrong. You're right.

I do have lightdm installed, which is odd, since I don't have any of the xorg packages installed. I wonder if that's somehow related. I don't have a /var/log/upstart/plymouth-stop.log.

[Andy Lutomirski (luto-mit)]

Correction: I didn't have lightdm, but I still had lightdm.conf. I did aptitude purge lightdm, and now everything's okay.

This seems really fragile to me.

[Steve Langasek (vorlon)]

> Correction: I didn't have lightdm, but I still had lightdm.conf. I did
> aptitude purge lightdm, and now everything's okay.

Aha, that explains. Plymouth assumes that if lightdm is installed, it will handle the stopping of plymouth as part of the flicker-free transition to X. If lightdm is removed but not purged, the upstart job triggers, causing plymouth-stop to skip stopping plymouth itself; and since the lightdm job won't actually start lightdm, nothing stops plymouth.

So it seems the lightdm upstart job should be adjusted to also detect the case where the package is purged, and call 'plymouth quit'.