After chewing on it for some time, I think that per the current init-policy draft [1] the "initfile invoked directly" can be striked out of the affected case since it's not supported anyway.
Thus the issue scope can be narrowed down to service, invoke-rc.d and ifupdown hooks. The former two can be patched to ensure that when invoking an initfile under !systemd the process is moved outside of any control group before invoking the script. I'm drafting a patch to do that, but so far I hit some roadblocks along the way (namely, cgmanager operates asynchronously, so the target of a MovePidAbs could still be moving across cgroup boundaries while forking; also I honestly don't know yet what happens when invoke-rc.d is used during an update run which includes an update for cgmanager itself and how to handle such an edge case). I still haven't looked into ifupdown hooks, but the only problematic ones are those who fork background processes directly (dhcp clients, pppd). Most of them use (rightfully so) invoke-rc.d, so they should not be a pain point. I don't know if I should Cc: sysv-rc and sysvinit-utils maintainers to get feedback from them before going ahead with a patch. Also, invoke-rc.d seems to be shipped by other packages as well (file-rc and openrc), but I'm not entirely sure if they're supported and/or if they require patching at all (IIRC openrc handled cgroup transitions gracefully on its own). [1]: https://lists.debian.org/debian-policy/2014/11/msg00069.html Regards, -- Matteo Panella
signature.asc
Description: OpenPGP digital signature
