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

[Andrei Borzenkov]

В Tue, 10 Feb 2015 22:28:23 +0100
Kai Krakow <hurikhan77 at gmail.com> пишет:

> 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.
> 

Well, it fails at spawning it. What is the content of your limits.conf?
Did you try to enable pam_limits debugging?

> >> 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.
>