Bug 129499

Summary: Prelink temp. freezes complete system and causes high system load for 16 minutes every day
Product: [Fedora] Fedora Reporter: Mathijs Tieleman <mathijs>
Component: prelinkAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: 0.3.2-10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-27 08:59:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Prelink logfile
Prelink cache file (/etc)
prelink logfile, full run
up2date logfile none

Description Mathijs Tieleman 2004-08-09 19:48:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040626 Firefox/0.9.1

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
.dynamic entry

This is from the opera webbrowser.

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

How reproducible:

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.

Additional info:

Comment 1 Jakub Jelinek 2004-08-10 16:30:14 UTC
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 ?

Comment 2 Mathijs Tieleman 2004-08-10 17:23:57 UTC
Created attachment 102582 [details]
Prelink logfile

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)

Comment 3 Mathijs Tieleman 2004-08-10 17:25:28 UTC
Created attachment 102583 [details]
Prelink cache file (/etc)

This is the cache file.

Comment 4 Mathijs Tieleman 2004-08-10 17:27:28 UTC
Created attachment 102584 [details]

Comment 5 Mathijs Tieleman 2004-08-10 17:30:54 UTC
Hopefully this information is usefull.

Comment 6 Jakub Jelinek 2004-08-10 17:34:19 UTC
So, you are clearly using -q, so if it doesn't take just a few seconds,
something is very wrong.
Can you:
( 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?

Comment 7 Mathijs Tieleman 2004-08-10 18:04:48 UTC

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
just seconds. 

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
real    2m17.929s
user    0m6.452s
sys     0m4.909s
[1]+  Done                    ( time /etc/cron.daily/prelink )

Comment 8 Mathijs Tieleman 2004-08-10 18:23:03 UTC
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
real	5m30.893s
user	0m7.667s
sys	0m8.436s
[root@mydell misc]#

Comment 9 Mathijs Tieleman 2004-08-10 18:25:41 UTC
Created attachment 102590 [details]
up2date logfile

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.

Comment 10 Jakub Jelinek 2004-10-27 08:59:42 UTC
Since 0.3.2-10 prelink caches information about unprelinkable files,
so even if you have many unprelinkable programs prelink -q should now
be faster.