Bug 132230 - prelink could use some locking
prelink could use some locking
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: prelink (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
bzcl34nup
:
Depends On:
Blocks: 1366045
  Show dependency treegraph
 
Reported: 2004-09-09 21:18 EDT by Alexandre Oliva
Modified: 2016-09-05 16:35 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-05 03:26:50 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 Alexandre Oliva 2004-09-09 21:18:07 EDT
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-09 22:02:45 EDT
Or, switch to a different cron daemon that integrates the anacron
functionality. :)
Comment 2 Alexandre Oliva 2004-09-09 23:43:58 EDT
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 05:19:43 EDT
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 17:06:08 EDT
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 18:30:23 EDT
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-07-31 23:46:30 EDT
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 11:38:44 EDT
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 03:10:13 EDT
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 03:26:50 EDT
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.

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