[systemd-devel] Bizarre issue with logins and cgroups?

[Ryan]

Thank you so much!! I spent ages trying to figure this out, and somehow
that never occurred to me. When I first did nsbox, there was no concept of
booted containers, so I just used nsenter for everything, then when I added
this I had never considered moving to machinectl at that point.

On Tue, Mar 31, 2020 at 10:31 AM Lennart Poettering <mzxreary at 0pointer.de>
wrote:

> On Sa, 28.03.20 14:02, Ryan (rymg19 at gmail.com) 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
>


-- 
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200331/3e89a480/attachment-0001.htm>