[arch-general] Systemd inside LXC: user sessions are not automatically removed on logout
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). fserv1-~ >>> loginctl list-sessions SESSION UID USER SEAT 5 0 root 16 2001 fserv1user 18 2001 fserv1user 19 2001 fserv1user 34 2001 fserv1user fserv1-~ >>> w 16:28:27 up 22:08, 1 user, load average: 0.00, 0.01, 0.05 USER TTY LOGIN@ IDLE JCPU PCPU WHAT fserv1us pts/0 16:06 3.00s 0.11s 0.00s w fserv1-~ >>> id uid=2001(fserv1user) gid=100(users) groups=100(users),190(systemd-journal) fserv1-~ >>> loginctl list-users UID USER 0 root 2001 fserv1user 2 users listed. fserv1-~ >>> ps -u root -U root | grep -i sh 18 ? 00:00:00 sshd 1506 ? 00:00:00 sshd As root: [root@fserv1 ~]# loginctl session-status 16 16 - fserv1user (2001) Since: Mon 2013-08-19 03:59:13 UTC; 12h ago Leader: 748 Remote: hermes.skynet Service: sshd; type tty; class user State: closing CGroup: systemd:/system/lxc_fserv1.service/user/2001.user/16.session [root@fserv1 ~]# loginctl session-status 5 5 - root (0) Since: Sun 2013-08-18 19:48:16 UTC; 20h ago Leader: 141 Remote: hermes.skynet Service: sshd; type tty; class user State: closing CGroup: systemd:/system/lxc_fserv1.service/user/0.user/5.session [root@fserv1 ~]# loginctl kill-session 16 Failed to issue method call: No such process [root@fserv1 ~]# loginctl kill-session 5 Failed to issue method call: No such process However, sshd works correctly, e.g. Aug 18 19:48:16 fserv1 sshd[141]: Accepted password for root from 10.0.0.154 port 39596 ssh2 Aug 18 19:48:16 fserv1 sshd[141]: pam_unix(sshd:session): session opened for user root by (uid=0) Aug 18 19:48:16 fserv1 systemd-logind[22]: New session 5 of user root. Aug 18 19:51:27 fserv1 sshd[141]: Received disconnect from 10.0.0.154: 11: disconnected by user Aug 18 19:51:27 fserv1 sshd[141]: pam_unix(sshd:session): session closed for user root The containers are vanilla (all systemd-related configuration is default) archlinux installs created with lxc-archlinux template from community/lxc. There are no errors/warnings reported by journalctl. The only systemd units masked inside the guests are: systemd-udevd-control.socket, systemd-udevd-kernel.socket, systemd-udevd.service, and proc-sys-fs-binfmt_misc.automount. Is this my mistake somewhere or a systemd issue? Thanks, Leonid. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
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. -- дамјан
On Tue, 20 Aug 2013 04:01:11 +0200 Damjan <gdamjan@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
participants (2)
-
Damjan
-
Leonid Isaev