lib_users can not find libs that has bin replaced with openvz-sources-2.6.32.76.5 Reproducible: Always Steps to Reproduce: 1. # emerge -uNDa world Actual Results: # lib_users #
Created attachment 349468 [details] emerge --info
Created attachment 349470 [details] qlop -l
I don't see what you mean. lib_users is not supposed to check whether your kernel is outdated.
I use lib_users on systems with hardened-sources kernel and gentoo-sources kernel. And after update a world, lib_users was always could find processes with a replaced libs. On system with OpenVZ kernel lib_users can't find this processes after update a world.
What do proc/[0-9]*/maps entries look like with such a kernel?
Created attachment 349480 [details] ls -1 /proc/[0-9]*/maps
Comment on attachment 349480 [details] ls -1 /proc/[0-9]*/maps I meant the contents of a maps file, preferably one for which you have just updated a library, in order to get a "(deleted)" entry (or not).
This is a maps file after update openvpn 2.3.0 up to 2.3.1 # cat /proc/23547/maps 00400000-0048f000 r-xp 00000000 fd:00 16245 (deleted)/var/tmp/portage/net-misc/openvpn-2.3.1/image/usr/sbin/openvpn 0068e000-0068f000 r--p 0008e000 fd:00 16245 (deleted)/var/tmp/portage/net-misc/openvpn-2.3.1/image/usr/sbin/openvpn 0068f000-00690000 rw-p 0008f000 fd:00 16245 (deleted)/var/tmp/portage/net-misc/openvpn-2.3.1/image/usr/sbin/openvpn 01130000-01172000 rw-p 00000000 00:00 0 01172000-012de000 rw-p 00000000 00:00 0 7fc5ee936000-7fc5ee94b000 r-xp 00000000 fd:00 377366 /lib64/libz.so.1.2.7 7fc5ee94b000-7fc5eeb4a000 ---p 00015000 fd:00 377366 /lib64/libz.so.1.2.7 7fc5eeb4a000-7fc5eeb4b000 r--p 00014000 fd:00 377366 /lib64/libz.so.1.2.7 7fc5eeb4b000-7fc5eeb4c000 rw-p 00015000 fd:00 377366 /lib64/libz.so.1.2.7 7fc5eeb4c000-7fc5eece6000 r-xp 00000000 fd:00 12856 (deleted)/var/tmp/portage/sys-libs/glibc-2.15-r3/image/lib64/libc-2.15.so 7fc5eece6000-7fc5eeee6000 ---p 0019a000 fd:00 12856 (deleted)/var/tmp/portage/sys-libs/glibc-2.15-r3/image/lib64/libc-2.15.so 7fc5eeee6000-7fc5eeeea000 r--p 0019a000 fd:00 12856 (deleted)/var/tmp/portage/sys-libs/glibc-2.15-r3/image/lib64/libc-2.15.so 7fc5eeeea000-7fc5eeeec000 rw-p 0019e000 fd:00 12856 (deleted)/var/tmp/portage/sys-libs/glibc-2.15-r3/image/lib64/libc-2.15.so 7fc5eeeec000-7fc5eeef0000 rw-p 00000000 00:00 0 7fc5eeef0000-7fc5eeef2000 r-xp 00000000 fd:00 12840 (deleted)/var/tmp/portage/sys-libs/glibc-2.15-r3/image/lib64/libdl-2.15.so 7fc5eeef2000-7fc5ef0f2000 ---p 00002000 fd:00 12840 (deleted)/var/tmp/portage/sys-libs/glibc-2.15-r3/image/lib64/libdl-2.15.so 7fc5ef0f2000-7fc5ef0f3000 r--p 00002000 fd:00 12840 (deleted)/var/tmp/portage/sys-libs/glibc-2.15-r3/image/lib64/libdl-2.15.so 7fc5ef0f3000-7fc5ef0f4000 rw-p 00003000 fd:00 12840 (deleted)/var/tmp/portage/sys-libs/glibc-2.15-r3/image/lib64/libdl-2.15.so 7fc5ef0f4000-7fc5ef2a0000 r-xp 00000000 fd:00 264853 /usr/lib64/libcrypto.so.1.0.0 7fc5ef2a0000-7fc5ef49f000 ---p 001ac000 fd:00 264853 /usr/lib64/libcrypto.so.1.0.0 7fc5ef49f000-7fc5ef4ba000 r--p 001ab000 fd:00 264853 /usr/lib64/libcrypto.so.1.0.0 7fc5ef4ba000-7fc5ef4c5000 rw-p 001c6000 fd:00 264853 /usr/lib64/libcrypto.so.1.0.0 7fc5ef4c5000-7fc5ef4c9000 rw-p 00000000 00:00 0 7fc5ef4c9000-7fc5ef528000 r-xp 00000000 fd:00 263359 /usr/lib64/libssl.so.1.0.0 7fc5ef528000-7fc5ef728000 ---p 0005f000 fd:00 263359 /usr/lib64/libssl.so.1.0.0 7fc5ef728000-7fc5ef72c000 r--p 0005f000 fd:00 263359 /usr/lib64/libssl.so.1.0.0 7fc5ef72c000-7fc5ef732000 rw-p 00063000 fd:00 263359 /usr/lib64/libssl.so.1.0.0 7fc5ef732000-7fc5ef733000 rw-p 00000000 00:00 0 7fc5ef733000-7fc5ef754000 r-xp 00000000 fd:00 16554 (deleted)/var/tmp/portage/dev-libs/lzo-2.06/image/usr/lib64/liblzo2.so.2.0.0 7fc5ef754000-7fc5ef953000 ---p 00021000 fd:00 16554 (deleted)/var/tmp/portage/dev-libs/lzo-2.06/image/usr/lib64/liblzo2.so.2.0.0 7fc5ef953000-7fc5ef954000 r--p 00020000 fd:00 16554 (deleted)/var/tmp/portage/dev-libs/lzo-2.06/image/usr/lib64/liblzo2.so.2.0.0 7fc5ef954000-7fc5ef955000 rw-p 00021000 fd:00 16554 (deleted)/var/tmp/portage/dev-libs/lzo-2.06/image/usr/lib64/liblzo2.so.2.0.0 7fc5ef955000-7fc5ef977000 r-xp 00000000 fd:00 12847 (deleted)/var/tmp/portage/sys-libs/glibc-2.15-r3/image/lib64/ld-2.15.so 7fc5efb1f000-7fc5efb65000 rw-p 00000000 00:00 0 7fc5efb75000-7fc5efb76000 rw-p 00000000 00:00 0 7fc5efb76000-7fc5efb77000 r--p 00021000 fd:00 12847 (deleted)/var/tmp/portage/sys-libs/glibc-2.15-r3/image/lib64/ld-2.15.so 7fc5efb77000-7fc5efb78000 rw-p 00022000 fd:00 12847 (deleted)/var/tmp/portage/sys-libs/glibc-2.15-r3/image/lib64/ld-2.15.so 7fc5efb78000-7fc5efb79000 rw-p 00000000 00:00 0 7fff7fe83000-7fff7fe98000 rw-p 00000000 00:00 0 [stack] 7fff7ff39000-7fff7ff3b000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Ah, that explains it: /usr/bin/lib_users:34: if line.endswith("(deleted)"):
Can you provide such a file as an attachment? Bugzilla tends to mess up whitespace, especially linebreaks and tabs. Fixing lib_user to work with OpenVZ kernels requires a good example, though.
Created attachment 349648 [details] openvz maps file
How weird. Is it documented why it writes maps files that way?
I found a lot of changes in the openvz-sources patch related to proc/PID/maps entries. I would consider the way they change that a bug in itself.
I've added code to handle this to the version of lib_users in the git repo (commit 068ebec053af0ef970eaccbe8470a11f665adf3d). Can you check out that version from http://git.schwarzvogel.de/?p=lib_users;a=summary like so: $ git clone http://git.schwarzvogel.de/repos/lib_users $ cd lib_user $ git checkout 068ebec053af0ef970eaccbe8470a11f665adf3d And then test to your heart's content? Thanks!
With python2 works fine! This error with python 3: # eselect python set python3.2 # ./lib_users.py Traceback (most recent call last): File "./lib_users.py", line 163, in <module> main() File "./lib_users.py", line 144, in main print(fmt_human(users)) File "./lib_users.py", line 79, in fmt_human for argv, pidslibs in lib_users.iteritems(): AttributeError: 'collections.defaultdict' object has no attribute 'iteritems'
(In reply to Alexandr Tiurin from comment #15) > With python2 works fine! Great, I'll make a new release, then. > This error with python 3: > > # eselect python set python3.2 > # ./lib_users.py > Traceback (most recent call last): > File "./lib_users.py", line 163, in <module> > main() > File "./lib_users.py", line 144, in main > print(fmt_human(users)) > File "./lib_users.py", line 79, in fmt_human > for argv, pidslibs in lib_users.iteritems(): > AttributeError: 'collections.defaultdict' object has no attribute 'iteritems' This I've already fixed. I'll cut v0.6 now and make a release. Should be in portage in a few hours.
Thanks all! P.S. IMHO, Integration lib_users with portage (as emerge option) would be a good feature.
(In reply to Alexandr Tiurin from comment #17) > Thanks all! > > P.S. IMHO, Integration lib_users with portage (as emerge option) would be a > good feature. The portage people are welcome to integrate lib_users with it. Since I have use for it outside of Gentoo, I'll keep maintaining it as a standalone program either way.
