previously on this list Kevin Chadwick contributed: > Perhaps before this thread spirals out of control I should
should also mention this has been discussed on this very list already, though before I was enrolled and the following response went unreplied to. On the other hand and I doubt of significance to me but it may well be worth looking into how Google uses cgroups though apparently systemd causes or would cause problems for them in potential kernel changes being incompatible with their usage. May have been resolved and brought up before though I forget if replied to, but might provide some pro argument for the cgroups case for the few that it matters to rather than the many that enforcing it's usage matters to. https://lists.debian.org/debian-devel/2011/07/msg00423.html _______________________________________________________________________ >> It seems this problem (double fork) is the basement of using cgroup >> under systemd ;) > > I think messing around with cgroups is a ridiculous way to solve this > problem. To be fair, systemd also uses cgroups to reliably kill rogue child processes when stopping a service. This is not unlike what BSD-derived shells use pgroups for, I believe. > The right answer is simply to change the daemons to give > them an option which causes them not to fork. Then you can just have > a single supervision daemon which reaps (and restarts, if desired). > I haven't done a survey of the available init replacements but this is > not a new concept Well, it's already present in SV init : 1:2345:respawn:/sbin/getty 38400 tty1 > and I hope that most of them implement it as a possibility. Daemontools, runit, minit, upstart, systemd all do. I don't know about initng. -- Juliusz -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd _______________________________________________________________________ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/489578.4170...@smtp104.mail.ir2.yahoo.com
