[systemd-devel] [lennart at kemper.freedesktop.org: [systemd-commits] src/pam-module.c]

Andrey Borzenkov arvidjaar at mail.ru
Tue Feb 8 03:52:21 PST 2011


On Tue, Feb 8, 2011 at 2:42 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 08.02.11 14:22, Andrey Borzenkov (arvidjaar at mail.ru) wrote:
>
>>
>> On Tue, Feb 8, 2011 at 1:36 PM, Lennart Poettering
>> <lennart at poettering.net> wrote:
>> > On Tue, 08.02.11 13:30, Andrey Borzenkov (arvidjaar at mail.ru) wrote:
>> >
>> >>
>> >> On Tue, Feb 8, 2011 at 1:15 PM, Lennart Poettering
>> >> <lennart at poettering.net> wrote:
>> >> > On Tue, 08.02.11 12:29, Andrey Borzenkov (arvidjaar at mail.ru) wrote:
>> >> >
>> >> >> > The rtkit patch ensures rtkit itself can get RT privs. This systemd
>> >> >> > patch ensures apps (such as PA) started within a systemd session can get
>> >> >> > RT privs. Without neither patch neither side can get RT privs. To work
>> >> >> > properly both sides need to be able to get RT privs.
>> >> >> >
>> >> >>
>> >> >> Do  I need this patch to *strart* rtkit?
>> >> >
>> >> > Hmm, yes? The cgroup fix needs to be applied when you start rtkit.
>> >> >
>> >>
>> >> But there is no login session at this point; is PAM involved at all?
>> >> At least "pam" does not appear anywhere in rtkit sources ... and we
>> >> must be able to use systemd with pam_systemd as well, must not we?
>> >
>> > Hmm?
>> >
>> > The patch to rtkit needs to be applied before rtkit is started. After
>> > applying, building and installing rtkit you need to reload the systemd
>> > configuration.
>> >
>> > The patch to systemd needs to be applied before you login. After
>> > applying, building and installing systemd it should be sufficient to
>> > relogin, since that will already load the updated PAM module.
>> >
>>
>> We apparently misunderstand each other.
>>
>> I speak about failure of rtkit-daemon to put itself in RT scheduling
>> group on startup. At this point there is no login at all.
>>
>> Anyway, I rebuild systemd with your PAM patch and restarted system and
>> as expected nothing changed:
>>
>> Feb  8 14:14:51 cooker rtkit-daemon[3165]: Failed to make ourselves
>> RT: Operation not permitted
>
> Hmpf. so you are suggesting that although rtkit itself is in the cpu:/

No. I do not. You stated it :)

As indicated by ps output, rtkit-daemon is *not* in cpu group

{pts/1}% ps xawf -eo pid,args,cgroup | grep rtkit
 3165 /usr/lib64/rtkit-daemon     name=systemd:/system/rtkit-daemon.service

Compare this with any other service like

{pts/1}% ps xawf -eo pid,args,cgroup | grep networkmanager
 1277 /usr/sbin/NetworkManager --
cpu:/system/networkmanager.service;name=systemd:/system/networkmanager.service
 2550  \_ /sbin/dhclient -d -4 -s
cpu:/system/networkmanager.service;name=systemd:/system/networkmanager.service

BTW rtkit is the only service having ControlGroup at all ...

{pts/1}% grep -r ControlGroup /lib/systemd/system
/lib/systemd/system/rtkit-daemon.service:ControlGroup=cpu:/

> cgroup it cannot make itself RT? That is really weird. What is the
> contents of /sys/fs/cgroup/cpu/cpu.rt_*_us?
>

{pts/1}% cat /sys/fs/cgroup/cpu/cpu.rt_*_us
1000000
950000


More information about the systemd-devel mailing list