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 <[email protected]> wrote: > On Sa, 28.03.20 14:02, Ryan ([email protected]) 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/
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
