Bug 525948 - yum upgrade BackupPC takes 12 hours to complete
Summary: yum upgrade BackupPC takes 12 hours to complete
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: BackupPC
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Johan Cwiklinski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-27 15:35 UTC by Adam Goode
Modified: 2010-02-05 01:30 UTC (History)
3 users (show)

Fixed In Version: 3.1.0-11.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-02-03 20:06:23 UTC


Attachments (Terms of Use)

Description Adam Goode 2009-09-27 15:35:52 UTC
Description of problem:
When BackupPC is upgraded, it runs restorecon over /var/lib/BackupPC. This takes 12 hours on my machine, and it is not a very large pool.


Version-Release number of selected component (if applicable):
BackupPC-3.1.0-9.fc12.noarch

How reproducible:
When /var/lib/BackupPC has some content, after a few machines have been backed up.

Steps to Reproduce:
1. Back up some machines.
2. Wait for a new BackupPC.
3. yum upgrade
  
Actual results:
Takes 12 hours to run restorecon.

Expected results:
Does not take 12 hours.

Comment 1 Johan Cwiklinski 2009-09-27 16:25:18 UTC
I really do not know what you want me to do... 

If restorecon takes too long, that's not BackupPC related. Anyways, I've already run restorecon (on F-11, i'm not using rawhide) against Gigas of datas and thousands of files, that takes much time, but not 12 hours... 

Does running manually restorecon on you backup directory takes 12 hours ?

Comment 2 Adam Goode 2009-09-28 23:47:41 UTC
Running "find /var/lib/BackupPC" takes 20 minutes and returns 4123986 lines. 4 million filesystem objects is a lot to process. How long does "time find /var/lib/BackupPC | wc" take on your machine? restorecon could take several times that.

Why is restorecon run in the postinst script anyway? In most cases the files should be correctly labelled already, yes? Almost no packages do this, why does BackupPC?

Comment 3 Johan Cwiklinski 2009-09-29 14:27:11 UTC
$ time find /var/lib/BackupPC/ | wc
5498440 5914320 650213286

real    35m7.903s
user    1m5.754s
sys     3m8.160s

Files should be correctly labelled, but they're not... I've recently fixed a bug concerning the embedded selinux module, and relabelling should be required.

Relabelling should probably not be required each time, anyways ; I should consider to remove the restorecon from the package, user would be responsible to launch it in that case.
Also consider that BackupPC is not upgraded so frequently.

Comment 4 Bug Zapper 2009-11-16 13:00:44 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 Ray Todd Stevens 2010-01-11 20:46:20 UTC
I can confirm that on some volumes the relabel will take 12 hours or more.

I don't know if this is possible, but would it be possible to put out a notice that this is what is happening and that you just need to wait.  

Another weird option might be to put a job in the cron system to do this that self deletes.   But I am not in favor of this.

Comment 6 Joel Uckelman 2010-01-11 21:11:43 UTC
Is restorecon in need of some optimization? I don't have a good handle on whether we should expect it to take as long as it does.

In any case, updating an RPM is not an operation which anyone will expect to take more than a few minutes---so it warning the use that updating BackupPC could take ages might be wise if neither making restorecon faster nor avoiding it altogether are feasible.

Comment 7 Adam Goode 2010-01-11 21:19:49 UTC
Running "find /var/lib/BackupPC" takes 20 minutes. If restorecon takes 12 hours, that's only 36 times slower. Does restorecon do 36 times the amount of work of find? Maybe.

Comment 8 Johan Cwiklinski 2010-01-12 06:20:05 UTC
The only way I can "solve" that in the BackupPC RPM is to disable restorecon while upgrading but I'm affraid that should cause "SELinux issues" if a relabel were really required and the user is not aware of that...

Comment 9 Joel Uckelman 2010-01-12 10:49:13 UTC
Is it possible to detect the conditions under which a relabel is necessary, and only do it under those conditions? That would mitigate the problem somewhat.

Comment 10 Johan Cwiklinski 2010-01-12 16:19:36 UTC
(In reply to comment #9)
> Is it possible to detect the conditions under which a relabel is necessary, and
> only do it under those conditions? That would mitigate the problem somewhat.    

I do not think such a thing is possible.

On the other hand, for those that do not use /var/lib/BackupPC to store their backups (as I do), backup directory will never be relabelled by the package ; so I guess that disabling relabel at update time should not be a such bad idea.

Other opinions?

Comment 11 Ray Todd Stevens 2010-01-12 18:26:32 UTC
My thoughts on this is that this would be much better done as a script.   The script could be distributed as a part of the package, and then if needed run.   It could default to the /var/lib/BackupPC tree, and could be overriden with a parameter for whatever the real root is if someone is using a different one.

If you would post here or send me the relabel command I would be willing to take on the task of writing and documenting this script.

Comment 12 Joel Uckelman 2010-01-12 18:54:34 UTC
So, Comment 10 says

> I do not think such a thing is possible.

in reply to my question about detecting the conditions under which relabelling needs to happen. And Comment 11 suggests that relabelling "would be much better done as a script". 

> The script could be distributed as a part of the package, and then if needed run.

Either we can detect the conditions under which such a script would need to run, and then the RPM post-install script should do it for us, or we can't, in which case the user won't know when to run the proposed script, either.

Comment 13 Joel Uckelman 2010-01-12 19:28:41 UTC
Alternatively, is it just a bad idea to have BackuPC default to /var/lib/BackuPC for its storage? If it defaulted to, say, /home/BackupPC, then restorecon wouldn't need to be run at all, right?

Comment 14 Johan Cwiklinski 2010-01-15 19:55:54 UTC
The problem is not related to the path where are stored backups, all files owned by the package are relabelled actually.

I've asked the relabelling question on #selinx on IRC, and the response I get was: "Just restorecon on any files that it has special labels for.".
Package does not specify any specific context on /var/lib/BackupPC, so it does not have to relabel that directory.

I'll comit the change quickly.

Comment 15 Fedora Update System 2010-01-15 21:01:54 UTC
BackupPC-3.1.0-10.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/BackupPC-3.1.0-10.fc12

Comment 16 Fedora Update System 2010-01-15 21:01:59 UTC
BackupPC-3.1.0-8.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/BackupPC-3.1.0-8.fc11

Comment 17 Fedora Update System 2010-01-17 02:52:33 UTC
BackupPC-3.1.0-8.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update BackupPC'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0668

Comment 18 Fedora Update System 2010-01-17 02:55:07 UTC
BackupPC-3.1.0-10.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update BackupPC'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0692

Comment 19 Joel Uckelman 2010-01-17 12:46:13 UTC
The update still runs "restorecon -R /var/lib/BackupPC".

Comment 20 Fedora Update System 2010-01-17 14:03:31 UTC
BackupPC-3.1.0-11.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/BackupPC-3.1.0-11.fc12

Comment 21 Fedora Update System 2010-01-17 14:03:37 UTC
BackupPC-3.1.0-5.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/BackupPC-3.1.0-5.el5

Comment 22 Fedora Update System 2010-01-17 14:03:42 UTC
BackupPC-3.1.0-9.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/BackupPC-3.1.0-9.fc11

Comment 23 Johan Cwiklinski 2010-01-17 14:14:42 UTC
(In reply to comment #19)
> The update still runs "restorecon -R /var/lib/BackupPC".    

Indeed, I made a mistake, sorry. I've just pushed again an update to fix that.

Comment 24 Joel Uckelman 2010-01-17 15:52:14 UTC
(In reply to comment #23)
> (In reply to comment #19)
> > The update still runs "restorecon -R /var/lib/BackupPC".    
> 
> Indeed, I made a mistake, sorry. I've just pushed again an update to fix that.    

Thanks! This update installs in <3 minutes instead of multiple hours.

Comment 25 Fedora Update System 2010-01-18 23:22:28 UTC
BackupPC-3.1.0-5.el5 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update BackupPC'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2010-0079

Comment 26 Fedora Update System 2010-01-19 00:57:51 UTC
BackupPC-3.1.0-9.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update BackupPC'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0713

Comment 27 Fedora Update System 2010-01-19 01:01:26 UTC
BackupPC-3.1.0-11.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update BackupPC'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0741

Comment 28 Fedora Update System 2010-02-03 20:06:17 UTC
BackupPC-3.1.0-5.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 29 Fedora Update System 2010-02-05 01:26:55 UTC
BackupPC-3.1.0-9.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 30 Fedora Update System 2010-02-05 01:30:39 UTC
BackupPC-3.1.0-11.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


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