LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 12-04-2017, 04:20 AM   #1
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 8,701

Rep: Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886
Library curiosity


I noticed some orphaned libs lying around and wondered are they leftovers from previous updates. This is the problem
Code:
ls -l /lib64/ld-2.??.so
-rwxr-xr-x 1 root root 162193 May  9  2014 /lib64/ld-2.19.so
-rwxr-xr-x 1 root root 179104 Aug  9 21:17 /lib64/ld-2.23.so
-rwxr-xr-x 1 root root 186920 Aug  4 01:21 /lib64/ld-2.26.so
This grep produces no results
Code:
grep -e '/lib64/ld-2.19.so' -e '/lib64/ld-2.23.so' -e '/lib64/ld-2.26.so' /var/log/packages/*
And this indicates only one is in use
Code:
bash-4.3$ ls -l /lib64/ld*
-rwxr-xr-x 1 root root 162193 May  9  2014 /lib64/ld-2.19.so
-rwxr-xr-x 1 root root 179104 Aug  9 21:17 /lib64/ld-2.23.so
-rwxr-xr-x 1 root root 186920 Aug  4 01:21 /lib64/ld-2.26.so
lrwxrwxrwx 1 root root     10 Oct  9 16:39 /lib64/ld-linux-x86-64.so.2 -> ld-2.26.so
lrwxrwxrwx 1 root root     27 Feb  1  2017 /lib64/ld-lsb-x86-64.so.3 -> /lib64/ld-linux-x86-64.so.2
They look important. Why are they in no package, and can I delete ld-2.19.so and 2.23.so without the sky falling in?
 
Old 12-04-2017, 05:22 AM   #2
heyjann
Member
 
Registered: Dec 2015
Posts: 72

Rep: Reputation: Disabled
If you remove the path from the search, you will find something:

Code:
grep -e 'ld-2.26.so' /var/log/packages/*
You will see that the package has it as lib64/incoming/ld-2.26.so which only later gets moved to lib64/ by doinst.sh

I am speculating that glibc-related libraries are not the simplest upgrade because the old versions have to keep working as long as possible while they are being upgraded (crucial system libraries), so the new ones get put into place as late as possible (?)

Not sure if it is to be expected or easily explained that old versions are left behind. I suppose you could delete them, but to be 100% sure I would first rename them to f.ex. ld-2.19.TO_BE_REMOVED, wait a while to see if that breaks anything, and only then delete them.

Possibly of interest:
https://www.linuxquestions.org/quest...encies-794133/
 
1 members found this post helpful.
Old 12-04-2017, 05:24 AM   #3
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 607

Rep: Reputation: 430Reputation: 430Reputation: 430Reputation: 430Reputation: 430
Quote:
Originally Posted by business_kid View Post
[/CODE] This grep produces no results
Code:
grep -e '/lib64/ld-2.19.so' -e '/lib64/ld-2.23.so' -e '/lib64/ld-2.26.so' /var/log/packages/*
Package listings only relative paths, so you'd need to drop the '/' prefix.
You shouldn't see any the older versions in the presently installed packages, unless you have both glibc- and glibc-solibs packages installed, and didn't keep them in sync (upgradepkg'ing them in unison).


Quote:
They look important. Why are they in no package, and can I delete ld-2.19.so and 2.23.so without the sky falling in?
They are important. Even though nothing may require those old versions explicitly, there may be running processes still using them.

Code:
lsof | egrep 'DEL.*(libc)' | sort | uniq | less
If you find any still using old libraries, you can restart the service and it'll use the new glibc library.
This is a necessary to do this for any library upgrade that contains a security fix, otherwise you may leave a service open that is exploitable due to it using an old copy of a library in RAM.

The old library files remain on the system because the library files within the package archive are contained within a staging directory, and are moved in to the final place by the package's install script. The package tools don't support removing files from a staging directory, so they remain on the file system to be cleaned manually.

Last edited by drmozes; 12-04-2017 at 05:26 AM.
 
Old 12-04-2017, 08:49 AM   #4
Petri Kaukasoina
Member
 
Registered: Mar 2007
Posts: 270

Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by business_kid View Post
I noticed some orphaned libs lying around and wondered are they leftovers from previous updates.
Try:

Code:
ls -l /lib64/*-2.19.so /lib64/*-2.23.so
 
Old 12-04-2017, 11:30 AM   #5
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 8,701

Original Poster
Rep: Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886
Quote:
Originally Posted by Petri Kaukasoina View Post
Try:

Code:
ls -l /lib64/*-2.19.so /lib64/*-2.23.so
That hit the Jackpot!
Code:
bash-4.3$ ls -lh /lib64/*-2.19.so /lib64/*2.23.so
-rwxr-xr-x 1 root root 159K May  9  2014 /lib64/ld-2.19.so
-rwxr-xr-x 1 root root 175K Aug  9 21:17 /lib64/ld-2.23.so
-rwxr-xr-x 1 root root 8.1K May  9  2014 /lib64/libBrokenLocale-2.19.so
-rwxr-xr-x 1 root root 8.1K Aug  9 21:17 /lib64/libBrokenLocale-2.23.so
-rwxr-xr-x 1 root root  19K May  9  2014 /lib64/libanl-2.19.so
-rwxr-xr-x 1 root root  20K Aug  9 21:17 /lib64/libanl-2.23.so
-rwxr-xr-x 1 root root 2.0M May  9  2014 /lib64/libc-2.19.so
-rwxr-xr-x 1 root root 2.0M Aug  9 21:17 /lib64/libc-2.23.so
-rwxr-xr-x 1 root root 197K May  9  2014 /lib64/libcidn-2.19.so
-rwxr-xr-x 1 root root 192K Aug  9 21:17 /lib64/libcidn-2.23.so
-rwxr-xr-x 1 root root  48K May  9  2014 /lib64/libcrypt-2.19.so
-rwxr-xr-x 1 root root  44K Aug  9 21:17 /lib64/libcrypt-2.23.so
-rwxr-xr-x 1 root root  19K May  9  2014 /lib64/libdl-2.19.so
-rwxr-xr-x 1 root root  19K Aug  9 21:17 /lib64/libdl-2.23.so
-rwxr-xr-x 1 root root 1.1M May  9  2014 /lib64/libm-2.19.so
-rwxr-xr-x 1 root root 1.1M Aug  9 21:17 /lib64/libm-2.23.so
-rwxr-xr-x 1 root root 172K Aug  9 21:17 /lib64/libmvec-2.23.so
-rwxr-xr-x 1 root root 114K May  9  2014 /lib64/libnsl-2.19.so
-rwxr-xr-x 1 root root 112K Aug  9 21:17 /lib64/libnsl-2.23.so
-rwxr-xr-x 1 root root  45K May  9  2014 /lib64/libnss_compat-2.19.so
-rwxr-xr-x 1 root root  41K Aug  9 21:17 /lib64/libnss_compat-2.23.so
-rwxr-xr-x 1 root root  37K May  9  2014 /lib64/libnss_db-2.19.so
-rwxr-xr-x 1 root root  37K Aug  9 21:17 /lib64/libnss_db-2.23.so
-rwxr-xr-x 1 root root  27K May  9  2014 /lib64/libnss_dns-2.19.so
-rwxr-xr-x 1 root root  31K Aug  9 21:17 /lib64/libnss_dns-2.23.so
-rwxr-xr-x 1 root root  56K May  9  2014 /lib64/libnss_files-2.19.so
-rwxr-xr-x 1 root root  55K Aug  9 21:17 /lib64/libnss_files-2.23.so
-rwxr-xr-x 1 root root  28K May  9  2014 /lib64/libnss_hesiod-2.19.so
-rwxr-xr-x 1 root root  27K Aug  9 21:17 /lib64/libnss_hesiod-2.23.so
-rwxr-xr-x 1 root root  55K May  9  2014 /lib64/libnss_nis-2.19.so
-rwxr-xr-x 1 root root  55K Aug  9 21:17 /lib64/libnss_nis-2.23.so
-rwxr-xr-x 1 root root  64K May  9  2014 /lib64/libnss_nisplus-2.19.so
-rwxr-xr-x 1 root root  64K Aug  9 21:17 /lib64/libnss_nisplus-2.23.so
-rwxr-xr-x 1 root root 139K May  9  2014 /lib64/libpthread-2.19.so
-rwxr-xr-x 1 root root 133K Aug  9 21:17 /lib64/libpthread-2.23.so
-rwxr-xr-x 1 root root 112K May  9  2014 /lib64/libresolv-2.19.so
-rwxr-xr-x 1 root root 111K Aug  9 21:17 /lib64/libresolv-2.23.so
-rwxr-xr-x 1 root root  42K May  9  2014 /lib64/librt-2.19.so
-rwxr-xr-x 1 root root  42K Aug  9 21:17 /lib64/librt-2.23.so
-rwxr-xr-x 1 root root  14K May  9  2014 /lib64/libutil-2.19.so
-rwxr-xr-x 1 root root  14K Aug  9 21:17 /lib64/libutil-2.23.so
bash-4.3$
It appears I have glibc-solibs-2.23.so in the packages, which accounts for many of them
Code:
bash-4.3$ ls -lh glibc-solibs*
-rw-r--r-- 1 root root 8.4K Oct  4 10:11 glibc-solibs-2.23-x86_64-4_slack14.2
-rw-r--r-- 1 root root  16K Oct  9 16:39 glibc-solibs-2.26_multilib-x86_64-1alien
To confuse things further, I went hunting
Code:
bash-4.3$ cd /lib64
bash-4.3$ ls ld-2.??.so
ld-2.19.so  ld-2.23.so	ld-2.26.so
bash-4.3$ file ld-2.??.so
ld-2.19.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
ld-2.23.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
ld-2.26.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
bash-4.3$ cd /lib
bash-4.3$ ls ld-2.??.so
ld-2.26.so
bash-4.3$
So I have no package to match /lib64/ld-2.26.so; No package to match ld-2.19.so. At a guess, these are leftovers from a failed upgrade attempt. I ended up with files on disc with no matching package, packages with no matching files(!) and the finger is firmly pointed at slackpkg. I thought I had got myself out of that, but apparently not :-(.
 
Old 12-04-2017, 01:06 PM   #6
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,881

Rep: Reputation: 563Reputation: 563Reputation: 563Reputation: 563Reputation: 563Reputation: 563
You have to look in the doinst.sh for the link-creation lines. The package db file only lists dirs and files.
 
Old 12-04-2017, 02:03 PM   #7
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 8,701

Original Poster
Rep: Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886
@gnashley: Thanks, but in Slackware, a lot of those were real libs, not links

Everything investigated, It seems that glibs-solibs when updated puts everything that finishes in /lib64 in /lib64/incoming, leaves the old ones there, and copies in the new AS WELL. That looks like a bug in the packages. From /var/log/packages/glibc-solibs-2.26-x86_64-3
Code:
lib64/incoming/
lib64/incoming/ld-2.26.so
lib64/incoming/libBrokenLocale-2.26.so
lib64/incoming/libanl-2.26.so
lib64/incoming/libc-2.26.so
lib64/incoming/libcidn-2.26.so
lib64/incoming/libcrypt-2.26.so
lib64/incoming/libdl-2.26.so
lib64/incoming/libm-2.26.so
lib64/incoming/libmemusage.so
lib64/incoming/libmvec-2.26.so
lib64/incoming/libnsl-2.26.so
lib64/incoming/libnss_compat-2.26.so
lib64/incoming/libnss_db-2.26.so
lib64/incoming/libnss_dns-2.26.so
lib64/incoming/libnss_files-2.26.so
lib64/incoming/libnss_hesiod-2.26.so
lib64/incoming/libnss_nis-2.26.so
lib64/incoming/libnss_nisplus-2.26.so
lib64/incoming/libpcprofile.so
lib64/incoming/libpthread-2.26.so
lib64/incoming/libresolv-2.26.so
lib64/incoming/librt-2.26.so
lib64/incoming/libthread_db-1.0.so
lib64/incoming/libutil-2.26.so
glibc-solibs-2.19 wasn't in Slackware 14.1 and may have been in current at some stage, but I found glibc-2.23 in Slackware-14.2, installed it (for the package file), then upgraded it to 2.26. I ran around the $PATH with this command for 2.19 & 2.23
Code:
ldd * |grep 2.19.so
ldd * |grep 2.23.so
and nothing was directly linked to them. Having a backup and an install dvd, I took the brave step
Code:
cd /lib64
find -name '*2.19.so' -delete
find -name '*2.23.so' -delete
and the sky hasn't fallen in. The other directory glibc-solibs writes to is /usr/lib64/gconv, but that behaves ok. Everything is overwritten.
 
Old 12-04-2017, 02:25 PM   #8
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,544

Rep: Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494
Quote:
Originally Posted by business_kid View Post
It appears I have glibc-solibs-2.23.so in the packages, which accounts for many of them
Code:
bash-4.3$ ls -lh glibc-solibs*
-rw-r--r-- 1 root root 8.4K Oct  4 10:11 glibc-solibs-2.23-x86_64-4_slack14.2
-rw-r--r-- 1 root root  16K Oct  9 16:39 glibc-solibs-2.26_multilib-x86_64-1alien
Not sure if I missed you mentioning this, but these are mismatched versions. You have the multilib version higher than the regular version. I don't know how problematic that might be.
 
1 members found this post helpful.
Old 12-04-2017, 03:50 PM   #9
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 8,701

Original Poster
Rep: Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886Reputation: 886
No, I didn't miss that, but I teetotally missed something else. Upgradepkg on the glibc-solibs-2.23 also managed to wipe glibc-solibs-2.26_multilib-x86_64-4alien! I've put in glibc-solibs-2.23_multilib-x86_64-4alien until I get back on and pick up glibc-solibs-2.26 multilib from somewhere. It's late in the day now, and I'm not bothered. It will probably be in the multilib stuff for current.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Just out of curiosity... y2kvirus Linux - Hardware 1 07-26-2015 11:48 AM
[SOLVED] Curiosity has gotten the best of me. Dafydd Linux - General 2 07-16-2013 09:25 PM
Curiosity cthomas Linux - Software 2 01-24-2007 10:40 AM
out of curiosity elamigo2004 Linux - Software 1 04-17-2004 04:39 PM
out of curiosity aizkorri General 5 12-15-2003 11:16 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:24 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration