Bug 1079775

Summary:	error while loading shared libraries
Product:	[Fedora] Fedora	Reporter:	sangu <sangu.fedora>
Component:	tracker	Assignee:	Deji Akingunola <dakingun>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	dakingun, debarshir, kalevlember
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-03-24 13:00:27 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description sangu 2014-03-24 01:18:34 UTC

Description of problem:
$ tracker-preferences 
tracker-preferences: error while loading shared libraries: libtracker-common.so.0: cannot open shared object file: No such file or directory

$ rpm -ql tracker|grep common
/usr/lib64/tracker-1.0/libtracker-common.so.0
/usr/lib64/tracker-1.0/libtracker-common.so.0.0.0


Version-Release number of selected component (if applicable):
0.17.8-3.fc21.x86_64

How reproducible:
always

Steps to Reproduce:
1. 
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 sangu 2014-03-24 01:59:40 UTC

$ /usr/libexec/tracker-miner-fs 
/usr/libexec/tracker-miner-fs: error while loading shared libraries: libtracker-extract.so.0: cannot open shared object file: No such file or directory

$ tracker-control 
tracker-control: error while loading shared libraries: libtracker-data.so.0: cannot open shared object file: No such file or directory

Comment 2 Kalev Lember 2014-03-24 11:17:04 UTC

Does running /sbin/ldconfig as root fix this?

Comment 3 Kalev Lember 2014-03-24 11:37:17 UTC

What is the output of 'ls -l /usr/lib64/tracker-1.0/libtracker-data.so.0' and 'rpm -V tracker' ?

Comment 4 sangu 2014-03-24 13:00:27 UTC

tracker-0.17.5.2 -> updating to 0.17.8-3
Error while loading shared libraries
# /sbin/ldconfig

$ tracker-control 
tracker-control: error while loading shared libraries: libtracker-data.so.0: cannot open shared object file: No such file or directory
$ rpm -V tracker
....L....    /usr/lib64/tracker-1.0/libtracker-common.so.0
....L....    /usr/lib64/tracker-1.0/libtracker-data.so.0
....L....    /usr/lib64/tracker-1.0/libtracker-extract.so.0


Downloading to 0.17.8-1 in koji -> updating to 0.17.8-3

Fixed!

Strange :(

Comment 5 Kalev Lember 2014-03-24 13:32:45 UTC

I am unsure how the ld.so cache exactly works, but my working theory is that it has something to do with the rebuilding of ld.so cache during the updates. Looking at the 'rpm -V' output you posted, it looks like broken so.0 symlinks in the private directory.

During the upgrade, what happens is:

1) The old package has /etc/ld.so.conf.d/tracker-x86_64.conf installed
2) New package is installed, /etc/ld.so.conf.d/tracker-x86_64.conf stays in place
3) New package's %post runs ldconfig
4) Old package is removed, removing /etc/ld.so.conf.d/tracker-x86_64.conf

And this somehow trashes the private .so.0 symlinks.

I think a workaround would be to add back /etc/ld.so.conf.d/tracker-x86_64.conf, but as an empty file. This should make sure ldconfig no longer considers the private directory when the new package's %post runs.

Comment 6 Kalev Lember 2014-03-24 13:46:37 UTC

I've added it back as an empty file in http://pkgs.fedoraproject.org/cgit/tracker.git/commit/?id=b0ffed261f53b2cd3586e71b89366d408904da2a. This workaround should only be needed for tracker 0.17.x -> 0.17.x / 0.18.x updates so we don't need to keep it in place for long. 0.16.x updates are unaffected because the private dir changed in the mean time.