Values of WCHAN in ps
What does the WCHAN (waiting channel) mean exactly? what can be its value and what those values represents? I tried to find them but got nothing.
Solution 1:
From man ps
, section Standard Format Specifiers
:
nwchan WCHAN address of the kernel function where the process
is sleeping (use wchan if you want the kernel
function name). Running tasks will display a
dash ('-') in this column.
wchan WCHAN name of the kernel function in which the process
is sleeping, a "-" if the process is running, or
a "*" if the process is multi-threaded and ps is
not displaying threads.
As can be seen, they are the kernel functions currently being used by the process. Further:
-n namelist
Set namelist file. Identical to N. The namelist file is needed
for a proper WCHAN display, and must match the current Linux
kernel exactly for correct output. Without this option, the
default search path for the namelist is:
$PS_SYSMAP
$PS_SYSTEM_MAP
/proc/*/wchan
/boot/System.map-$(uname -r)
/boot/System.map
/lib/modules/$(uname -r)/System.map
/usr/src/linux/System.map
/System.map
You can inspect /boot/System.map-$(uname -r)
on Ubuntu for a list of functions:
$ sudo head /boot/System.map-$(uname -r)
0000000000000000 D __per_cpu_start
0000000000000000 D irq_stack_union
0000000000000000 A xen_irq_disable_direct_reloc
0000000000000000 A xen_save_fl_direct_reloc
00000000000001e0 A kexec_control_code_size
0000000000004000 d exception_stacks
0000000000009000 D gdt_page
000000000000a000 D espfix_waddr
000000000000a008 D espfix_stack
000000000000a020 D cpu_info
Solution 2:
Note that this answer is mostly obsolete: you should never need a namelist or System.map
anymore. ps
in procps-ng
reads /proc/${pid}/wchan
directly, instead of reading the 30th field (wchan) out of /proc/${pid}/stat
and decoding it against a symbol map file.
In fact, some kernels may set the wchan field of /proc/${pid}/stat
to 1 instead of a real value in order to hide the details of kernel address space layout randomization.
(I'm hitting some odd issues with wchan on Fedora 32 though, see fedora bug 1879450).