Hide Forgot
Description of problem: Every time I boot my laptop I see restorecon running the first 15-20 minutes and it chews CPU to the point where my system is close to unusable for that period. The process runs as a child of systemd with the following command line: 2545 ? D 5:22 /sbin/restorecon -e /var/lib/stateless/writable -e /data -e /config -e /proc -e /sys -rv / A full relabel was run before I checked the last time. I booted a new kernel, full relabel was run during boot. Then I logged in and saw restorecon running after login. After this I rebooted and this time no relabel during boot, but restorecon is running after I log in. Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Are you sure it is restorecon or restorecond? There is a difference. restorecond is a user daemon that watches for you creating content in your homedir and fixes the labels.
You can see the command line above in my comment. I don't have policycoreutils-restorecond installed on my system.
Kjartan, Do you have a /.autorelabel file on your machine? systemd should be blocking waiting for the relabel to finish. And the relabel is supposed to remove the /.autorelabel when it is done. /lib/systemd/fedora-autorelabel is the script that does the relabel.
No the /.autorelabel file is gone. I created one to see if a forced relabel would help, but it didn't.
If you are seeing restorecon running in back ground on every boot then something is going very wrong on your system. I would check the /lib/systemd/fedora-autorelabel and comment out the fixfiles line and see if that stops the problem. This would tell us that systemd thinks the system wants to relabel after every boot. One last thing, you did not add auditrelabel to a grub line on the kernel? Check /etc/grub.conf
cat /proc/cmdline
(In reply to comment #0) > 2545 ? D 5:22 /sbin/restorecon -e /var/lib/stateless/writable -e > /data -e /config -e /proc -e /sys -rv / I don't think that's the commandline that the fedora-autorelabel script uses. Can you try to find out which systemd service this process belongs to? To do that you can use: systemctl status 2545 or cat /proc/2545/cgroup (of course the PID will be different every boot, so substitute the right one)
no auditrelabel in grub.conf. I'll check the other suggestions when I reboot next.
[kmaraas@e4300 ~]$ systemctl status 3231 ovirt-firstboot.service - SYSV: ovirt-firstboot node configuration script Loaded: loaded (/etc/rc.d/init.d/ovirt-firstboot) Active: activating (start) since Wed, 14 Dec 2011 23:25:41 +0100; 1min 27s ago Control: 3223 (ovirt-firstboot) CGroup: name=systemd:/system/ovirt-firstboot.service ├ 3223 /bin/bash /etc/rc.d/init.d/ovirt-firstboot start └ 3231 /sbin/restorecon -e /var/lib/stateless/writable -e... [kmaraas@e4300 ~]$
=> ovirt-node.
Although, why do you have this enabled? Is it intentional?
No, probably just because I installed the ovirt stuff just to check it out at some point.
This isn't a bug. This is normal behavior on an oVirt Node Livecd. ovirt-node package isn't meant to be installed on normal Fedora systems, only on the Livecd based image oVirt Node ISO. I'll close this as notabug, and the solution should just be to yum remove the ovirt-node package from your system.