Lennart Poettering <lenn...@poettering.net> schrieb: > On Tue, 10.02.15 08:42, Kai Krakow (hurikha...@gmail.com) wrote: > >> >> 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? >> > >> > 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 user@...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. >> 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. > > 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. >> 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? > 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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
