[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 22:28, Kai Krakow (hurikhan77 at gmail.com) wrote:
> 
>> 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.
> 
> BFQ? What is that? I'd really try a vanilla kernel before checking
> anything else...

Bucket Fair Queue... A "better" variant of CFQ. I think it wouldn't matter.

Well, thanks to your pointers, I somehow solved it. I don't know exactly why 
because adding "debug" to pam_limits and pam_systemd yielded nothing 
helpful. But I figured that I was part in many - historically needed - 
groups. Those were added by Gentoo previously and according to post install 
instruction, you had to be member of realtime, pulse, pulse-access, video, 
audio etc etc etc. I've removed myself from those groups since I guess 
systemd takes care of that now.

The error message in the log is now gone and to my surprise, there's a 
running "systemd --user" instance for my uid in the process list now.

But now I got a new message in the log:
Unable to autolaunch a dbus-daemon without a $DISPLAY for X11

I'd be happy, to fix that, too. ;-) Tho, not sure if systemd is there yet 
(at least regarding KDE).

My dbus session and services like obexd nevertheless run after login, 
however they weren't started through means of systemd. I guess kded took 
care of it.

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

Well, fixed by removing myself from different historically needed groups (in 
Gentoo at least). Tho, there was nothing special about these groups in 
limits.conf or limits.d/*.conf (read: non-existent)... So I don't know where 
the culprit is to be found - probably not in systemd but somewhere deep 
inside Gentoo login logic and the fact that group-membership is documented 
during install, but "dismembership" isn't during upgrades.

Thanks for your help. :-)

-- 
Replies to list only preferred.