Quoting Steve Langasek (steve.langa...@canonical.com):
> On Thu, Feb 16, 2012 at 02:25:36PM -0000, Serge Hallyn wrote:
> > regarding whether disabling plymouth is the right fix: I don't know the
> > mechanisms plymouth uses.
>
> Well, I'm happy to answer questions you have on this, but I don't understand
> what issue you're trying to address by disabling plymouth. The bug
> description says only that:
>
> > As stgraber said, "it writes some error messages to /var/log/upstart (when
> > you have logging) and sometimes to the console".
>
> But a) that's not true for values of "it" == "plymouth" (maybe this refers
> to upstart?), and b) it's not clear to me what behavior you expect for the
> various messages if plymouth is disabled - particularly the ones that are
> *actually* being routed to plymouth, which may require some sort of user
> interaction.
>
> > 1. for system log entries, the right fix will be a syslog namespace,
> > which doesn't yet exist.
>
> plymouth has nothing to do with syslog. It captures *console* output to
> /var/log/boot.log, but that's a secondary function and doesn't use syslog
> for output.
Does it write it straight to /var/log/boot.log, or does it do it through
syslog(2) or syslog(3)? If it writes straight to /var/log/boot.log then
there should be no problem.
> > 2. if it uses proc files, we may be able to use apparmor to protect from
> > plymouth, though that may make plymouth fail and cause the container to
> > not boot right. The right fix would be a mix of user namespaces and
> > proc file access filtering.
>
> Plymouth uses /proc/cmdline and /proc/self/fd. Are these a problem in
> lxc?
/proc/self/fd is correct. /proc/cmdline will be the host's kernel
cmdline, which shouldn't exactly be a problem but may be misleading.
> > 3. if it uses devices (ioctls or writes), we may be able to use apparmor
> > and/or the devices namespace to protect from plymouth, but a device
> > namespace will be the right fix.
>
> Oh, it definitely uses devices. At a minimum, it expects to be able to open
> /dev/console. It also generally expects to make use of /dev/fb, /dev/tty0,
> /dev/tty1, and a few others. I had assumed that there is some sort of
> virtualized console in the container that would be exposed with the usual
> device name. If there isn't, then there's definitely no point in running
> plymouth in a container.
/dev/console and /dev/tty{1-4} are bind-mounted pty devices, and are ok
for it to use. /dev/fb is not available in the container - I don't see
/dev/fb0 at all, and the devices cgroup will refuse the container the
rights to read or write it. Otherwise it would be a problem as that is
not virtualized.
Steve, it sounds to me like we should mark this bug as wontfix.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/925513
Title:
plymouth should not run in container
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/925513/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
