3

I observed that the command su takes too long (30 seconds) when it is executed in a LXD Debian container that is nested into an Ubuntu LXD container. This overhead does not occur Debian containers that are not nested, nor in Ubuntu containers nested into an Ubuntu container. Does anyone have any explanation for this? Next I describe how to reproduce this issue.

Setup

I have set up LXD containers in an Ubuntu 18.04 machine to use nested containers (as is described in https://ubuntu.com/blog/nested-containers-in-lxd). I use the system apt packages (lxd and lxd-client) to install LXD. Then, I created two containers as follows:

lxc launch ubuntu:20.04 c1 -c security.nesting=true
lxc launch images:debian/10 c2

Then, inside container c1, I created two nested containers:

lxd init
lxc launch ubuntu:20.04 c3
lxc launch images:debian/10 c4

In the Debian containers, I created non-root user debian with the following command:

adduser --home /home/debian --gecos Debian --disabled-password debian

In Ubuntu containers is not needed to create a non-root user because the ubuntu user is already defined.

Measuring how long su takes

For each container I measure the time required for the command su with the following commands (where user is either ubuntu or debian):

time pwd
time su $user -c pwd

It is expected that the second command takes more time due to the overhead of the su command. In all cases this overhead is around 59 milliseconds, except for container c4 (i.e., for the Debian container inside the Ubuntu container) where the overhead is around 30 seconds.

Community
  • 1
Daniel Hernández
  • 253
  • 1
  • 2
  • 4
  • Don't know if related, but for me this is even the case on a non-nested Debian container (running on a Debian host), although "only" 35 seconds. – doak Sep 16 '21 at 21:41
  • Did you try `strace su "$user" -c pwd`. In my case it seems to timeout polling some socket (probably DBus). If I read the log correctly it is `/run/dbus/system_bus_socket`. Would be interesting if my case is related to yours. It could be related to PAM for instance. – doak Sep 16 '21 at 22:00
  • 1
    Indeed: After disabling `session optional pam_systemd.so` in `/etc/pam.d/common-session` (included by `/etc/pam/su.conf`) it works fast as light :) Let's see if you can hunt it down. (Btw. I got a bunch of related logs hinting to isues with `systemd-logind` in the journal as well.) – doak Sep 16 '21 at 22:11
  • 1
    Thanks @doak, just commenting that line in the configuration makes it fast! – Daniel Hernández Sep 26 '21 at 14:48

0 Answers0