Is there any further information I can provide to help debug this (or should it
get a -moreinfo)?
Note that of interest may be that the workaround of spawning in a screen session only works if lxc-start is passed the
-F command which places it in the foreground (though sshd still gets the -D option running inside the container).
Matt
On 6/1/21 11:26, Matt Corallo wrote:
Is your sshd configured to use PAM?
Yes, "UsePAM yes" is in the sshd_config (I don't believe I've changed that, it
appears to be the default?).
So, you log in via ssh, then start a (second) sshd process (inside a lxc
container) via the above command?
That is correct, yes.
Would be great to have a set a commands which allows us reproduce the problem.
The above command paste should basically do it, eg install lxc, then `lxc-create --name fuzzer -t download` to create a
(debian) container, then install sshd inside of it via apt, then run the `systemd-run --user -p "Delegate=yes"
--unit=fuzzer -- lxc-start --name fuzzer -- /usr/sbin/sshd -D` command to spawn it, then log out of the ssh session
which spawned it. There's likely some network configuration which needs to happen in between but I don't know off-hand
how to set it up without public IPs for things.
Once you started the process, can you create a systemd-cgls output and attach
it to this bug report.
Relevant bits post-spawn:
Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│ ├─user@1000.service
│ │ ├─app.slice
│ │ │ └─run-rc291ab200158464d9b477a247d01a095.service
│ │ │ ├─lxc.payload.fuzzer
│ │ │ │ └─12319 /usr/sbin/sshd -D
│ │ │ └─lxc.monitor.fuzzer
│ │ │ └─12313 [lxc monitor] /home/matt/.local/share/lxc fuzzer
│ │ └─init.scope
│ │ ├─1164 /lib/systemd/systemd --user
│ │ └─1165 (sd-pam)
│ ├─session-24.scope
│ │ ├─12207 sshd: matt [priv]
│ │ ├─12213 sshd: matt@pts/0
│ │ ├─12214 -bash
│ │ └─12374 systemd-cgls
│ └─session-1.scope
│ ├─1192 SCREEN
│ └─1193 /bin/bash
On 6/1/21 11:20, Michael Biebl wrote:
Am 01.06.2021 um 17:18 schrieb Michael Biebl:
Am 01.06.2021 um 16:24 schrieb Matt Corallo:
No, the shell is spawned from sshd (and almost nothing else running on the
host).
On 6/1/21 04:22, Michael Biebl wrote:
Control: tags -1 + moreinfo
Am 01.06.2021 um 02:37 schrieb Matt Corallo:
After upgrading to bullseye on a test machine, spawning an lxc container with systemd-run[1] still kills the lxc
container after the spawning shell is closed (and the user logs out). No only does the lxc container eventually
get killed, but systemd refuses any further login for the user while it waits for the lxc container to die
(something like maybe 30 seconds for a simple lxc container running an sshd service), making it appear the system
has hung.
This doesn't appear to be resolved by the options suggested in the man page for systemd-run like `loginctl
enable-linger` or `KillUserProcesses=no` (which appears to still be the default).
Matt
[1] eg systemd-run --user -p "Delegate=yes" --unit=fuzzer -- lxc-start --name
fuzzer -- /usr/sbin/sshd -D
So, you log in via ssh, then start a (second) sshd process (inside a lxc
container) via the above command?
Would be great to have a set a commands which allows us reproduce the problem.
