I also wonder if someone on this mailing list is interested in actually
implementing a cgroup-based babysitter as is outlined in the post,
perhaps packaged together with standalone workalikes of the cgroup
chainloaders (`create-control-group' etc) from nosh?

Is there real pressure to have this?
The problem with such a "babysitter" is that it would need to forward
signals, much like execline's trap program. It's ugly, and I'd rather
have people not do that any more than strictly necessary.

If there's important pressure to have cgroups support, I will probably
end up applying some version or another of jlyo's patch to s6-supervise,
which makes s6-supervise itself the babysitter. That would allow the
supervised process to operate as usual.

The reason why I didn't want to apply this patch in the first place is
that it's Linux-specific, so it would introduce divergent behaviour in
s6 depending on the system it's running on. But it's probably workable
with some build-time + run-time configuration, I need to think more
about this.

As for cgroups-related chainloaders, I could probably write some in
s6-linux-utils, but wasn't the cgroups interface designed to make
sure those operations are trivial to implement as small scripts?

[And I really like using the word "babysit" here, which comes with a
nice degree of derogatoriness without being excessive.]

 I don't, for several reasons, one of which is that Google's homemade
supervisor (which is... not great) is called "babysitter", and it triggers
cringey memories.


Reply via email to