Am Mon, 1 May 2017 16:01:13 +0100 schrieb Jorge Almeida <jjalme...@gmail.com>:
> On Mon, May 1, 2017 at 2:46 PM, Rich Freeman <ri...@gentoo.org> wrote: > > On Sun, Apr 30, 2017 at 4:17 PM, Kai Krakow <hurikha...@gmail.com> > > wrote: > >> Am Sun, 30 Apr 2017 10:33:05 -0700 > >> schrieb Jorge Almeida <jjalme...@gmail.com>: > >> > [...] > >> > > > > > Honestly, I can't think of why you wouldn't want to use it. > > > > The use cases of killing orphan processes and managing resources at > > a service level have already been mentioned. > > I don't usually have orphan processes (that process 1 doesn't reap). > My services don't require fine tuning re resources. This doesn't really qualify, because in the end, everything would be reaped by PID 1... I spoke of the cases where an emerge build phase left orphan processes floating around. I don't want them, even when (not if) PID 1 kills the process at last. This also affects the shutdown phase because the filesystem cannot be cleanly unmounted then. You really don't want that. It results in funny effects with some combinations of boot loaders and file systems (e.g. XFS and grub, grub may see zero-size files then, and everything is back to normal after a clean mount). Also, stopping daemons in OpenRC without cgroups often leaves services in limbo state, partially shutdown but still orphans running. This can often result in all sorts of (not so) funny effects (besides the one mentioned above). If someone runs apache servers with PHP shopping softwares, she/he knows what I mean: such PHP software with so-called integrated "background services" seems to happily spawn processes ignoring SIGTERM, probably even double-forking, resulting in unstoppable services: OpenRC stops the master, master exits, orphan process is re-parented to PID 1, you try to start the service: boom, doesn't work. Tho, in systemd you can easily escape the cgroup by doing "su -" or something similar which moves the process into a different session context. This also affects OpenRC because it can't catch such funny maneuvers. "su" is really not a thing to use in init scripts or bash scripts initializing daemons. :-( > > Another use case is that the kernel automatically takes cgroups into > > account when scheduling. So, if one of your services launches a > > bunch of children they'll be weighted together when allocating > > CPU. That means that a service with ten threads won't get 10x the > > CPU of a service with one thread if CPU becomes limiting, assuming > > equal niceness/etc. On a multi-user system the same would apply to > > the user running 100 processes vs 1. Good catch, I forgot to mention that. > > I also use cgroups to monitor memory use/etc at a service level. > > I don't have complex services (some might argue that very complex > services are badly designed services, but I leave that discussion to > pros). I only run single-user workstations. A multi-threaded/multi-process daemon isn't particular a complex daemon... > > Sure, they're somewhat optional, but they're a pretty useful kernel > > feature. > > No arguing there. Still, it shouldn't be pushed. It's a bad sign. Well, I think the wording can be discussed. But I think it's not too bad: The Gentoo newbie/noob will simple follow the warning, enable it, and that results in a suggested configuration with all features possible. It saves developers from figuring out unexpected problems later. If you know better, go for it, with all the consequences that has... ;-) -- Regards, Kai Replies to list-only preferred.
