[systemd-devel] pam_limits: Could not set limit for ...: Operation not permitted

[Kai Krakow]

Lennart Poettering <lennart at poettering.net> schrieb:

> On Tue, 10.02.15 20:16, Kai Krakow (hurikhan77 at gmail.com) wrote:
> 
>> Then the question is: Why or what does try to start a user session in the
>> first place? I don't think KDE does this as it's not there yet (at least
>> in KDE 4.x). And I didn't enable a user at ...service (but shouldn't it work
>> then when started from the normal service startups in systemd).
> 
> logind maintains one user at .service instance per-user as long as she or
> he is logged in at least once. The service is basically ref-counted by
> the user's session.

So, be patient with me until I fully understand it... I'm using kdm 
(previously lightdm but made no difference) to launch my KDE session. At 
some time in the process, the aforementioned messages get logged. As far as 
I can tell, logind is involved in this as it actually does spawn my 
graphical session.

That in turn, according to your words, means: A user at .service for me should 
be launched (whether I need it or not).

If this is true, I should see a systemd user instance in "ps axuw", or 
simpler: Another systemd process except PID1 should be running.

So far the outcome is: It doesn't but I instead see those error logs in the 
journal.

>> I don't consider this a bug, but my main problem with this is I have no
>> idea how to track that down.
> 
> Do you have any weird kernel patch applied, something that is supposed
> to improve security or so?

This is the plain Gentoo kernel 3.18.6 for desktop, nothing special except 
BFQ patches (applied by the Gentoo kernel package itself, not manually 
patched). I'm pretty sure Gentoo does not apply any special extra patches. 
Autogrouping for cgroups (SCHED_AUTOGROUP) is turned on - I'm not sure if it 
plays into the issue but from what I read it shouldn't.

Maybe I should diff my kernel config with one that doesn't show this 
behaviour. Do you have one I should compare with? 

>> > This is unrelated. The kernel RT cgroup API is really just awfully
>> > broken, ignore this.
>> 
>> Maybe just turn off the RT_FIFO feature in the kernel for the time
>> being?
> 
> Nah, just ignore that log msg...

I meant SCHED_OTHER/RR_FIFO, but I'll ignore that then.

-- 
Replies to list only preferred.