Re: Bizarre issue with logins and cgroups?

[Lennart Poettering <mzxreary@xxxxxxxxxxx>]

On Sa, 28.03.20 14:02, Ryan (rymg19@xxxxxxxxx) wrote:

> I don't yet have a small test for this yet, so here's all the information
> I've found while I get that ready:
>
> I have a side project <https://nsbox.dev/> that revolves around using
> systemd-nspawn to run pet containers. One feature I'm trying to use it for
> is booted containers, where the following happens:
>
> - During container boot, a service is run that creates an account inside
> the container corresponding to the outside user. This service depends on
> multi-user.target, as well as console-getty (which is overridden to enable
> autologin).
> - The service inside signals the outside world when it's done that the
> container is ready for login.
> - Once the signal is received outside, the host uses nsenter to enter the
> container namespace, then runs
>
>   runuser -s /bin/bash -- - "$THE_USER_NAME" some-command

Use systemd-run for this.

nsenter inserts an outside process into the container, outside of all
supervision, outside of any sensible cgroup and so on. This shouldn't
be done for long-running stuff that is supposed to actually properly
join the container.

> Here's the bizarre part: runuser just hangs forever. I went into debugging
> it further, and found it was hanging waiting for a response from
> systemd-logind while executing the PAM config. With verbose logging for
> logind enabled, I observed the following:

Your client lives outside of the supervision of systemd inside the
container, it's a foreign process, even if it suddenly appears in the
same PID ns... i.e. its PPID is 0, and not 1, because it is
foreign. Just don't do this. systemd-run exists for a reason: it
inserts only a tiny very short-living process into the container that
then talks to systemd inside of the container and tells it to do
something, and then just hands over to that. This means the long
running process is actually running from the context of the user
inside it and all is good.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel