The utility lsof is a very useful utility, and can be used to list the shared libraries being used by a running process. It can be important to know if a running process is using a particular library, perhaps for forensics reasons or for library upgrades.
To list all the libraries in a particular process, try this command:
lsof -a -c name +D /usr/lib
This will list all files used by name in /usr/lib. To list all files used by name, just use:
lsof -c name
Alternately, to find all processes using a file (library) in /usr/lib, use this command:
lsof /usr/lib/libname
The -c option specifies the beginning of a name of a process to list. The -a option is used to create a boolean AND set; otherwise, lsof assumes a boolean OR set of options. With the +D option (which scans for files recursively down the directory tree), the first example looks for the process name that also has open files from the /usr/lib directory tree.
Another good use of lsof has to do with finding files that are open but deleted. Such a situation could potentially happen with a shared library if the library was deleted while a file was using it. This could perhaps happen during a library upgrade. Use this command to do this:
lsof +L1
The +L option specifies files with a specific number of links; here, any file with less than one link (that is, zero links) will be listed. Files with zero links are not listed in the filesystem but are open and in use by a file. The blocks from such files remain marked as in use by the filesystem, but the file cannot be found by name anywhere and has no inode.
There is a nice concise article by Joe Barr at Linux.com about what you can do with lsof. Lsof is available for download.
UNIX Administratosphere 
Interesting that you should post this. A couple weeks ago I was asked to see if a shared library was really being shared or if a new copy was being opened. I immediately used lsof but had difficulty convincing the developer that the library was being shared as he intended. He felt a new copy was being opened and it was not being shared as he intended. Here was the output.
lsof /product/patch11/lib/librc.slCOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
LM01 29895 tuxcycl1 mem REG 64,0x10003 155779072 295456 /product/patch11/lib/librc.sl
LM02 29898 tuxcycl1 mem REG 64,0x10003 155779072 295456 /product/patch11/lib/librc.sl
LM03 29902 tuxcycl1 mem REG 64,0x10003 155779072 295456 /product/patch11/lib/librc.sl
LM04 29905 tuxcycl1 mem REG 64,0x10003 155779072 295456 /product/patch11/lib/librc.sl
LM05 29908 tuxcycl1 mem REG 64,0x10003 155779072 295456 /product/patch11/lib/librc.sl
I am sorry if this is vague. I was just looking for more information on what I am seeing here and what your thoughts might be. Thanks in advance.
According to your output, the library is loaded into each command, LM0[1-5], and all are in memory. It doesn’t give a lot of information as to whether the library is shared among all or just with each one.
You may wish to try the ipcs command with the -mp options.
I’m not sure how a library would wind up being “shared” in the way you describe; the system loader as I understand it will load a shared library for each executable.
To truly “share” a library, I would contend it would be necessary to create a separate program (with separate process space) that used a shared memory segment to share data or functions some how.
Here is an example output of ipcs -mp:
# ipcs -mp
IPC status from /dev/kmem as of Tue Nov 13 23:06:59 2007
T ID KEY MODE OWNER GROUP CPID LPID
Shared Memory:
m 0 0x411c016d --rw-rw-rw- root root 791 791
m 1 0x4e0c0002 --rw-rw-rw- root root 791 793
m 2 0x41202f4c --rw-rw-rw- root root 791 793
m 3 0x06347849 --rw-rw-rw- root root 1573 1599
m 327684 0x0c6629c9 --rw-r----- root root 1589 1578
m 32773 0x49185e65 --rw-r--r-- root root 1578 1599
m 1310726 0x00a5c581 --rw------- sfmdb users 1769 1772
Does this help any?
Your explanation helped me understand this subject a great deal better. We were using ipcs as well. My understanding of shared libraries was vague but I thought it worked as you explained here. Thanks again for the further explanation.
This is a great post by the way. This is the type of system administration subjects I like seeing tackled on a blog.