[arch-general] When will Arch switch to Systemd

C Anthony Risinger anthony at extof.me
Thu Jan 20 18:55:20 EST 2011


On Thu, Jan 20, 2011 at 4:17 PM, Jan Steffens <jan.steffens at gmail.com> wrote:
> On Thu, Jan 20, 2011 at 9:34 PM,  <fons at kokkinizita.net> 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


More information about the arch-general mailing list