On Thu, 24.01.13 00:29, Lars Kellogg-Stedman ([email protected]) wrote: Heya,
Currently, our idea of containers is that no devices beyond /dev/null, /dev/zero, /dev/random and friends are available to them, and if you have any others you want to expose they need to be managed by the container manager instead of the container itself. Or in other words, if you expose a network device to the container it should probably be pre-configured before it is passed in, and not be handled otherwise in the container. By default systemd in the container is conditionalized on CAP_SYS_MKNOD, where the idea is that the container manager drops that, which means udev is not started at all in containers. > I am running Linux under LXC. I have a systemd unit file for dhcpcd (a > DHCP client) that includes: > > BindsTo=sys-subsystem-net-devices-eth0.device Well, systemd waits for udev to announce the device with a "systemd" tag on it. If you really want to start udev in the container, this would mean that the two udev mcast netlink groups need to work properly in the container, and that "udev trigger" in the container would actually be able to trigger the device, but only in the container, without having that leak to the host. Currently, only a small part of /sys is virtualized right now, we thus recommend that /sys is mounted read-only in the container, so that the container cannot alter the host's attributes on arbitrary devices. Triggering a device via "udev trigger" however means you need to allow write access. Much of what systemd expects from the container manager is documented here btw: http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface I don't really have a good answer to the question what to do with unit files that use device dependencies in containers... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
