Red Hat Bugzilla – Bug 129499
Prelink temp. freezes complete system and causes high system load for 16 minutes every day
Last modified: 2007-11-30 17:10:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Description of problem:
The daily cron runs prelink every day with -av -mR (as I found in the
When it runs the cron job, it freezes the complete system (not even
the mouse works) for 15 seconds, 3 times. I tried, but cannot trace
what causes this freeze.
At my laptop (DELL 5150, 3 Ghz), it takes every daily run, at 16
minutes to complete the full run. It doesn't (never) start prelink
with the -q option.
During the freeze, my processor fan is running at high speed, which is
probably normally caused when it is running at 100%.
During almost the complete run, my harddisk runs at full speed,
slowing down the computer by 50% or more, because every read/write to
the harddisk from other programs is terribly slow.
It looks like it has something to do with "Cannot prelink against
non-PIC shared library /usr/lib/libGL.so.1.0.6106". This is a NVIDIA
lib, which comes from the NVIDIA driver from their website. If I look
at the logfile (tail -f) during prelink runs, it takes 30 seconds or
more and a lot of proccessor power when it shows the line above.
I need this non-GPL lib as part of my videodriver. The standard kernel
does not have all openGL etc. options available, which makes the video
The same is for: Could not prelink /usr/bin/wineclipsrv because its
dependency /usr/local/lib/libwine_unicode.so.1 could not be prelinked
This comes from the standard wine RPM.
And this: /usr/lib/opera/7.50-20040422.1/opera: Not enough room to add
This is from the opera webbrowser.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install the NVIDIA Linux video driver from the www.nvidia.com site
2. Start the prelink script from the daily cron directory
Actual Results: 3 times a system freeze for 15 seconds and a very
high system load during the rest of the 16 minutes.
Expected Results: Running prelink, without me knowing it.
That's weird. Even on my 650MHz/256MB FC2 P3 -q finishes within
a few seconds and without -q (e.g. when I remove /var/lib/misc/prelink.full)
it lasts just above 2 minutes.
On FC2 there aren't that many libraries linked against libGL.so.1
(on my box 53 screen savers and 10 other programs), so eventhough
prelink retries them every time (as libGL.so.1 makes them not prelinkable),
it shouldn't take that much time and shouldn't eat too much memory.
So, I wonder, does the prelink process actually finish successfully
for you (this can be checked if /etc/prelink.cache file has been written).
Does your /var/log/prelink.log end with
Prelink failed with return value NN ?
Created attachment 102582 [details]
This is my logfile from yesterday. There are no errors at the end of the
But the libGL shown in the logfile, is the NVIDIA version and not the Fedora
version. So prob. it has something to do with the way NVIDIA compiles their
(See the complete bug info I sent about the NVIDIA driver)
Created attachment 102583 [details]
Prelink cache file (/etc)
This is the cache file.
Created attachment 102584 [details]
Hopefully this information is usefull.
So, you are clearly using -q, so if it doesn't take just a few seconds,
something is very wrong.
( time /etc/cron.daily/prelink ) 2>/tmp/prelink.time &
and in top watch if its memory usage doesn't go too high
(similarly if it is eating substantial amount of time)?
Then cat /tmp/prelink.time?
Are all the directories mentioned in /etc/prelink.conf on local filesystems?
Yes, all files are on the local file system, it's my laptop :-).
Below the results. Top doesn't show that prelink is consuming a lot of
memory. Not at all.
This run shows a different behaviour. It is still slow (2 minutes) but
much faster than yesterday. I updated my Fedora core (via the rhn
applet/tool, the previous update I did was from last week), the
difference is that the logfile shows a lot of mozilla libs which could
not be found (new mozilla via the updates). These checks are 95% of
those 2 minutes running prelink. The libGL.so.1.6106's are now done in
But, it took seconds before/after it found out a file doesn't exist
any longer. Rerunning prelink again shows that those libs does not
exists. I'll start a full prelink run and will add the results to this
[root@mydell etc]# cat /tmp/prelink.time
+ Done ( time /etc/cron.daily/prelink )
Created attachment 102589 [details]
prelink logfile, full run
I removed the prelink.full file and ran prelink. This shows a 5 minutes run, no
high processor load, only a very, very active harddisk, mostly during the files
for which it says that he cannot find them.
I've seen prelink eating up my processor & harddisk for weeks, and now it
behaves differently. I'll add the up2date logfile as well.
[root@mydell misc]# cat /tmp/prelink.time
Created attachment 102590 [details]
Logfile with the updates from Fedora. After the updates it shows mozilla libs
which can't be found during which the prelink processing time is huge per lib,
but the libGL from nvidia lines are really fast now.
Since 0.3.2-10 prelink caches information about unprelinkable files,
so even if you have many unprelinkable programs prelink -q should now