New subject: ./autorelabel

19 Jul 2012


      Daniel J Walsh wrote:
...
On 07/19/2012 11:18 AM, m.roth@5-cent.us wrote:
...
Daniel J Walsh wrote:
...
On 07/19/2012 11:03 AM, m.roth@5-cent.us wrote:
...
I updated a CentOS system yesterday from 6.2 to 6.3. I saw it update
selinux-policy-targeted (I think it was) and several hours later, it
still hadn't gotten to the next package; looking, it appeared to be
running a restorecon. I killed it, and redid the update.
For other reasons, it didn't reboot. I brought it up under the most
recent previous kernel, it did an fsck on a 2T drive... then it's been
running autorelabel for at least an hour and a half, and I have no
idea how much longer it will be. It's longer than fsck.
This is a backup server, which uses hardlinks to save space.
You may not consider this a bug, but it certainly makes selinux close
to unusable in anything resembling a working environment.
If you have a volume with a huge number of files on it, you could mount
it with a context option and this will prevent restorecon from entering
the volume for relabel.  Otherwise an autorelabel will attempt to read
the context on ever file on the computer and "fix" it.
<snip>
...
...
But still, the fact that it takes that long is what I'm griping about.
If I'm doing an fsck -c, to check for bad blocks, I can understand why it
takes forever on 2T and 3T drives; but for this, where there are some
significantly smaller number of files than blocks, I still see that as a
problem.
Right when SELinux policy is updated it attempts to find the least
possible changes of labeling between the old labeling and the new labeling
(fixfiles -C filecontext.pre restore) In some cases this could get as
high as
...
restorecon -R -v /usr or restorecon -R -v /var which seems to be what
you saw.
As a datapoint, it's now been relabelling for at least three or three and
a half hours. As I noted above, I believe that there are significantly
fewer files on this f/s than there are physical blocks that an fsck -c
would check. Therefore, I suggest to you that you folks need to revisit
your code, and look at speed optimizations.
mark

Re: ./autorelabel