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. > 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... > > 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
