Bug#989317: systemd kill background processes after user logs out (#825394 regression)

Matt Corallo dbsdsfdog at mattcorallo.com
Mon Jun 7 20:20:20 BST 2021


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 at 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 at 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.
>>



More information about the Pkg-systemd-maintainers mailing list