System calls to get a process from Linux and parameters (troubleshooting cases) _linux Shell

When a program fails, there are times when you want to troubleshoot problems by understanding the system tuning that the process is executing. You can usually use Strace to track. But Strace is no help when the process is already in the D state (uninterruptible sleep). This is the time to pass

Copy Code code as follows:

Cat/proc/<pid>/syscall

To get the current system call and parameters.


Here is an example of a recent problem. The problem is that a server is stuck when it executes pvcreate to create a physical volume, and the process status is D

Copy Code code as follows:

# PS Aux|grep pvcreate
Root 8443 0.0 0.0 27096 2152? D Apr04 0:00 Pvcreate/dev/sddlmac
...

The D state is actually waiting for the system call to return. So let's see what the system call is waiting for.

Copy Code code as follows:

b0313010:~ # Cat/proc/8443/syscall
0 0x7 0x70f000 0x1000 0x0 0x7f33e1532e80 0x7f33e1532ed8 0x7fff3a6b8718 0x7f33e128cf00

The first number is the system call number, followed by the parameter. The number of parameters required for different system calls is different. The number of fields here is based on the maximum number of parameters, so it is not necessarily worth each parameter segment. So how do you know the system call number corresponds to which system call? is defined in the header file/usr/include/asm/unistd_64.h. You can also use a little foot to quickly find:

Copy Code code as follows:

#!/bin/bash
# Usage:whichsyscall <syscall_nr>
Nr= "$"
File= "/usr/include/asm/unistd_64.h"
Gawk ' $1== "#define" && $3== "' $nr '" {Sub ("^__nr_", "", $);p rint $} ' $file '

For different system call parameters, you can use the Man 2 < system call Name > Lookup. As Man 2 read. For just that example, 0 corresponds to the read call. The first parameter of the read invocation is a file descriptor.

And then use Lsof to find out what file 7 corresponds to.

Copy Code code as follows:

# lsof-p 8443
COMMAND PID USER FD TYPE DEVICE size/off NODE NAME
......
Pvcreate 8443 root 5u CHR 10,236 0t0 19499/dev/mapper/control
Pvcreate 8443 root 6u BLK 253,1 0t8192 36340797/dev/dm-1
Pvcreate 8443 root 7u BLK 253,5 0t0 35667968/dev/dm-5

It turned out to be a device mapper device file. Finally, we found that this file was created by MULTIPATHD. The system should use the Multipath software provided by the storage vendor. The problem is due to the simultaneous opening of the MULTIPATHD cause of the conflict.

/proc/<pid>/syscall is useful for troubleshooting D-state processes. But in the 2.6.18 kernel does not support, specifically from which kernel version began to have this function, has not been found. However, at least from the 2.6.32 version is supported.