|Summary:||Prelink temp. freezes complete system and causes high system load for 16 minutes every day|
|Product:||[Fedora] Fedora||Reporter:||Mathijs Tieleman <mathijs>|
|Component:||prelink||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||0.3.2-10||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-10-27 08:59:42 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 /var/log/prelink.log). 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 slow. 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): prelink-0.3.2-1 How reproducible: Always 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 logfile. 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 libs. (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 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 & top 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
Hi, 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 report. [root@mydell etc]# cat /tmp/prelink.time real 2m17.929s user 0m6.452s sys 0m4.909s + Done ( time /etc/cron.daily/prelink ) 2>/tmp/prelink.time
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.