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

Kai Krakow hurikhan77 at gmail.com
Wed Feb 11 11:07:52 PST 2015


Andrei Borzenkov <arvidjaar at gmail.com> schrieb:

> В 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?

Debugging did not help at all (nothing useful in the output, it even was 
pretty terse). But thanks anyway because it gave me some pointers where to 
look and I "repaired" my group memberships (tho, out of pure desperation)... 
See my other post answering Lennart.

-- 
Replies to list only preferred.



More information about the systemd-devel mailing list