On Sat, Nov 17, 2012 at 3:20 AM, Eric Furman <[email protected]> wrote: > You missed the point. > This is a joke. > Rod was making a joke by pointing out how F****** retarded these people > are.
i'm going to pretend that you pointed out that cgroups prevent double-forking from being a factor whereas pgroups do not this is a question of policy, not api: 1. if a program double-forks, that program has made it clear that it does not need the destructors scripted in "systemd implementation", and is eligible for being terminated by the generic, all-encompasing, sysv killall(), linux killall5, or bsd kill(-1) at the end of shutdown. this conclusion is drawn by the fact that the program can negate scripted destructors ANYWAY under cgroups by way of being unrestricted in its set of system calls (which is a concern OUTSIDE "systemd implementation", therefore the role of a more generic utility), or by plain bat shit insane userland code. there's no sandbox being added by cgroups here 2. if a program double-forks, security is not compromised because the permissions of that program are completely orthogonal to control via "systemd implementation". the admin's *policy* is that there's always an interest in running certain daemons as certain users. that "systemd implementation" can also map processes to users is coincidental 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 > > On Sat, Nov 17, 2012, at 02:21 AM, Andres Perera wrote: >> On Sat, Nov 17, 2012 at 1:55 AM, Rod Whitworth <[email protected]> >> wrote: >> > On Fri, 16 Nov 2012 20:49:37 -0600, Amit Kulkarni wrote: >> > >> >>https://lwn.net/Articles/524606/ >> >> >> >>don't have a subscription but for those who do, enjoy. >> >> >> > >> > But http://lwn.net/Articles/524920/ will give you the idea without $$$ >> >> "rleigh, it's really not as easy as you think. Making the event loop >> portable to kqueue is complex, but doable, I can agree to that. -- But >> the trouble starts beyond that. The BSDs don't have anything like >> cgroups. *There's no way to attach a name to a group of processes, in >> a hierarchal, secure way*. And you cannot emulate this. (And no, don't >> say "BSD jail" now, because that is something very different). But >> this already is at the very core of systemd. It's how systemd tracks >> services." >> >> 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?
