Re: The "Unix Philosophy 2020" document

From: Serge E. Hallyn <serge_at_hallyn.com>
Date: Sat, 28 Dec 2019 12:29:59 -0600

On Sat, Dec 28, 2019 at 06:41:56PM +0100, Oliver Schad wrote:
> On Sat, 28 Dec 2019 15:37:35 +0200
> Alex Suykov <alex.suykov_at_gmail.com> wrote:
>
> > The reason I think it's mostly useless is because the only use case
> > for cgroup supervision is supervising double-forking daemons, which
> > is not a very smart thing to do. A much better approach is to get rid
> > of double-forking and then just directly supervise the resulting long
> > running process.
> > I can't think of any other cases where it would be useful.
>
> I definitly have to correct you: cgroups are *NOT* designed to catch
> wild forking processes. This is just a side-effect ot them.
>
> The purpose is to control resource limits, like CPU, RAM, Disk I/O and
> so on. So for linux it would definitly make sense to have an interface
> to the full feature set.

Note that with a few simple scripts, users (and daemons) can do this all
themselves. Even without privilege, once set up at boot. Years ago I
would run firefox and kernel builds with restricted memory and cpu,
with a dynamic (unprivileged) daemon freezing them when the cpu got over
a certain temperature. Yeah that laptop wasn't the most reliable...

-serge
Received on Sat Dec 28 2019 - 18:29:59 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC