Discussion:
pam_limits: Could not set limit for ...: Operation not permitted
(too old to reply)
Kai Krakow
2014-12-15 21:42:51 UTC
Permalink
Hello!

I'm seeing the following errors in systemd's journal:

Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session):
Could not set limit for 'memlock': Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session):
Could not set limit for 'nice': Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session):
Could not set limit for 'rtprio': Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: PAM audit_log_acct_message() failed:
Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: Failed at step PAM spawning
/usr/lib/systemd/systemd: Operation not permitted

Is it meaningless? Do I have to worry? Or which configuration do I miss?
--
Replies to list only preferred.
Lennart Poettering
2015-02-03 17:59:12 UTC
Permalink
Post by Kai Krakow
Hello!
Could not set limit for 'memlock': Operation not permitted
Could not set limit for 'nice': Operation not permitted
Could not set limit for 'rtprio': Operation not permitted
Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: Failed at step PAM spawning
/usr/lib/systemd/systemd: Operation not permitted
Is it meaningless? Do I have to worry? Or which configuration do I miss?
Hmm, this is certainly weird. It indicates some issue with your PAM
setup maybe? Do you have SELinux enabled? Is this in some container or so?

Lennart
--
Lennart Poettering, Red Hat
Kai Krakow
2015-02-10 07:42:02 UTC
Permalink
Post by Lennart Poettering
Post by Kai Krakow
Hello!
Could not set limit for 'memlock': Operation not permitted
Could not set limit for 'nice': Operation not permitted
Could not set limit for 'rtprio': Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: PAM audit_log_acct_message()
failed: Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: Failed at step PAM spawning
/usr/lib/systemd/systemd: Operation not permitted
Is it meaningless? Do I have to worry? Or which configuration do I miss?
Hmm, this is certainly weird. It indicates some issue with your PAM
setup maybe? Do you have SELinux enabled? Is this in some container or so?
This is a Gentoo box, plain hardware. My pam configuration looks right. When
I run "systemd --user" manually through strace, I see missing permissions on
cgroups. But I almost guess this is intended if running from an already
existing user session.

I don't use SELinux or similar security policies, just plain Linux security
policy as it is default in Gentoo. But strangely systemd gives me on boot:

systemd 218 running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR
+SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP
+BLKID +ELFUTILS +KMOD +IDN)

I don't know why smack is enabled... It's not in my kernel and isn't set as
a feature to compile in the ebuild. But I'm not sure if it would make a
difference for this problem.

I suppose for the same reason, rtkit-daemon cannot give RT priority to
itself...

$ journalctl -b -p err
-- Logs begin at So 2014-05-25 21:33:33 CEST, end at Di 2015-02-10 08:35:24
CET. --
Feb 08 19:42:24 jupiter bluetoothd[714]: Sap driver initialization failed.
Feb 08 19:42:24 jupiter bluetoothd[714]: sap-server: Operation not permitted
(1)
Feb 08 19:42:26 jupiter systemd[843]: pam_limits(systemd-user:session):
Could not set limit for 'memlock': Operation not permitted
Feb 08 19:42:26 jupiter systemd[843]: pam_limits(systemd-user:session):
Could not set limit for 'rtprio': Operation not permitted
Feb 08 19:42:26 jupiter systemd[843]: Failed at step PAM spawning
/usr/lib/systemd/systemd: Operation not permitted
Feb 08 19:42:41 jupiter rtkit-daemon[1636]: Failed to make ourselves RT:
Operation not permitted
Feb 08 19:42:41 jupiter rtkit-daemon[1636]: Failed to make ourselves RT:
Operation not permitted
Feb 08 19:42:41 jupiter rtkit-daemon[1636]: Failed to make ourselves RT:
Operation not permitted
Feb 08 19:42:41 jupiter rtkit-daemon[1636]: Failed to make ourselves RT:
Operation not permitted
Feb 08 19:42:41 jupiter rtkit-daemon[1636]: Failed to make ourselves RT:
Operation not permitted
[...many iterations of the same message...]

Maybe my kernel config is wrong although I'm pretty sure I set all the
recommended options. If you point me to which kernel options come into play
here, I'd be happy to dump those and/or try again with another set of
options.

My pam config is plain Gentoo with the recommended systemd settings (which
are default since many iterations of the ebuild package):

$ cat /etc/pam.d/systemd-user
# This file is part of systemd.
#
# Used by systemd --user instances.
account include system-auth
session include system-auth

