[systemd-devel] systemd-logind retrying constantly when operation is denied by selinux

[Tim Cuthbertson]

I recently noticed loud and sustained disk noise, and iotop reported that
jdb2 was going full throttle on /dev/sda1 (my root partition). I ran
`journalctl -f` to see if anything obvious was wrong, and was greeted with
the following messages:

Jan 03 10:23:04 meep systemd[1]: SELinux policy denies access.
Jan 03 10:23:04 meep systemd-logind[447]: Failed to query ActiveState:
Access denied

These two messages were appearing constantly - more than 200x per second
each. I quickly ran `setenforce 0`, and everything went quiet.

I think this is due to something I did yesterday - I used `audit2allow` to
allow system-wide systemd unit files to live in a home directory[0]. This
rule added:

    allow systemd_logind_t user_home_t:service start;

When I run audit2allow again now (after the errors), it wants to add:

    allow systemd_logind_t user_home_t:service { status stop };

I have now changed this to:

    allow systemd_logind_t user_home_t:service *;

Which seems to compile, and hopefully won't cause the problem to recur
whenever systemd performs a new operation on this service. But I thought
I'd report my observations here anyway, since it seems pretty drastic for
systemd-logind to be retrying this failed operation 200+ times a second
when the error is "access denied" (something that is unlikely to be fixed
in the next few milliseconds).

Of course, I don't know if this failure case is distinct from other errors
that *do* benefit from immediate-and-furious-retry, so I'll leave it to the
developers to determine whether something better can / should be done here.

Cheers,
 - Tim.

[0] I have a modified user at .service unit file managed in my home partition,
because I want to run `systemd --user` via a wrapper that picks up
additional user config. I symlink it under /etc/systemd/system/ rather than
keeping it in there because / is wiped on OS upgrades, but /home is a
separate partition that I keep between upgrades.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140103/7a2b6bff/attachment.html>