Bug 132230

Summary:	prelink could use some locking
Product:	[Fedora] Fedora	Reporter:	Alexandre Oliva <oliva>
Component:	prelink	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	mattdm, triage
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	bzcl34nup
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-04-05 07:26:50 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1366045

Description Alexandre Oliva 2004-09-10 01:18:07 UTC

Description of problem:
If you turn you box on at a certain time of the day such that anacron
starts prelink an hour or so later, and then cron runs prelink at the
regular time, you'll end up with two prelink runs at the same time. 
If one of them happens to be a full run (or maybe regardless of that),
you may end up with warning messages like this in /var/log/prelink.log:

 /usr/sbin/prelink: /usr/lib/firefox-0.9.3/xpt_dump: Library
/lib/libdl.so.2 has changed since it has been prelinked

Trying to help things out and starting prelink by hand can only make
things worse.

This, besides the potential race condition of prelink and rpm package
installation, makes me wonder if prelink shouldn't do some kind of
locking, using perhaps the rpm transaction lock file.  Except that
prelink could probably use a timeout of say 1-2 hours, to make sure a
box that takes say more than 24 hours to run prelink (yuck!) doesn't
end up with a growing number of copies of prelink fighting each other.


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

Comment 1 Bill Nottingham 2004-09-10 02:02:45 UTC

Or, switch to a different cron daemon that integrates the anacron
functionality. :)

Comment 2 Alexandre Oliva 2004-09-10 03:43:58 UTC

I'll give you that this would address the first concern I bring up,
but it wouldn't solve issues from running prelink by hand, or having
the cron-start prelink kick in while installing updates or running
rpm.  If you're sufficiently unlucky, prelink can overwrite a library
just after rpm installs it, and this could be pretty bad.

Comment 3 Jakub Jelinek 2004-09-30 09:19:43 UTC

Well, you get warnings, but that's the worst thing that should happen
if multiple prelink's run at the same time.
prelink will not modify the library if it changed while it was running
(unless you hit the window in between the last check and rename).
But even in that case, if it is multiple prelinks that compete,
you'll just end up with some binaries that can't use prelinking
advantage until next prelink run.

Therefore I don't think /usr/sbin/prelink should do any locking.

Perhaps the cron.daily script could run some tiny proglet (or is it doable in python too)
which would acquire rpm database lock and release it when done.

Comment 4 Alexandre Oliva 2004-10-08 21:06:08 UTC

FWIW, I was just hit by the problem scenario I described.  I installed
an FC3test3 release candidate and then, after the first boot,
proceeded to update it to yesterday's rawhide.  The up2date run took a
very long time, given the large number of packages, and, in the middle
of the install, I saw some ldconfig errors about zero-sized files,
that kept changing, so I know they weren't left-overs from shutdowns
during prelink runs; prelink was actually running.  Today, when I
tried to run up2date again, to update to today's rawhide, up2date
would crash.  LD_DEBUG showed it was in the middle of a library that
had been updated yesterday.  Un-prelinking the entire system didn't
help, but re-installing the library package fixed the problem.

Comment 5 Matthew Miller 2006-07-10 22:30:23 UTC

Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 6 Alexandre Oliva 2006-08-01 03:46:30 UTC

I still don't see any conflict-avoidance with rpm in place, but I haven't seen
this problem lately.

Comment 7 Bug Zapper 2008-04-03 15:38:44 UTC

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 8 Alexandre Oliva 2008-04-05 07:10:13 UTC

IIRC I was something about avoiding running prelink while update transactions
were underway, but I don't think there's anything that will stop transactions
from being started while prelink is running.  Should this be a WONTFIX?

Comment 9 Jakub Jelinek 2008-04-05 07:26:50 UTC

I guess so, at least until the kernel provides sufficiently atomic syscalls
(rename only if the target filename has matching st_dev/st_ino).  The kernel
people ignored that when I raised that up, so I lost my hopes.