When upgrading an OpenVZ container using Yum from Fedora 14 to 15 the container won't start. Only one process running and that is init. In general it would be nice if Fedora were at least OpenVZ aware and didn't break OpenVZ. It seems like every release of Fedora there's some incompatibility that needs to be fixed. I wish I had more information about what is happening. Is there a way to test/troubleshoot this bug to see where init is failing?
A little more information. From within the container if I execute initctl list I get: initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused There also seems to be some discussion relating to problems running under chroot, which is how OpenVZ works. Fedora 14 containers work. This just started in Fedora 15.
Fedora 15's default init is systemd. Run: # ls -l /proc/1/exe do you see /proc/1/exe -> /bin/systemd or /proc/1/exe -> /sbin/upstart ?
ls -l /proc/1/exe lrwxrwxrwx 1 root root 0 May 30 03:02 /proc/1/exe -> /bin/systemd
What's the kernel version? There is a known problem related to capabilities when running on kernel < 2.6.38. If it's that, try commenting out all "CapabilityBoundingSet=" lines in /etc/systemd/system/*
I commented out CapabilityBoundingSet lines. No difference. Things that tend to break OpenVZ are sometime udev related. or getty related. OpenVZ also runs in a fake root. Fedora 14 works so the problem happened in the last release. Let me know if you want me to test anything else.
Also - the latest OpenVZ kernel is 2.6.32.
That's quite old. Maybe systemd depends on something else from newer versions. I don't know much about OpenVZ. Can you get any logs out of it if you boot with systemd.log_level=debug ?
Hi Micheal, What file do I set systemd.log_level=debug ?
I can't pass kernel parameters to the container because individual containers don't have their own kernel. Tried to run systelctl and I get: Failed to get D-Bus connection: Failed to connect to socket /org/freedesktop/systemd1/private: Connection refused
(In reply to comment #9) > I can't pass kernel parameters to the container because individual containers > don't have their own kernel. Though the parameter is usually passed via the kernel command line, it's not in fact a parameter for the kernel, but for systemd. Surely OpenVZ must have some way to pass arguments to the container's init process.
Surely systemd has some way to debug without counting on a command line parameter. I'm not an OpenVZ developer. I don't know if you can pass a kernel parameter without a kernel.
Edit LogLevel and LogTarget in /etc/systemd/system.conf. Or make a trivial wrapper around /bin/systemd with the parameters you need and name it /sbin/init.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Closing this as CANTFIX because: - OpenVZ is not in Fedora - systemd developers do not know much about OpenVZ (except for the fact that the kernel is old) - the bug has been in NEEDINFO for months If someone else is willing to debug/fix it, feel free.
Pavel Šnajdr uses OpenVZ in his project and he convinced me to take a look at it. I used a RHEL6 host and a precreated F15 guest template. What I found: - systemd stops booting because its attempt to mount devtmpfs on /dev fails in OpenVZ. To workaround that, you can edit src/mount-setup.c:mount_table[] and change "devtmpfs" to non-fatal. This is sufficient for the container to boot far enough to let you enter it. - systemctl showed 25 failed services. Most of them fail because /dev/console does not work in OpenVZ. You can workaround that partially at least for SysV services by using "SysVConsole=no" in /etc/systemd/system.conf. You could workaround that for native services by avoiding the use of "Standard{Input,Output,Error}=tty" in the unit files. OpenVZ should provide a working /dev/console for the guests, perhaps by using a pseudoterminal. - Services that use "CapabilityBoundingSet=" or "IOSchedulingClass=" fail with EXIT_CAPABILITIES and EXIT_IOPRIO because of the old kernel.
At work, and on remote servers, we do use OpenVZ a lot (in combination with ProxMox), with whatever Fedora templates we have. For now, there are templates for Fedora <= 15 (http://wiki.openvz.org/Download/template/precreated), i.e., not for Fedora 16 (and of course not for Rawhide). When there is no template, we have to use KVM/QEMU, which is both less efficient and consumes more resources from the host, even when idle. I guess that most people go on without Fedora 16 template by using KVM, which may explain why there does not seem to have so much demand for that template. A thread has been started on the OpenVZ forum: http://forum.openvz.org/index.php?t=tree&th=10124 If anyone wants to contribute to an OpenVZ Fedora 16 template, I would be very happy to test it!