top and ps truncate command after 15 chars

[Lethe]

Binary package hint: procps

I guess this is an issue with 'top', and not really Ubuntu related, but...

I noticed something hogging my CPU, and top revealed:

15219 root 30 10 109m 104m 4092 R 92 5.2 1:44.15 update-apt-xapi

Of course, there is no such process called 'update-apt-xapi'.

top truncates the process name to 15 chars (this was in fact 'update-apt-xapian-index' running).

Nick

[karl michael (karlzt)]

happened to me on intrepid

[Robert Roth (evfool)]

This happens with ps too, and it is really strange.

[周成瑞 (e93b5ae3)]

This is due to the fact that some procedures of procs get the command name from /proc/<pid>/stat but not from /proc/<pid>/cmdline. As far as I know, ps and pgrep also have this bug. For example, 'ps -e' ( non-BSD stlye output) gives truncated commannd names. But if you have BSD options, you get full command name, e.g. ps x (this includes command line arguments though). With pgrep, you can only provide truncated command name as its arguments as said in its man page.

These behaviors are confusing if you do not know what the source code really does. I do not see the truncated command name advantage when the kernel provide full command name.

This is an upstream bug. Please report it to the upstream author and link the report here. Thanks.

[Alexandru Zbarcea (zbarcea-a)]

How come is undecided?

"ps" doesn't work as expected! This is a HUGE bug. I will switch to other distro ONLY for this BUG.

[Ciprian Ciubotariu (cheepeero)]

By the way, this also affects killall (for whoever writes scripts).

[kapetr (kapetr)]

A had report probably a duplicate of this, but take a look at my report - about the man page X reality:

 https://bugs.launchpad.net/ubuntu/+source/procps/+bug/976034

Ubuntu 12.04.1 64b

Why is this old Bug still not in Progress ? :-/

[Dominique Poulain (dominique-poulain)]

Confirmed on latest Xenial for top, `ps -e` and pgrep:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu Xenial Xerus (development branch)
Release: 16.04
Codename: xenial

$ python3 -c 'print(len("chromium-browser"))'
16
$ pgrep chromium-browser
echo $?
1 # exit status code 1 == no processes matched (as per man page for pgrep(1))
$ pgrep chromium-browse
22351
22364
[snip]

$ cat /proc/22351/cmdline && echo
chromium-browser --enable-pinch
$ cat /proc/22351/stat
22351 (chromium-browse) S 1616 1829 1829 0 -1 4194560 37820 20451 701 0 657 236 6 2 20 0 29 0 355501 1262727168 41021 18446744073709551615 94135085649920 94135125690420 140723151897424 140723151896160 140132228684269 0 0 4096 81923 0 0 0 17 2 0 0 64 0 0 94135127791120 94135129570812 94135143915520 140723151902368 140723151902426 140723151902426 140723151904717

$ ps -e | grep chromium
22351 ? 00:00:08 chromium-browse
22364 ? 00:00:00 chromium-browse
22366 ? 00:00:00 chromium-browse
22464 ? 00:00:02 chromium-browse
22469 ? 00:00:00 chromium-browse
22557 ? 00:00:00 chromium-browse
$ top -b -n 1 -p 22351
[snip]
22351 foo 20 0 1233132 164084 118164 S 0,0 1,0 0:08.85 chromium-browse

related to LP #1174911 'pgrep cuts process names' <https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1174911>

[PabloAB (pabloab777)]

The reason is in kernel TASK_COMM_LEN (check man proc) constant fixed to 16 (name + \0). A guy called [Luben Tuikov][0] proposed to increase this back on 2006 ([last lines][1] of sys.c). Even if this is too difficult because of mysterous complicated reasons pgrep should search on the complete name, not the truncated version (/proc/PID/comm, /proc/PID/status | grep ^Name).

Maybe something like grep -hoa "\/[^/]*$" /proc/*/cmdline | grep -a pattern [or][2] ps aux | grep "[p]attern".

With -f "the full command line is used" (/proc/PID/cmdline, readlink /proc/PID/exe). This is too broad.

Something similar happen with the 4096 B limit of PAGE_SIZE. In that case the solution is easy, [just recompile the kernel][3] with a new value... :s

[0](http://lkml.iu.edu/hypermail/linux/kernel/0606.2/3139.html)
[1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/sys.c#n2544)
[2](https://unix.stackexchange.com/a/74186/209677)
[3](https://stackoverflow.com/a/199199/4970442)