<div dir="ltr">> 

Wouldn't it be better to have the container inform the host via NOTIFY_SOCKET (the Type=notify mechanism)? I believe systemd has had support for sending readiness notifications from init to a container manager for quite a while.<div><br></div><div>> Use the notify socket and you'll get a notification back when the container is ready, without having to inject anything</div><div><br></div><div>To be clear, I'm not looking for alternative solutions for my specific example, I was raising the general architectural issue.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Sept 2023 at 12:06, Luca Boccassi <<a href="mailto:luca.boccassi@gmail.com">luca.boccassi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 29 Sept 2023 at 12:00, Lewis Gaul <<a href="mailto:lewis.gaul@gmail.com" target="_blank">lewis.gaul@gmail.com</a>> wrote:<br>
><br>
> Hi systemd team,<br>
><br>
> I've encountered an issue when running systemd inside a container using cgroups v2, where if a container exec process is created at the wrong moment during early startup then systemd will fail to move all processes into a child cgroup, and therefore fail to enable controllers due to the "no internal processes" rule introduced in cgroups v2. In other words, a systemd container is started and very soon after a process is created via e.g. 'podman exec systemd-ctr cmd', where the exec process is placed in the container's namespaces (although not a child of the container's PID 1). This is not a totally crazy thing to be doing - this was hit when testing a systemd container, using a container exec "probe" to check when the container is ready.<br>
<br>
Use the notify socket and you'll get a notification back when the<br>
container is ready, without having to inject anything<br>
</blockquote></div>