On Thu, Jan 20, 2011 at 4:17 PM, Jan Steffens <jan.steffens@xxxxxxxxx> wrote: > On Thu, Jan 20, 2011 at 9:34 PM, <fons@xxxxxxxxxxxxxxx> wrote: >> After years of problems and frustration,for the last two or >> three years we (the people using such audio apps on Linux) >> have finally got a system that allows normal users to do this >> (using ulimits and just two lines in /etc/security/limits.conf >> giving members of the 'audio' group the required privileges). >> >> So here's my question: will a system using systemd still allow >> this, *without* requiring source modifications to each and every >> application (to join a specific cgroup), and *whitout* every >> application requiring real-time or memory locks to be 'registered' >> somewhere ? As far as I've understood it would not. Which would >> make systemd an absolute no-go for users requiring this. > > 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. hmmm, i know that it used to used the `debug` group for lack of a better group. i believe a `noop` subsystem is also available now... i can't find any evidence on the systemd code of it using `debug` anymore. it seems to only use `name=systemd` which causes no other subsystems to be mounted unless they are explicitly included (which they don't seem to be...). i could be wrong but it appears that it's no longer using `debug`, and is using `none` or `noop` somehow instead; which would mean that it's not doing anything other than pure grouping. however glimpses like this: http://0pointer.de/public/systemd-man/systemd.exec.html show you just how powerful service files can be. in the example case of audio apps, it appears trivial to tweak resources to any degree if need be, with infinitely more precision than previous solutions. on a side note, there is also a PAM module that puts user sessions into groups as well, apparently providing the same flexibilities. C Anthony
