Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lsof -b may still cause kernel blocks #181

Open
propertone opened this issue Dec 8, 2021 · 3 comments
Open

lsof -b may still cause kernel blocks #181

propertone opened this issue Dec 8, 2021 · 3 comments

Comments

@propertone
Copy link

[Linux] I'm not sure if this is a bug, but lsof -b does not entirely avoid blocking calls. While it avoid stat/lstat/readlink calls on the mounted filesystems, strace shows that it still calls lstat and stat on the file descriptor symlinks in /proc/*/fd/*. Unlike lstat, stat will resolve symlinks, so if the open file handle is on a filesystem that's hung, then lsof will hang as well, even with the -b option.

I've tested this on Linux using the latest version of lsof

@masatake
Copy link
Contributor

masatake commented Dec 8, 2021

If your strace supports -k option, could you run the strace command with the option, so I can find in which context, the systems calls are called.

@propertone
Copy link
Author

Here's a sample strace lsof invocation:

[/var/tmp/lsof_4.94.0.linux] % strace -k -o /tmp/strace.out -estat,lstat ./lsof -b -w -i:80

...
stat("/proc/10577/", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
 > /usr/lib64/libc-2.17.so(__xstat+0x15) [0xef465]
 > /var/tmp/lsof_4.94.0.linux/lsof(gather_proc_info+0x2c1) [0x407fd1]
 > /var/tmp/lsof_4.94.0.linux/lsof(main+0x1c45) [0x415ffc]
 > /usr/lib64/libc-2.17.so(__libc_start_main+0xf4) [0x22554]
 > /var/tmp/lsof_4.94.0.linux/lsof(_start+0x28) [0x402408]
lstat("/proc/10577/fd/0", {st_mode=S_IFLNK|0300, st_size=64, ...}) = 0
 > /usr/lib64/libc-2.17.so(__lxstat+0x15) [0xef505]
 > /var/tmp/lsof_4.94.0.linux/lsof(process_id+0x14e8) [0x407519]
 > /var/tmp/lsof_4.94.0.linux/lsof(gather_proc_info+0x64c) [0x40835c]
 > /var/tmp/lsof_4.94.0.linux/lsof(main+0x1c45) [0x415ffc]
 > /usr/lib64/libc-2.17.so(__libc_start_main+0xf4) [0x22554]
 > /var/tmp/lsof_4.94.0.linux/lsof(_start+0x28) [0x402408]
stat("/proc/10577/fd/0", {st_mode=S_IFREG|0600, st_size=1573, ...}) = 0
 > /usr/lib64/libc-2.17.so(__xstat+0x15) [0xef465]
 > /var/tmp/lsof_4.94.0.linux/lsof(process_id+0x151c) [0x40754d]
 > /var/tmp/lsof_4.94.0.linux/lsof(gather_proc_info+0x64c) [0x40835c]
 > /var/tmp/lsof_4.94.0.linux/lsof(main+0x1c45) [0x415ffc]
 > /usr/lib64/libc-2.17.so(__libc_start_main+0xf4) [0x22554]
 > /var/tmp/lsof_4.94.0.linux/lsof(_start+0x28) [0x402408]
lstat("/proc/10577/fd/1", {st_mode=S_IFLNK|0300, st_size=64, ...}) = 0
 > /usr/lib64/libc-2.17.so(__lxstat+0x15) [0xef505]
 > /var/tmp/lsof_4.94.0.linux/lsof(process_id+0x14e8) [0x407519]
 > /var/tmp/lsof_4.94.0.linux/lsof(gather_proc_info+0x64c) [0x40835c]
 > /var/tmp/lsof_4.94.0.linux/lsof(main+0x1c45) [0x415ffc]
 > /usr/lib64/libc-2.17.so(__libc_start_main+0xf4) [0x22554]
 > /var/tmp/lsof_4.94.0.linux/lsof(_start+0x28) [0x402408]
stat("/proc/10577/fd/1", {st_mode=S_IFREG|0600, st_size=1573, ...}) = 0
 > /usr/lib64/libc-2.17.so(__xstat+0x15) [0xef465]
 > /var/tmp/lsof_4.94.0.linux/lsof(process_id+0x151c) [0x40754d]
 > /var/tmp/lsof_4.94.0.linux/lsof(gather_proc_info+0x64c) [0x40835c]
 > /var/tmp/lsof_4.94.0.linux/lsof(main+0x1c45) [0x415ffc]
 > /usr/lib64/libc-2.17.so(__libc_start_main+0xf4) [0x22554]
 > /var/tmp/lsof_4.94.0.linux/lsof(_start+0x28) [0x402408]
...

@masatake
Copy link
Contributor

masatake commented Dec 9, 2021

Thank you. I read gather_proc_info and process_id.
In my understanding, calling these system calls in the context is needed. lsof on Linux doesn't work at all without calling the system calls in the context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants