<div dir="ltr">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.</div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 31, 2020 at 10:31 AM Lennart Poettering <<a href="mailto:mzxreary@0pointer.de">mzxreary@0pointer.de</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sa, 28.03.20 14:02, Ryan (<a href="mailto:rymg19@gmail.com" target="_blank">rymg19@gmail.com</a>) 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 <<a href="https://nsbox.dev/" rel="noreferrer" target="_blank">https://nsbox.dev/</a>> 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 </blockquote></div> <div> </div>-- <div dir="ltr" class="gmail_signature">Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else <a href="https://refi64.com/" target="_blank">https://refi64.com/</a></div>