Bug 806369 - the /forcefsck file not being removed after filesystem check complete
the /forcefsck file not being removed after filesystem check complete
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-23 11:03 EDT by Daniel Belton
Modified: 2012-09-08 16:17 EDT (History)
11 users (show)

See Also:
Fixed In Version: selinux-policy-3.10.0-110.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 836644 (view as bug list)
Environment:
Last Closed: 2012-04-04 17:10:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Belton 2012-03-23 11:03:43 EDT
Description of problem:

When a filesystem check is forced on boot using /forcefsck, once the filesystem check is completed, the /forcefsck file should be removed, but it isn't

Version-Release number of selected component (if applicable):

systemd 44-1 fc17 

and

systemd 37-17 fc16

How reproducible:

touch /forcefsck
reboot

Steps to Reproduce:
1. touch /forcefsck
2. reboot
3. the /forcefsck file still exists after the filesystem check completes and the system boots.
  
Actual results:

/forcefsck file remains after filesystem check completed 


Expected results:

/forcefsck file should be removed once filesystem check completes

Additional info:

By not removing the /forcefsck file, then a filesystem check will be forced upon every boot until the file is manually removed. This is not proper behaviour, especially on systems with large filesystems that take a long time to check. 

This is occurring on Fedora 17, and Fedora 16.
Comment 1 Michal Schmidt 2012-03-23 11:22:23 EDT
I'd expect /forcefsck to be removed by systemd-tmpfiles-setup.service. There is a directive for it in /usr/lib/tmpfiles.d/systemd.conf.

Does "systemctl --failed" report any problems after boot?
Comment 2 Daniel Belton 2012-03-23 11:36:07 EDT
not a single one reported. No errors found in any of the logs either. 

[root@tower20 etc]# systemctl --failed
UNIT LOAD   ACTIVE SUB JOB DESCRIPTION

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

0 units listed. Pass --all to see inactive units, too.


Also, here is what is in my /usr/lib/tmpfiles.d/systemd.conf

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

# See tmpfiles.d(5) for details

d /run/user 0755 root root 10d
F /run/utmp 0664 root utmp -

f /var/log/wtmp 0664 root utmp -
f /var/log/btmp 0600 root utmp -

d /var/cache/man - - - 30d

r /forcefsck
r /forcequotacheck
r /fastboot

d /run/systemd/ask-password 0755 root root -
d /run/systemd/seats 0755 root root -
d /run/systemd/sessions 0755 root root -
d /run/systemd/users 0755 root root -
Comment 3 Daniel Belton 2012-03-23 11:41:26 EDT
well, look what I found..

[root@tower20 tmpfiles.d]# systemctl status systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories
	  Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static)
	  Active: active (exited) since Fri, 23 Mar 2012 09:53:34 -0500; 46min ago
	 Process: 515 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/systemd-tmpfiles-setup.service

Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: Successfully loaded SELinu...
Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: remove(/forcefsck): Permis...
[root@tower20 tmpfiles.d]# systemctl status systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories
	  Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static)
	  Active: active (exited) since Fri, 23 Mar 2012 09:53:34 -0500; 47min ago
	 Process: 515 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/systemd-tmpfiles-setup.service

Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: Successfully loaded SELinux database in 18ms 43us, size on heap is 525K.
Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: remove(/forcefsck): Permission denied
Comment 4 Michal Schmidt 2012-03-23 11:45:22 EDT
(In reply to comment #3)
> well, look what I found..
> 
> [root@tower20 tmpfiles.d]# systemctl status systemd-tmpfiles-setup.service
...
> Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: Successfully loaded SELinux
> database in 18ms 43us, size on heap is 525K.
> Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: remove(/forcefsck):
> Permission denied

Nice!
It runs as root, so the denial is likely due to SELinux. What context does the file have?: ls -lZ /forcefsck
Do you have any AVC denials logged?: ausearch -m avc -ts today
Comment 5 Daniel Belton 2012-03-23 11:48:19 EDT
[root@tower20 tmpfiles.d]# ls -lZ /forcefsck
-rw-r--r--. root root unconfined_u:object_r:etc_runtime_t:s0 /forcefsck


Looks like no AVC denials logged, though..

[root@tower20 tmpfiles.d]# ausearch -m avc -ts today
<no matches>
Comment 6 Michal Schmidt 2012-03-23 12:19:17 EDT
The AVC message could be in dmesg:
dmesg|grep -i avc
Comment 7 Daniel Belton 2012-03-23 12:21:23 EDT
yes, I do get one there.

[root@tower20 /]# dmesg | grep avc
[   46.540924] type=1400 audit(1332514414.367:4): avc:  denied  { write } for  pid=515 comm="systemd-tmpfile" name="/" dev="sda5" ino=2 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir
Comment 8 Michal Schmidt 2012-03-23 12:25:41 EDT
Reassigning to selinux-policy.
Please allow systemd-tmpfiles to delete files in the root directory.
Comment 9 Daniel Belton 2012-03-23 12:28:05 EDT
Thanks Michal for your very prompt response to this and all of your help in tracing the bug down :)
Comment 10 Miroslav Grepl 2012-03-26 09:49:56 EDT
So systemd-tmpfiles removes 

