Hi does anyone know what the problem here is
[root@dnstest lib]# ps
ps: error while loading shared libraries: libproc-3.2.3.so: cannot open shared object file: No such file or directory
[root@dnstest lib]# ln -s libproc-3.2.7.so libproc-3.2.3.so
[root@dnstest lib]# ps
ps: /lib/libproc-3.2.3.so: version `_3_1_14' not found (required by ps)
as far as I know only ps is giving me this error.
CentOS release 5.3 (Final)
P.A wrote:
Hi does anyone know what the problem here is
[root@dnstest lib]# ps
ps: error while loading shared libraries: libproc-3.2.3.so: cannot open shared object file: No such file or directory
rpm -qf $(which ps) rpm -V procps
[root@dnstest lib]# ln -s libproc-3.2.7.so libproc-3.2.3.so
[root@dnstest lib]# ps
ps: /lib/libproc-3.2.3.so: version `_3_1_14' not found (required by ps)
Why should that work?
as far as I know only ps is giving me this error.
ps --version
CentOS release 5.3 (Final)
Was that a CentOS 4 machine in an earlier life?
Ralph
On Thu, Apr 30, 2009, P.A wrote:
Hi does anyone know what the problem here is
[root@dnstest lib]# ps
ps: error while loading shared libraries: libproc-3.2.3.so: cannot open shared object file: No such file or directory
When programs like ps, sed, find, etc. start showing shared library problems, it is usually an indication that the box has been partially cracked. I say partially since the cracker will install/replace versions of /bin/ps et al with ones that are built for another version of Linux.
As other have noted, ``rpm -V'' is usually useful to detect changed files.
Frequently crackers put their programs under /tmp, /var/tmp, or the /dev directories with directory names such as ``.. '' that are not easily seen. They try to install versions of find, ps, netstat, etc. that are designed to hide their processes.
If you have a good system to monitor changes on *ALL* critical files and directories, and can identify changed, added, or deleted files, it is possible to restore a cracked system without a complete reinstall. Otherwise the only safe method is to take the system off line, do a fresh install, and try to figure out how the system was cracked.
Bill
Bill, good point but I looked and don't think that is what happened. This box is not in production and has a private ip. I took care of the ps issue by reinstalling procps-3.2.7-11.1.el5.i386. The RPM issue was fix by reinstalling the rpm package.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Bill Campbell Sent: Thursday, April 30, 2009 12:54 PM To: centos@centos.org Subject: Re: [CentOS] ps error
On Thu, Apr 30, 2009, P.A wrote:
Hi does anyone know what the problem here is
[root@dnstest lib]# ps
ps: error while loading shared libraries: libproc-3.2.3.so: cannot open shared object file: No such file or directory
When programs like ps, sed, find, etc. start showing shared library problems, it is usually an indication that the box has been partially cracked. I say partially since the cracker will install/replace versions of /bin/ps et al with ones that are built for another version of Linux.
As other have noted, ``rpm -V'' is usually useful to detect changed files.
Frequently crackers put their programs under /tmp, /var/tmp, or the /dev directories with directory names such as ``.. '' that are not easily seen. They try to install versions of find, ps, netstat, etc. that are designed to hide their processes.
If you have a good system to monitor changes on *ALL* critical files and directories, and can identify changed, added, or deleted files, it is possible to restore a cracked system without a complete reinstall. Otherwise the only safe method is to take the system off line, do a fresh install, and try to figure out how the system was cracked.
Bill
-
Bill Campbell -
P.A -
Ralph Angenendt