On Thu, Jan 20, 2011 at 11:17 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
Note that grouping processes using cgroups does not imply having to use the group scheduler . IIRC systemd uses a debugging hierarchy by default which does not affect program resources.
This is correct. If you want, systemd can put your program in different kinds of cgroups to restrict resources (have a look in /etc/systemd/system.conf), but because of the possible problem outlined by "FA" above, the cpu cgroup hirearchy is off by default (hopefully the underlying problem will be fixed in the kernel soon, so we can enable some usefull cgroups by default, but in any case this functionality can always be turned off). @Yaro: 1) In my experience Lennart has been a pleasure to work with. 2) Regarding systemd and "The Arch Way", I guess this is a matter of opinion, but the way I see it, systemd fits perfecttly. For two reasons (off the top of my head, there might be more): Firstly, while systemd is more complex (due to more features) than sysvinit, the arch-specific parts of systemd are much simpler than the arch-specific parts of sysvinit (since systemd does most of what rc.sysinit and rc.shutdown do for sysvinit). In fact, by pushing as much as our boot process "upstream" and sharing it with other distributions, we simplify our lives significantly due to the "free" testing and development effort we receive (especially the integration of the init system and related packages like udev and util-linux). Secondly, in a world where devices might come and go and their dependencies might be arbitrarily complex, the sysvinit architecture cannot work in a clean way. SysVinit was created when all setups could be assumed to be static, and this is simply no longer the case (this can best be seen in a setup with lots of raid/lvm/encrypted devices). Cheers, Tom