[Bug 925513] Re: plymouth should not run in container
** Changed in: lxc (Ubuntu) Status: Confirmed = Won't Fix -- 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
[Bug 925513] Re: plymouth should not run in container
@Serge, Could you explain why use of --path can lead to X crashing where lxc-create without --path is not? My motivation was: I don't want lxc-create to create the rootfs under /var/lib/lxc. I need the stuff to be stored elsewhere. I thought that the --path option in the template was made exactly for this purpose. Also notice that --path is specified as parameter for the ubuntu template and not for the lxc-create command: it is specified after -- in the command line. So I think it is really the plymouthd doing something with my framebuffer (which I assume my X server is also using), somehow eventually killing my X session. Does that make sense? I just noticed that I should probably have called lxc-ubuntu with the --trim option. The description of the option is somewhat misleading: Looking at the trim() function in the script itself, it in particular disables a couple of upstart services: quoting from the script: ~~ chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls u*.conf); do mv $f $f.orig; done' chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls tty[2-9].conf); do mv $f $f.orig; done' chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls plymouth*.conf); do mv $f $f.orig; done' chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls hwclock*.conf); do mv $f $f.orig; done' chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls module*.conf); do mv $f $f.orig; done' ~~ This also explains why another container (lucid) that was created with the --trim option works without problems. I will re-test the oneiric container with --trim... Cheers - Michael -- 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
[Bug 925513] Re: plymouth should not run in container
Confirmed: running the same lxc-create command with --trim creates a directly usable container. -- 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
Re: [Bug 925513] Re: plymouth should not run in container
Quoting Michael Adam (ob...@samba.org): @Serge, Could you explain why use of --path can lead to X crashing where lxc-create without --path is not? After creating such a container, look at /var/lib/lxc/container/config and provided-path/config. My motivation was: I don't want lxc-create to create the rootfs under /var/lib/lxc. I need the stuff to be stored elsewhere. The recommended way (which will be in the server guide once written, before release) is to either symlink or bind mount the desired location under /var/lib/lxc. I thought that the --path option in the template was made exactly for this purpose. You're not the only one. This just came up on the lxc-users mailing list, which is why it stood out to me. Also notice that --path is specified as parameter for the ubuntu template and not for the lxc-create command: it is specified after -- in the command line. So I think it is really the plymouthd doing something with my framebuffer (which I assume my X server is also using), somehow eventually killing my X session. Does that make sense? I believe it's involved, but that it wouldn't happen if you didn't use --path. I just noticed that I should probably have called lxc-ubuntu with the --trim option. The description of the option is somewhat misleading: That'll accomplish the same thing in that plymouth won't run :) Looking at the trim() function in the script itself, it in particular disables a couple of upstart services: quoting from the script: ~~ chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls u*.conf); do mv $f $f.orig; done' chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls tty[2-9].conf); do mv $f $f.orig; done' chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls plymouth*.conf); do mv $f $f.orig; done' chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls hwclock*.conf); do mv $f $f.orig; done' chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls module*.conf); do mv $f $f.orig; done' ~~ This also explains why another container (lucid) that was created with the --trim option works without problems. I will re-test the oneiric container with --trim... Still, the moral of the story which we both agree on is: plymouth can be dangerous in containers :) -- 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
[Bug 925513] Re: plymouth should not run in container
@Michael (and @Steve) So plymouth must do stuff over netlink. Instead of using --trim, you can simply add the lines from /etc/lxc/lxc.conf to the config file in your custom path. By not having those lines, you are telling lxc not to create a new network namespace. That means the container is running plymouth in the host's network namespace, and talking to the host's upstart over dbus over unix sockets, for instance. -- 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
[Bug 925513] Re: plymouth should not run in container
Sorry, I said netlink, but a unix socket is more likely. same root cause -- 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
[Bug 925513] Re: plymouth should not run in container
@Serge, thanks for your comments. I have experimented a little more. And I found that --path is indead at the very least misleading: If I don't use --path, then the config (snippet) given to lxc-create by -f is merged with the config that the template creates. If i do use paht, then the -f file is put under /var/lib/lxc while the template creates is stored under the --path. So at least this is bad and confusing. I also came up with the idea of linking or bind-mounting /var/lib/lxc to some other place. It seems safer ... :-) As for plymouth: I still have to experiment whether the behaviour is different when not using --path. But one of the main purposes for me to use is to get network virtualization, so it is not an option to _not_ configure network for my containers. :-) I usually use veth and one of the bridge devices created by libvirt. Cheers - Michael -- 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
[Bug 925513] Re: plymouth should not run in container
@Steve, regarding whether disabling plymouth is the right fix: I don't know the mechanisms plymouth uses. 1. for system log entries, the right fix will be a syslog namespace, which doesn't yet exist. 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. 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. -- 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
[Bug 925513] Re: plymouth should not run in container
@Serge, I might have misready your statement about network config. I do add nettwork config (veth0, dev=virbr0, etc) manually. There is no /etc/lxc/lxc.conf in my system. The reason I used a config file snipped for lxc-create was exactly to get this network virtualization layer into the container config. Cheers - Michael -- 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
Re: [Bug 925513] Re: plymouth should not run in container
Quoting Michael Adam (ob...@samba.org): @Serge, I might have misready your statement about network config. I do add nettwork config (veth0, dev=virbr0, etc) manually. What do you mean by adding it manually? Have you added it to the /data/lxc/ubuntu1/config? If there is no 'lxc.network.link' entry there, then a new network namespace is not created, which is what you need You should jsut be able to cat ./ubuntu1-template.con /data/lxc/ubuntu1/config to get something that works. There is no /etc/lxc/lxc.conf in my system. Ah, right, that was introduced with precise. The reason I used a config file snipped for lxc-create was exactly to get this network virtualization layer into the container config. Right, it's just that you provided that lxc.conf to lxc-create. lxc-create copied that to where it wanted that path to go - which is /var/lib/lxc/ubuntu1/config. lxc-create doesn't look at the template arguments. It's certainly gross that lxc-create passes information to the templates over the same channel that users do. Might be worth talking with upstream about changing that for next cycle. -- 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
Re: [Bug 925513] Re: plymouth should not run in container
On Thu, Feb 16, 2012 at 02:25:36PM -, 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. 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? 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. -- 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
Re: [Bug 925513] Re: plymouth should not run in container
Quoting Steve Langasek (steve.langa...@canonical.com):
On Thu, Feb 16, 2012 at 02:25:36PM -, 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
[Bug 925513] Re: plymouth should not run in container
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.
Yes, it's straight to the log file.
/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.
Well, if /dev/fb0 isn't available, plymouth should automatically fall
back to using the console in text-only mode.
Steve, it sounds to me like we should mark this bug as wontfix.
Ok, done.
** Changed in: plymouth (Ubuntu)
Status: Incomplete = Won't Fix
--
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
[Bug 925513] Re: plymouth should not run in container
Hi, plymouth running in the container prevents me from using the container at all, it kills my X instead: I created a 11.10 container with the following lxc-create command on freshly installed 11.10: sudo lxc-create -n ubuntu1 -f ./ubuntu1-template.conf -t ubuntu -- --release=oneiric --path=/data/lxc/ubuntu1 here ubuntu1-template.conf contains this: ~ lxc.network.type = veth lxc.network.flags = up lxc.network.link = virbr0 ~ (virbr0 being the bridge created by libvirt) Now when I later start the container with sudo lxc-start -n ubuntu1 (after sudo lxc-create -n ubuntu1 -f /data/lxc/ubuntu1/config), then there is no output but after a couple of seconds, my X session is killed placing me in the login manager. When I do lxc-ps -n ubuntu1, I see only plymouthd is running except for init. After disabling plymouth in the container by mv /etc/init/plymouth.conf /etc/init/plymouth.conf.gone, I was able to start the container successfully. So maybe plymouth should really be disabled in the container. Cheers - Michael -- 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
[Bug 925513] Re: plymouth should not run in container
I understand how plymouth currently running in the container might cause problems. My doubt is that disabling plymouth in the container is the right fix. -- 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
[Bug 925513] Re: plymouth should not run in container
@Michael, your problem with X crashing is actually due to your using the '--path' option. Please don't use that. It is only meant to be specified by lxc-create to the template. We've specifically removed --path from the help output because it does the wrong thing when used by hand and is dangerous. -- 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
[Bug 925513] Re: plymouth should not run in container
I'm having trouble sussing out the underlying principle here that warrants special-casing plymouth in a container. Plymouth is the standard boot-time I/O multiplexer; any upstart jobs that need to interact with the user at boot time should be using plymouth. Now for the most part, this currently consists of mountall and cryptsetup, and I can understand how it might be that neither of those are relevant in the context of a container. But what about things like /etc/init/failsafe.conf? Or a hypothetical apache job that prompts for an SSL passphrase through plymouth? So it's not clear to me that disabling plymouth in the container is the right answer, as opposed to fixing any problems plymouth has when running. Writing errors to the console seems to be part and parcel of plymouth's responsibilities. ** Changed in: plymouth (Ubuntu) Status: Confirmed = Incomplete -- 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
