previously on this list hero...@gentoo.org contributed: > > And grepping through the output of "ps" or similar is not what > > I would consider reliable and robust either. > > Nod. grepping `ps` is what we should avoid at all cost.
All cost? While I like OpenRC and thanks to Gentoo for it and like your mention of each to there own (I am no old-nerd by the way). I have to disagree. If a service fails I am more interested in why and what will happen if it restarts and not is it back-up already. For that, I would use redundant servers which in any way you look at it and especially for high availability situations must be more reliable than trying to restart a failed service blindly that may not operate as it should when it does. Functional externally generated tests like https returned this file are most valuable for monitoring services and I don't really see your point or the major benefit at all, especially if it involves increased kernel complexity. cgroups doesn't break that, worth it, question for me personally. However whilst I have found the reasoning by the CTTE to have been rather disappointing and superficial and I am unlikely to ever use systemd due to having fundamental issues with it. If a major concern was portability and many of you have your heart set on systemd then although it goes against my desires and technical concerns then perhaps pgroups are worth a mention. ________________________________________________________________________ http://marc.info/?l=openbsd-misc&m=135313692911156&w=2 how can someone write this and not explain why a process managing pgroups can't achieve the same results? pgroups is going to be the first alternative for someone instinctively looking for a portable alternative, so i'm genuinely interested in knowing why they've discarded the idea i am, however, aware of differences *unrelated* to writing a systemd like appliance. pgroups do not provide per item hostname and other virtualization facilities in freebsd jails/linux cgroups, but what about *relevant* differences? something weak like "the index for for cgroups is wide enough to fit an UUID"? in other words, something that *doesn't* require a completely new api? http://marc.info/?l=openbsd-misc&m=135314269712851&w=2 therefore the requirement for cgroups is completely arbitrary also of interest: * early versions of systemd documentation advised daemon authors not to double fork. presumably cgroups wasn't in the radar at the time * several (all?) openbsd daemons have options for not double-forking. some of these daemons have the gall of preceding systemd -- _______________________________________________________________________ '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/163088.43505...@smtp102.mail.ir2.yahoo.com
