With kernel 2.6.31, restorecond uses 99% of my CPU.
This is because removing and readding the watch on utmp triggers inotify to
return an IN_IGNORED event for the old watch descriptor. If the watch gets
allocated the same wd when it is readded, then restorecond thinks that utmp
has changed, so removes and readds the watch again, potentially looping.
With kernel <= 2.6.30, this never happened, because the kernel didn't reuse
watch descriptors. So the IN_IGNORED event comes with a wd that is no
longer in use, and gets ignored. But kernel 2.6.31 reuses the same watch
descriptor. The kernel has been fixed to not reuse watch descriptors.
However as some kernels do reuse them, and its possible they may again,
this patch fixes that by ignoring inotify events whose only bit set is
IN_IGNORED.
Signed-off-by: Martin Orr <martin@martinorr.name>
Signed-off-by: Manoj Srivastava <srivasta@debian.org>
Signed-off-by: Laurent Bigonville <bigon@debian.org>
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
Do not assume it is always a success and error gracefully when it isn't.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
Basically this patch makes restorecond a dbus session service that can
be run in the users session to watch the creation of files in the
homedir. Most of the changes are just to get it to run as a dbus
session and then to allow it to read its own config.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
