Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 176570 - symlinks pointing to /tmp/prelink files on running system
Summary: symlinks pointing to /tmp/prelink files on running system
Alias: None
Product: Fedora
Classification: Fedora
Component: prelink
Version: 5
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
Reported: 2005-12-26 18:54 UTC by Jim Cornette
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-06 03:52:47 UTC

Attachments (Terms of Use)

Description Jim Cornette 2005-12-26 18:54:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051215 Fedora/1.7.12-3

Description of problem:
When launching a program, ppcracer in his case, I ended up getting a permission error for a library that was actually a symlink to a /tmp/prelink<random> file.
There were several prelink files left in the /temp directory which were there for at least several days.
Refer to the thread link described for current suggestions.
During shutdown issue, prelink should exit cleanly. does SIGKILL after 5 seconds cause a problem?

Also, is /tmp a good location for prelink to do its temporary storage or should a location under /var/cache/ be used instead?

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

How reproducible:

Steps to Reproduce:
1. shutdown system
2. launch certain application on system after an hour or so life to system.
3. get error permission denied  referring to library.

Actual Results:  It shuts down
The application refers to permission denied on a library. The link to the library is a symlink to a prelink file in /tmp

Expected Results:  system should finish processes or cache information and resume prelinking on reboot.

Additional info:

stated in thread on fedora test list

Comment 1 Jim Cornette 2005-12-30 04:23:42 UTC
There is still an ongoing problem with symlinks pointing to #prelink# files.
These files are not under /tmp as what happened with the library where it was
needed for me to re-install the packages.

 locate '#prelink#'

were the files left over on my system. These files linked to the symlink that is
setup normally to point to the major library with the minor versioning number.

The excerpt below was linked to /usr/lib/
instead of how I edited the symlink after removing the #prelink# versiion with a
different date but same filesize.

 ls -la /usr/lib/*
lrwxrwxrwx 1 root root     19 Dec 29 23:10 /usr/lib/ ->
-rwxr-xr-x 1 root root 289240 Dec 27 17:14 /usr/lib/

Comment 2 Jakub Jelinek 2006-01-03 07:44:35 UTC
ldconfig in glibc-2.3.90-23 and abov has been changed to ignore prelink
temporaries.  I'll also write a prelink SIGTERM handler, though if you unplug
the cord or kill -9 prelink, prelink temporaries might still be left around.

Comment 3 Jim Cornette 2006-01-06 12:05:19 UTC
I am not getting libs symlinked to /tmp lately. I still get these files in lib
and the lib without the #prelink# is in the directory also.


 locate '#prelink#'
[jim@cornette-lt ~]$ cd /usr/lib
[jim@cornette-lt lib]$ ls -laZ *#prelink#*
-rwx------  root     root     system_u:object_r:textrel_shlib_t
-rwx------  root     root     system_u:object_r:textrel_shlib_t
-rwx------  root     root     system_u:object_r:textrel_shlib_t
-rwx------  root     root     system_u:object_r:textrel_shlib_t
-rwx------  root     root     system_u:object_r:textrel_shlib_t
-rwx------  root     root     system_u:object_r:textrel_shlib_t
-rwx------  root     root     system_u:object_r:textrel_shlib_t

Comment 4 Jim Cornette 2006-02-06 03:52:47 UTC
I have not deteced any errors with libraries linked to files in /tmp or with
files with #prelink# as part of the file name. Thanks! I feel the problem is
resolved with changes.

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