./autorelabel

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/19/2012 01:54 PM, m.roth at 5-cent.us wrote:
> Daniel J Walsh wrote:
>> On 07/19/2012 11:18 AM, m.roth at 5-cent.us wrote:
>>> Daniel J Walsh wrote:
>>>> On 07/19/2012 11:03 AM, m.roth at 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
> 
> -- selinux mailing list selinux at lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/selinux
> 
THis code has been heavily optimized over the years, I have no heard of
something this slow, so maybe there is a bug being triggered.  Does find /
take a huge amount of time on this machine?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAJvv4ACgkQrlYvE4MpobMSlACgtuBnRDUD8fjooPVArXInW7H4
ezgAoKvKXs8OMpK+eXhTqxF+6NdOdLeL
=3tpu
-----END PGP SIGNATURE-----