[systemd-devel] Automatically moving forked processes in a different cgroup based on children's UID
Wadih
wadih at systemesmw.com
Sat Jan 1 21:41:12 UTC 2022
Hi,
I've been using apache2-mpm-itk with cgrulesengd in cgroupv1 to
automatically classify the child processes that apache2-mpm-itk spawns
when servicing web requests for different vhosts for about 3 years, and
it's been working great, when a vhost starts using up too much CPU/RAM,
oom killer takes care of that specific vhost and leaves the others
alone, as well as the parent process.
I'm now preparing to move to Debian 11 as part of my yearly updates,
and I'm finding out that I need to use cgroup v2 now. So I'm trying to
bring my resource control solution to the new world.
When I create my e.g. /etc/systemd/system/user-
UID.slice.d/override.conf with the resource controls for that user,
they don't apply to the forked processes, as cgrulesengd used to be
able to do, as I am confirming with systemd-cgls. Instead, the parent
and all its children all still belong to the same apache2.service
slice. Which makes sense since it wasn't systemd that spawned the child
processes.
Is there a way to automatically classify child processes of a process
in a different cgroup than the spawning process with systemd based on
the children's new UID? I know apache2-mpm-itk calls setuid() on its
children, so we would have to somehow hook on that.
By default, the processes are now all in :
system.slice/apache2.service
I'd like to have the child processes that apache2-mpm-itk spawns go
under their respective user, e.g.
system.slice/apache2.service/vhosts/%UID%
And then I would set a memory limit of 1G on
system.slice/apache2.service/vhosts
Then when the sum of the memory usage of the vhosts goes above 1G, oom
killer will choose the biggest offending group under
system.slice/apache2.service/vhosts/ and terminate that group, without
touching the others nor the parent process. I've been able to do this
with cgrulesengd and cgconfigparser for 3 years, it's been rock solid.
I'm trying to bring that to the new systemd world.
Would the only solution for me to create a daemon which monitors for
setuid() calls of the parent apache process, and classify the children
as per the new setuid user?
Or perhaps, I think root parent processes spawning specific UID
children is a common security practise, perhaps there should be
something in systemd out of the box for classifying the children under
their respective cgroups?
If my only solution is to create a daemon which monitors for setuid()
I'll do it, although I've never done it before, not sure where I'd have
to start. Any guidance would be great!
Thank you so much,
Wadih Maalouf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220101/9980ad31/attachment.htm>
More information about the systemd-devel
mailing list