Bug 862626
Summary: | /.autorelabel gets recreated and file system gets relabelled on every boot | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Fikret Skrgic <skrgic> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | dominick.grift, dwalsh, iarlyy, johannbg, jonathan, lnykryn, metherid, mgrepl, mschmidt, msekleta, notting, plautrba, systemd-maint, vpavlin |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-08-01 11:25:18 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Fikret Skrgic
2012-10-03 11:55:19 UTC
Thank you for your support. Relabeling should never happen on a disabled SELinux box? I have not heard of this bug before. You could try to disable this service. /usr/lib/systemd/system/fedora-autorelabel.service If this is happening to everyone it is a serious bug, in systemd. I can not get this to happen on my F18 box. I managed to stop the recreation of /.autorelabel by deleting the files below and replacing them with symbolic links to /dev/null. rm /usr/lib/systemd/system/fedora-autorelabel-mark.service rm /usr/lib/systemd/system/fedora-autorelabel.service ln -s /dev/null /usr/lib/systemd/system/fedora-autorelabel-mark.service ln -s /dev/null /usr/lib/systemd/system/fedora-autorelabel.service Trying to disable them, didn't help: systemctl disable fedora-autorelabel.service systemctl disable fedora-autorelabel-mark.service /.autorelabel was still always recreated. With the files removed I verified that it doesn't get created any more. It is better now, but not perfect. [root@turing fskrgic]# systemd-analyze blame 9913ms network.service 6055ms udev-settle.service 5199ms home.mount 1915ms lvm2-monitor.service 1853ms fedora-storage-init-late.service 1843ms fedora-readonly.service 1592ms fedora-loadmodules.service 1574ms systemd-logind.service 1549ms avahi-daemon.service 1495ms jetty.service 1316ms colord-sane.service 1254ms colord.service 1209ms systemd-vconsole-setup.service 1123ms media.mount 1114ms abrt-vmcore.service 1077ms dev-hugepages.mount 1074ms fedora-storage-init.service 1065ms dev-mqueue.mount 1051ms sendmail.service 1049ms udev-trigger.service 1049ms sys-kernel-debug.mount 1021ms udev.service 825ms systemd-remount-fs.service 821ms sshd.service 786ms rtkit-daemon.service 508ms sys-kernel-config.mount 442ms upower.service 423ms bluetooth.service 336ms systemd-readahead-collect.service 312ms systemd-readahead-replay.service 298ms console-kit-log-system-start.service 250ms boot.mount 179ms systemd-user-sessions.service 172ms gpm.service 165ms irqbalance.service 138ms acpid.service 115ms mcelog.service 98ms console-kit-daemon.service 96ms mdmonitor.service 93ms mdmonitor-takeover.service 79ms sm-client.service 64ms dbus.service 47ms rc-local.service 32ms systemd-sysctl.service 28ms fedora-wait-storage.service 5ms rpcbind.service 1ms sys-fs-fuse-connections.mount Something is fishy anyway. As hardware gets faster and faster, booting should also become faster and faster. I remember reading about how systemd would improve the boot time. I see the opposite. I think that there's a trend of everything getting steadily slower in the decade (on roughly as fast hardware as available at the time) including desktop environments. Selinux, IMHO, is the biggest mistake in the history of Linux. It's just such a bad idea I am really surprised the usually conservative crowd dealing with the guts of the system accepted it. It's just like not being able to remove Internet Explorer from Windows. Actually, it's worse, since this has very limited usage. It's barely useful to anyone. The creation of .autorelabel is not the problem. Since this should be created on a disabled machine. The init script paying attention to /.autorelabel on a disabled SELinux machine is the problem. I find systemd with a Solid State Drive to be very fast in booting, on a regular disk, it is not going to speed up the machine. Reassigning to initscripts, since this is not an selinux-policy issue. .autorelabel creation is predicated on booting without selinux; that's entirely expected. However, fedora-autorelabel.service has: ConditionSecurity=selinux ConditionKernelCommandLine=|autorelabel ConditionPathExists=|/.autorelabel so it shouldn't even be running if SELinux is disabled. Moving to systemd... when you see a boot taking forever, what do you get for 'systemctl status fedora-autorelabel.service'? How *exactly* did you disable SELinux?
On a side note:
> ln -s /dev/null /usr/lib/systemd/system/fedora-autorelabel.service
Modifying files under /usr/lib is a bad idea. A package update will revert your changes. You can put the symlink under /etc/systemd/system, or you can use:
systemctl mask fedora-autorelabel.service
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |