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
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):
Or, switch to a different cron daemon that integrates the anacron
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.
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.
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.
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.
I still don't see any conflict-avoidance with rpm in place, but I haven't seen
this problem lately.
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:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
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?
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.