$ cat /etc/pam.d/system-auth ## lines reindented for readability
auth required pam_env.so
auth sufficient pam_ssh.so
auth required pam_unix.so try_first_pass likeauth nullok
auth optional pam_permit.so
account required pam_unix.so
account optional pam_permit.so
password required pam_cracklib.so difok=2 minlen=8 dcredit=2
ocredit=2 retry=3
password required pam_unix.so try_first_pass use_authtok
nullok sha512 shadow
password optional pam_permit.so
session optional pam_ssh.so
session required pam_limits.so
session required pam_env.so
session required pam_unix.so
session optional pam_permit.so
-session optional pam_systemd.so

Thanks for investigating...
--
Replies to list only preferred.
Lennart Poettering
2015-02-10 10:58:42 UTC
Permalink
Post by Kai Krakow
Post by Lennart Poettering
Post by Kai Krakow
Could not set limit for 'memlock': Operation not permitted
Could not set limit for 'nice': Operation not permitted
Could not set limit for 'rtprio': Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: PAM audit_log_acct_message()
failed: Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: Failed at step PAM spawning
/usr/lib/systemd/systemd: Operation not permitted
Is it meaningless? Do I have to worry? Or which configuration do I miss?
Hmm, this is certainly weird. It indicates some issue with your PAM
setup maybe? Do you have SELinux enabled? Is this in some container or so?
This is a Gentoo box, plain hardware. My pam configuration looks right. When
I run "systemd --user" manually through strace, I see missing permissions on
cgroups. But I almost guess this is intended if running from an already
existing user session.
Yeah, --user instances of systemd don't get access to the controller
attributes of the cgroup tree, and that's intended.
Post by Kai Krakow
I don't use SELinux or similar security policies, just plain Linux security
systemd 218 running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR
+SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP
+BLKID +ELFUTILS +KMOD +IDN)
I don't know why smack is enabled... It's not in my kernel and isn't set as
a feature to compile in the ebuild. But I'm not sure if it would make a
difference for this problem.
Well, turn it off during build-time if you don't want it. Use
--disable-smack. It is enabled by default, since all features we
consider stable are enabled by default unless their library
dependencies are missing. Since SMACK so far didn't require any
library it hence is effectively always on unless you explicitly turn
it off...
Post by Kai Krakow
I suppose for the same reason, rtkit-daemon cannot give RT priority to
itself...
This is unrelated. The kernel RT cgroup API is really just awfully
broken, ignore this.

Not sure what else I can suggest...

Lennart
--
Lennart Poettering, Red Hat
Kai Krakow
2015-02-10 19:16:03 UTC
Permalink
Post by Lennart Poettering
Post by Kai Krakow
Post by Lennart Poettering
Operation not permitted Dez 15 22:33:57 jupiter systemd[1515]: PAM
audit_log_acct_message() failed: Operation not permitted
Dez 15 22:33:57 jupiter systemd[1515]: Failed at step PAM spawning
/usr/lib/systemd/systemd: Operation not permitted
Is it meaningless? Do I have to worry? Or which configuration do I miss?
Hmm, this is certainly weird. It indicates some issue with your PAM
setup maybe? Do you have SELinux enabled? Is this in some container or so?
This is a Gentoo box, plain hardware. My pam configuration looks right.
When I run "systemd --user" manually through strace, I see missing
permissions on cgroups. But I almost guess this is intended if running
from an already existing user session.
Yeah, --user instances of systemd don't get access to the controller
attributes of the cgroup tree, and that's intended.
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 ***@...service (but shouldn't it work then
when started from the normal service startups in systemd).

I don't consider this a bug, but my main problem with this is I have no idea
how to track that down.
Post by Lennart Poettering
Post by Kai Krakow
I don't use SELinux or similar security policies, just plain Linux
security policy as it is default in Gentoo. But strangely systemd gives
systemd 218 running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR
+SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ +LZ4
+SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
I don't know why smack is enabled... It's not in my kernel and isn't set
as a feature to compile in the ebuild. But I'm not sure if it would make
a difference for this problem.
Well, turn it off during build-time if you don't want it. Use
--disable-smack. It is enabled by default, since all features we
consider stable are enabled by default unless their library
dependencies are missing. Since SMACK so far didn't require any
library it hence is effectively always on unless you explicitly turn
it off...
If it doesn't hurt either, I just let it the way it is. There was just this
idea it could be related to the problem. But from your words I guess: nope.
Post by Lennart Poettering
Post by Kai Krakow
I suppose for the same reason, rtkit-daemon cannot give RT priority to
itself...
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?
Post by Lennart Poettering
Not sure what else I can suggest...
I appreciate that you answered although this was pretty old. Good to know
thinks don't become forgotten, just take time. ;-)
--
Replies to list only preferred.
Lennart Poettering
2015-02-10 20:19:40 UTC
Permalink
Post by Kai Krakow
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
when started from the normal service startups in systemd).
logind maintains one ***@.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.
Post by Kai Krakow
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?
Post by Kai Krakow
Post by Lennart Poettering
Post by Kai Krakow
I suppose for the same reason, rtkit-daemon cannot give RT priority to
itself...
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...

