On Tue, 20 Aug 2013 04:01:11 +0200 Damjan <gdamjan@xxxxxxxxx> wrote: > On 19.08.2013 18:48, Leonid Isaev wrote: > > Hi, > > > > I have been experimenting with archlinux guests inside LXC containers, and > > noticed that when a user logs out, systemd-logind won't remove the session. > > This is reproducible on all (archlinux x86_64) host-guest, testing-stable > > combinations. > > > > Here is an example (fserv1 is a container hostname). The only way to login > > is through ssh (sshd.service is enabled and running inside the container). > > you know that systemd has the systemd-nspawn utility to start containers? > > For ex. I use this to "boot" my container: > > sudo systemd-nspawn -bD /home/virt/arch-x64 > > /home/virt/arch-x64 is installed with pacstrap I believe (though I don't > find it on my system now) - it has been some time, or maybe with pacman > itself. > > loginctl behaves as expected, having clear separation of sessions. > > so the problem might be with either lxc-start, or the way you installed > the container. > > > ps. > you'd need to add --private-network to systemd-nspawn > if you want network separation, and then you'd have to add and set a > veth device manually - not so hard though: > > sudo modprobe veth > ip link add type veth # this will create veth0 and veth1 by default > ip link set dev veth1 netns <THE PID OF THE NS> # to move veth1 to > the namespace > > "the pid of the ns" is the pid of the first child of systemd-nspawn, > it'll be a /usr/lib/systemd/systemd process. > > > > Yes, I'm aware of systemd-nspawn. Without trying to start a flame war, I see two (mainly convenience) issues with it, which make it convenient as a local super-chroot, but not as an alternative to virtualization, e.g. qemu. 1. With lxc-start the running container already has a virtual eth0 device (and a corresponding randomly-named vethXXXXXX interface on the host). Somehow I don't see a clean way to accomplish this with multiple containers created via systemd-nspawn. There was a proposal to implement such functionality [1], but I don't know whether that has been merged... 2. Secure containers [2] relying on user kernel namespaces (not enabled in -ARCH kernels due to conflict with XFS) which systemd-nspawn doesn't currently support AFAIK, although it'll probably be implemented as soon as userns is enabled by default in mainline kernel... [1] http://lists.freedesktop.org/archives/systemd-devel/2013-March/009249.html [2] http://s3hh.wordpress.com/2013/02/12/user-namespaces-lxc-meeting/ Cheers, Leonid. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Attachment:
signature.asc
Description: PGP signature
