Is there a command like pstree for libraries?

Posted on

Is there a command like pstree for libraries? – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.

But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about linux, rhel5, , , .

I need to determine whether a library named libunaSA.so is being called directly by the process or by another library called libtoki2.so. I guess what I’m looking for is a pstree for libraries. The system is running RHEL 5.3 Beta.

This output shows the two libraries in the process map

# grep -e toki -e una /proc/2335/maps
0043f000-004ad000 r-xp 00000000 08:02 543465     /usr/lib/libtoki2.so
004ad000-004c5000 rwxp 0006d000 08:02 543465     /usr/lib/libtoki2.so
01185000-01397000 r-xp 00000000 08:02 543503     /usr/lib/libunaSA.so
01397000-013dc000 rwxp 00211000 08:02 543503     /usr/lib/libunaSA.so

This output shows that only the libtoki2.so library is in the current cache

# ldconfig -p | grep -e una -e toki
libtoki2.so (libc6) => /usr/lib/libtoki2.so
libtoki.so.4.4.1 (libc6) => /usr/lib/libtoki.so.4.4.1
libtoki.so.2 (libc6) => /usr/lib/libtoki.so.2

I attached strace to the running process but it doesn’t provide much output

# strace -p 2335
Process 2335 attached - interrupt to quit
futex(0xb7ef5bd8, FUTEX_WAIT, 2336, NULL

Here’s the output to ldd for each library

# ldd /usr/lib/libtoki2.so
        linux-gate.so.1 =>  (0x00a0a000)
        libdl.so.2 => /lib/libdl.so.2 (0x001bd000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x00f3f000)
        libm.so.6 => /lib/libm.so.6 (0x00b27000)
        libc.so.6 => /lib/libc.so.6 (0x0043d000)
        /lib/ld-linux.so.2 (0x00742000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00110000)
# ldd /usr/lib/libunaSA.so
        linux-gate.so.1 =>  (0x00244000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00baf000)
        libdl.so.2 => /lib/libdl.so.2 (0x007fa000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x009ce000)
        libm.so.6 => /lib/libm.so.6 (0x00c96000)
        libc.so.6 => /lib/libc.so.6 (0x004a2000)
        /lib/ld-linux.so.2 (0x00742000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a9f000)

Solution :

Everything you posted suggests that libunaSA.so stands alone. libtoki2.so does not require libunaSA (as shown by ldd). You could try using ltrace or lsof against the running application to see if libunaSA is called; if libtoki2 makes the call, then it will be hidden (I believe) from the output of ltrace.

lsof will show if the binary requires libunaSA at all.

Both ltrace and lsof are available for RHEL 5.

Leave a Reply

Your email address will not be published.