Lennart
--
Lennart Poettering, Red Hat
Kai Krakow
2015-02-10 21:28:23 UTC
Permalink
Post by Lennart Poettering
Post by Kai Krakow
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
then when started from the normal service startups in systemd).
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 ***@.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.
Post by Lennart Poettering
Post by Kai Krakow
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?
Post by Lennart Poettering
Post by Kai Krakow
Post by Lennart Poettering
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.
Andrei Borzenkov
2015-02-11 05:47:12 UTC
Permalink
В Tue, 10 Feb 2015 22:28:23 +0100
Post by Kai Krakow
Post by Lennart Poettering
Post by Kai Krakow
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
then when started from the normal service startups in systemd).
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.
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?
Post by Kai Krakow
Post by Lennart Poettering
Post by Kai Krakow
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?
Post by Lennart Poettering
Post by Kai Krakow
Post by Lennart Poettering
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.
Kai Krakow
2015-02-11 19:07:52 UTC
Permalink
Post by Andrei Borzenkov
В Tue, 10 Feb 2015 22:28:23 +0100
Post by Kai Krakow
Post by Lennart Poettering
Post by Kai Krakow
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
shouldn't it work then when started from the normal service startups
in systemd).
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.
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.
Lennart Poettering
2015-02-11 11:42:29 UTC
Permalink
Post by Kai Krakow
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...
Post by Kai Krakow
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.

Lennart
--
Lennart Poettering, Red Hat
Kai Krakow
2015-02-11 19:05:12 UTC
Permalink
Post by Lennart Poettering
Post by Kai Krakow
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.
Post by Lennart Poettering
Post by Kai Krakow
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.
Lennart Poettering
2015-02-11 19:27:38 UTC
Permalink
Post by Kai Krakow
Post by Lennart Poettering
Post by Kai Krakow
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.
Well, I can't see the relation between groups and rlimits I must
say... Unless the default limits.conf on Gentoo sets something weird
for members of those groups...
Post by Kai Krakow
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.
Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Hmm, maybe Gentoo ships some dbus hookup for systemd user sessions
that triggers this?

Simon is working on getting this cleaned up in dbus-daemon upstream,
see the other threads about that.

Lennart
--
Lennart Poettering, Red Hat
Kai Krakow
2015-02-11 20:11:04 UTC
Permalink
Post by Lennart Poettering
Post by Kai Krakow
Post by Lennart Poettering
Post by Kai Krakow
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.
Well, I can't see the relation between groups and rlimits I must
say... Unless the default limits.conf on Gentoo sets something weird
for members of those groups...
Me neither, especially since there is nothing special except maybe this one:

$ cat /etc/security/limits.d/40-realtime-base.conf
# Start of 40-realtime-base.conf from realtime-base-0.1
@realtime - rtprio 99
@realtime - memlock unlimited
# End of 40-realtime-base.conf from realtime-base-0.1

But that becomes installed as a dependency of rtkit.
Post by Lennart Poettering
Post by Kai Krakow
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.
Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Hmm, maybe Gentoo ships some dbus hookup for systemd user sessions
that triggers this?
It's triggered by gnome-keyring-daemon... I already set DISPLAY=:0 in
user.conf just to try. This allows me to "systemctl --user start
obex.service" so the change was applied but didn't fix the messages.
Essentially, the messages may have been there before and I just didn't
Post by Lennart Poettering
Simon is working on getting this cleaned up in dbus-daemon upstream,
see the other threads about that.
Yeah I already discovered that and thus currently won't work that out
further in this thread. I'll follow the discussion and jump in when I feel
I'd like to.

Thanks for bothering, it's appreciated.
--
Replies to list only preferred.
Kai Krakow
2015-02-22 14:36:57 UTC
Permalink
Post by Kai Krakow
Post by Lennart Poettering
Post by Kai Krakow
Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Hmm, maybe Gentoo ships some dbus hookup for systemd user sessions
that triggers this?
It's triggered by gnome-keyring-daemon... I already set DISPLAY=:0 in
user.conf just to try. This allows me to "systemctl --user start
obex.service" so the change was applied but didn't fix the messages.
Essentially, the messages may have been there before and I just didn't
Post by Lennart Poettering
Simon is working on getting this cleaned up in dbus-daemon upstream,
see the other threads about that.
Yeah I already discovered that and thus currently won't work that out
further in this thread. I'll follow the discussion and jump in when I feel
I'd like to.
BTW: This error message is gone since 219. I guess this is because this
version of systemd now exports some extra variables.
--
Replies to list only preferred.
Continue reading on narkive:
Loading...