[arch-general] lxc: systemd-udev-trigger resets host kbd & mouse settings
I've just started playing with lxc, and found that if I create a container with: # lxc-create -n arch -t archlinux and then start it: # lxc-start -n arch it resets my X keyboard map and mouse acceleration settings (which are set by setxkbmap/xset/xinput), though mouse button remapping done by xmodmap is not affected. I tracked it as far as the execution of: /usr/bin/udevadm trigger --type=devices --action=add in /usr/lib/systemd/system/systemd-udev-trigger.service, which seems to write "add" to most of the "uevent" files under /sys/devices. I don't know the reason for this, especially in a container, but disabling the whole udev trigger service in the container keeps the host X input settings intact without breaking anything obvious in the container (and the container boots a lot faster now, too). I'd appreciate any thoughts on what systemd-udev-trigger is doing, whether it's appropriate in a container, and if there's a better way to keep a container from changing X input settings on the host. Carl
On 18/04/14 05:40 PM, Carl Schaefer wrote:
I've just started playing with lxc, and found that if I create a container with:
# lxc-create -n arch -t archlinux
and then start it:
# lxc-start -n arch
it resets my X keyboard map and mouse acceleration settings (which are set by setxkbmap/xset/xinput), though mouse button remapping done by xmodmap is not affected.
I tracked it as far as the execution of:
/usr/bin/udevadm trigger --type=devices --action=add
in /usr/lib/systemd/system/systemd-udev-trigger.service, which seems to write "add" to most of the "uevent" files under /sys/devices. I don't know the reason for this, especially in a container, but disabling the whole udev trigger service in the container keeps the host X input settings intact without breaking anything obvious in the container (and the container boots a lot faster now, too).
I'd appreciate any thoughts on what systemd-udev-trigger is doing, whether it's appropriate in a container, and if there's a better way to keep a container from changing X input settings on the host. Carl
Do you have these issues with systemd-nspawn? mkdir container && pacstrap -cd base container systemd-nspawn -bD container Containers are not yet completely solid. One of the most notable flaws is the complete lack of namespacing for the cgroup filesystem. These kind of things are worked around by systemd via various hacks, so perhaps lxc is missing something.
On Fri, 2014-04-18 at 17:45 -0400, Daniel Micay wrote:
On 18/04/14 05:40 PM, Carl Schaefer wrote:
I've just started playing with lxc, and found that if I create a container with:
# lxc-create -n arch -t archlinux
and then start it:
# lxc-start -n arch
it resets my X keyboard map and mouse acceleration settings (which are set by setxkbmap/xset/xinput), though mouse button remapping done by xmodmap is not affected.
I tracked it as far as the execution of:
/usr/bin/udevadm trigger --type=devices --action=add
in /usr/lib/systemd/system/systemd-udev-trigger.service, which seems to write "add" to most of the "uevent" files under /sys/devices. I don't know the reason for this, especially in a container, but disabling the whole udev trigger service in the container keeps the host X input settings intact without breaking anything obvious in the container (and the container boots a lot faster now, too).
I'd appreciate any thoughts on what systemd-udev-trigger is doing, whether it's appropriate in a container, and if there's a better way to keep a container from changing X input settings on the host. Carl
Do you have these issues with systemd-nspawn?
no, systemd-nspawn does not reset host X input settings; the nspawn container makes /sys read-only, so "udevadm trigger" in the container can't succeed, and in fact the unit file's condition keeps it from even trying: nspawn# systemctl status systemd-udev-trigger * systemd-udev-trigger.service - udev Coldplug all Devices Loaded: loaded (/usr/lib/systemd/system/systemd-udev-trigger.service; static) Active: inactive (dead) start condition failed at Fri 2014-04-18 20:21:24 EDT; 28s ago ConditionPathIsReadWrite=/sys was not met
Containers are not yet completely solid. One of the most notable flaws is the complete lack of namespacing for the cgroup filesystem. These kind of things are worked around by systemd via various hacks, so perhaps lxc is missing something.
I agree it seems something is missing, but I'm less clear about what & from where... :-) Carl
On 18/04/14 11:17 PM, Carl Schaefer wrote:
On Fri, 2014-04-18 at 17:45 -0400, Daniel Micay wrote:
On 18/04/14 05:40 PM, Carl Schaefer wrote:
I've just started playing with lxc, and found that if I create a container with:
# lxc-create -n arch -t archlinux
and then start it:
# lxc-start -n arch
it resets my X keyboard map and mouse acceleration settings (which are set by setxkbmap/xset/xinput), though mouse button remapping done by xmodmap is not affected.
I tracked it as far as the execution of:
/usr/bin/udevadm trigger --type=devices --action=add
in /usr/lib/systemd/system/systemd-udev-trigger.service, which seems to write "add" to most of the "uevent" files under /sys/devices. I don't know the reason for this, especially in a container, but disabling the whole udev trigger service in the container keeps the host X input settings intact without breaking anything obvious in the container (and the container boots a lot faster now, too).
I'd appreciate any thoughts on what systemd-udev-trigger is doing, whether it's appropriate in a container, and if there's a better way to keep a container from changing X input settings on the host. Carl
Do you have these issues with systemd-nspawn?
no, systemd-nspawn does not reset host X input settings; the nspawn container makes /sys read-only, so "udevadm trigger" in the container can't succeed, and in fact the unit file's condition keeps it from even trying:
nspawn# systemctl status systemd-udev-trigger * systemd-udev-trigger.service - udev Coldplug all Devices Loaded: loaded (/usr/lib/systemd/system/systemd-udev-trigger.service; static) Active: inactive (dead) start condition failed at Fri 2014-04-18 20:21:24 EDT; 28s ago ConditionPathIsReadWrite=/sys was not met
Containers are not yet completely solid. One of the most notable flaws is the complete lack of namespacing for the cgroup filesystem. These kind of things are worked around by systemd via various hacks, so perhaps lxc is missing something.
I agree it seems something is missing, but I'm less clear about what & from where... :-) Carl
AFAIK the /sys filesystem and most (all?) of the submounts are not yet namespaced. Any cgroup created on the host will be visible in the container, etc.
participants (2)
-
Carl Schaefer
-
Daniel Micay