LinuxQuestions.org - Locking up: could multiple installed versions of same package be culprit?

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - Locking up: could multiple installed versions of same package be culprit? (https://www.linuxquestions.org/questions/linux-software-2/locking-up-could-multiple-installed-versions-of-same-package-be-culprit-519867/)

Locking up: could multiple installed versions of same package be culprit?

Hi all. I'm trying to track down random lockups on a dell poweredge 2650 running RHEL4, and in addition to many other things I'm comparing the packages this system has with another similar system that does not have these lockup issues. I inherited this system so I don't know its history, but I'm finding many packages installed with different versions of the same package. See below (taken from rpm -qa).

Is it generally okay to have multiple versions of the same package installed? If I find out what files were installed with the package, can I use "find" to tell me if they've been accessed recently? Is that a robust way to determine whether an RPM has been used recently or is there a better way to see if package X version Y is still being used by something? This is a production system so I can't experiment much (e.g., uninstall them and see what happens).

apr-0.9.4-24.1
apr-0.9.4-24.5

apr-util-0.9.4-17
apr-util-0.9.4-21

dump-0.4b37-1
dump-0.4b39-3.EL4.2

fetchmail-6.2.5-6
fetchmail-6.2.5-6.el4.2

glibc-kernheaders-2.4-9.1.87
glibc-kernheaders-2.4-9.1.98.EL

gnome-desktop-devel-2.8.0-3
gnome-desktop-devel-2.8.0-5

gnome-terminal-2.7.3-1
gnome-terminal-2.7.3-2

grub-0.95-3.1
grub-0.95-3.5

indexhtml-4.1-1
indexhtml-4-2

j2sdk-1.4.1_01-fcs
j2sdk-1.4.2_08-fcs

java-1.4.2-gcj-compat-1.4.2.0-26jpp
java-1.4.2-gcj-compat-1.4.2.0-27jpp

kernel-2.6.9-22.0.1.EL
kernel-2.6.9-22.EL

kernel-devel-2.6.9-22.0.1.EL
kernel-devel-2.6.9-22.EL

kernel-smp-2.6.9-22.0.1.EL
kernel-smp-2.6.9-22.EL

kernel-smp-devel-2.6.9-22.0.1.EL
kernel-smp-devel-2.6.9-22.EL

kudzu-1.1.95.15-1
kudzu-1.1.95.8-1

kudzu-devel-1.1.95.15-1
kudzu-devel-1.1.95.8-1

libpcap-0.8.3-10.RHEL4
libpcap-0.8.3-7

libtool-1.5.6-4
libtool-1.5.6-4.EL4.1

logrotate-3.7.1-2
logrotate-3.7.1-5.RHEL4

logwatch-5.2.2-1
logwatch-5.2.2-1.EL4.1

metacity-2.8.6-2.1
metacity-2.8.6-2.8

mikmod-3.1.6-30.1
mikmod-3.1.6-32.EL4

nasm-0.98.38-3
nasm-0.98.38-3.EL4

pam_krb5-2.1.2-1
pam_krb5-2.1.8-1

pango-1.6.0-7
pango-1.6.0-9

pango-devel-1.6.0-7
pango-devel-1.6.0-9

redhat-artwork-0.120.1-1.2E
redhat-artwork-0.120-1.1E

redhat-logos-1.1.25-1
redhat-logos-1.1.26-1

redhat-lsb-1.3-5.2
redhat-lsb-3.0-8.EL

rusers-0.17-41
rusers-0.17-41.40.1

setup-2.5.37-1.1
setup-2.5.37-1.3

subversion-1.1.1-2.1
subversion-1.1.4-2.ent

sudo-1.6.7p5-30.1
sudo-1.6.7p5-30.1.3

system-config-securitylevel-1.4.19.1-1
system-config-securitylevel-1.4.19.2-1

system-config-securitylevel-tui-1.4.19.1-1
system-config-securitylevel-tui-1.4.19.2-1

tcpdump-3.8.2-10.RHEL4
tcpdump-3.8.2-7

telnet-0.17-30
telnet-0.17-31.EL4.3

telnet-server-0.17-30
telnet-server-0.17-31.EL4.3

ttmkfdir-3.0.9-14
ttmkfdir-3.0.9-14.1.EL

vim-minimal-6.3.046-0.40E.4
vim-minimal-6.3.046-0.40E.7

xinetd-2.3.13-4
xinetd-2.3.13-4.4E.1

xorg-x11-deprecated-libs-6.8.2-1.EL.13.37.5
xorg-x11-deprecated-libs-devel-6.8.2-1.EL.13.37.5

zlib-1.2.1.2-1
zlib-1.2.1.2-1.2

zlib-devel-1.2.1.2-1
zlib-devel-1.2.1.2-1.2

zsh-4.2.0-3
zsh-4.2.0-3.EL.3

I'm trying to track down random lockups
Does this occur as long as you have the box?
Anything anomalous in any logs? With verbosity turned up?
Can you get a fix on the interval? If not, after aprox what period of time?
Any SAR data (atop, dstat) to check for ramping up memory, I/O etc, etc?

another similar system that does not have these lockup issues.
Exact same HW?

I inherited this system so I don't know its history
OK, what *do* you know about the box?

Is it generally okay to have multiple versions of the same package installed?
Depends on what your POV is. If it's about standarisation, minimising of risk, maintenance time then I'd say less is more, except for kernels (and stuff you can't avoid for legacy reasons). In your list I don't see any packages I know would conflict though.

Is that a robust way to determine whether an RPM has been used recently or is there a better way to see if package X version Y is still being used by something?If I find out what files were installed with the package, can I use "find" to tell me if they've been accessed recently?

Code:

# Say you want to find out about /bin/ls:

]$ rpm -q --whatprovides --qf="%{name}\n" /bin/ls

coreutils

# ...so package coreutils requires:

]$ rpm -q --whatrequires --qf="%{name}\n" coreutils

devlabel

prelink

# now the access times of the dependent devlabel package sorted by date:

rpm -ql devlabel | xargs -iF stat -c '%N %x' 'F'| column -t | sort -rk2

This is a production system so I can't experiment much (e.g., uninstall them and see what happens).
No testbed available? Can't swap in a spare?

Quote:

Does this occur as long as you have the box?

Yes

Quote:

Anything anomalous in any logs?

Quote:

With verbosity turned up?

Verbosity is on max, still nothing.

Quote:

Can you get a fix on the interval? If not, after aprox what period of time?

No regular periodicity. It's locked-up 12 hours after reboot, and 37 days after reboot.

Quote:

Any SAR data (atop, dstat) to check for ramping up memory, I/O etc, etc?

sar/vmstat show no peaks right before the lockup. The box is not under any heavy load when it locks-up. No routine jobs (cron, etc.) running when it locks up.

Quote:

Exact same HW?

Same hardware specs (exact same HW would be the same box).

Quote:

OK, what *do* you know about the box?

A bit

Quote:

In your list I don't see any packages I know would conflict though.

Thanks

Quote:

No testbed available? Can't swap in a spare?

No and no, however I replaced the system board, riser card/DRAC and raid controller last night to see if anything changes.

Thanks for the code to track RPM usage, I appreciate it.