[arch-general] Systemd inside LXC: user sessions are not automatically removed on logout

[Leonid Isaev]

On Tue, 20 Aug 2013 04:01:11 +0200
Damjan <gdamjan at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20130819/bdba242e/attachment.asc>