/forcefsck
/forcequotacheck
/fastboot

which means it would allow systemd_tmpfiles_t to remove files in the root directory.
Comment 11 Miroslav Grepl 2012-03-26 09:51:34 EDT
Are these files created only by a user?
Comment 12 Bill Nottingham 2012-03-26 11:27:04 EDT
They're created only by the administrator, yes.
Comment 13 Kay Sievers 2012-03-27 12:09:09 EDT
A general note. We recommend:
  fsck.mode=force
  fsck.mode=skip
on the kernel commandline to control the behaviour, instead of these flags
required to be created on the live filesystem.

Needing to write to the filesystem which is requested to be checked, is a
pretty bad idea and a kind of backwards logic, hence we recommend using only
the kernel commandline options and not the historic way doing that.

Some day in the future, we might remove all support for the (broken) flag
files, because it is really the wrong way to control that kind of behaviour.
Comment 14 Daniel Walsh 2012-03-27 14:54:27 EDT
Fixed in selinux-policy-3.10.0-107.fc17
Comment 15 Daniel Belton 2012-03-29 09:20:16 EDT
Daniel, it was also an issue in F16 as well. Is the selinux policy going to be updated for it as well?
Comment 16 Miroslav Grepl 2012-03-29 09:22:26 EDT
Yes.
Comment 17 Daniel Belton 2012-03-30 01:27:35 EDT
Installed the selinux-policy-3.10.0-108.fc17 from koji and it appears this issue has been resolved. 

The file /forcefsck is now removed once the filesystem checks are completed.

I will be using the fsck.mode=force on the kernel line in the future, though. I do agree, it is a bad idea to write to the filesystem that needs checking, and about the only time I use /forcefsck is when the root filesystem needs checking since that is is about the only one I can't umount and check while the system is up and running. 

Actually, it would be nice if the forced filesystem check could be limited to the root filesystem, but that is beyond the scope of this bug :)
Comment 18 Fedora Update System 2012-04-03 03:43:42 EDT
selinux-policy-3.10.0-110.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-110.fc17
Comment 19 Fedora Update System 2012-04-04 17:10:27 EDT
selinux-policy-3.10.0-110.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 20 igor.redhat@gmail.com 2012-06-09 17:23:23 EDT
FWIW, this still hasn't been fixed for F16 as far as I can tell...
Comment 21 Miroslav Grepl 2012-06-11 08:35:17 EDT
Please open a new bug for F16. Thank you.
Comment 22 igor.redhat@gmail.com 2012-06-29 14:41:44 EDT
Apologies for the delay, here it is: bug 836644
Comment 23 João Carlos Mendes Luís 2012-08-22 19:55:21 EDT
(In reply to comment #13)
> A general note. We recommend:
>   fsck.mode=force
>   fsck.mode=skip
> on the kernel commandline to control the behaviour, instead of these flags
> required to be created on the live filesystem.
> 
> Needing to write to the filesystem which is requested to be checked, is a
> pretty bad idea and a kind of backwards logic, hence we recommend using only
> the kernel commandline options and not the historic way doing that.
> 
> Some day in the future, we might remove all support for the (broken) flag
> files, because it is really the wrong way to control that kind of behaviour.

This will be usefull if and only if there is a way to pass arguments into a rebooting kernel, like Solaris do: http://docs.oracle.com/cd/E19082-01/819-2240/reboot-1m/index.html

While this is not possible, I really miss shutdown -F

Note You need to log in before you can comment on or make changes to this bug.