Command, args and process name

Question

I learned recently of pidof, and I was comparing it to pgrep. While doing that, I noticed that pidof returned several PIDs for Firefox, while pgrep returned just one.

I checked pgrep's man page and experimented with its toggles, and got the expected output with -f:

   -f, --full
          The pattern is normally only matched against the process name.  
          When -f is set, the full command line is used.

Now, I knew of ps making distinctions between the full path to a command, 'simple' command name (like basename on the fullpath) and the full args, but I had never heard of process names.

In the case below, all the other processes are children of 4661, so I'm guessing Firefox forked them to take advantage of multiprocessing.

The questions, then:

• What are process names?
• How and why do processes set them?

Looking at these posts, it seems that it may or may not be done by changing argv[0] or calling prctl(PR_SET_NAME), and that it is used simply to help on debugging, identifying which subprocess is doing what (or, sometimes, to fool the user thinking a process is something else).

Is that so? Or are process names something in addition to argv?

$ pidof firefox
5495 5463 5391 5384 5380 5351 5330 5311 5239 5184 4661
$ pgrep firefox
4661
$ pgrep -f firefox
4661
5184
5239
5311
5330
5351
5380
5384
5391
5463
5495
$ pgrep -fl firefox
4661 firefox
5184 Web Content
5239 Web Content
5311 Web Content
5330 Web Content
5351 Web Content
5380 Web Content
5384 Web Content
5391 Web Content
5463 Privileged Cont
5495 WebExtensions
$ 

Answer 1

Most of the exec functions receive at least two arguments, where the first is the the path to the executable and the second is the list of arguments. That list includes argv[0], so the programmer always has the option to change it. That's what bash does for exec -a new_name. So, the parent of a process can define argv[0] while still pointing to the expected executable.

Firefox, from the original question, changes the process name by calling prctl (PR_SET_NAME,...). According to prctl(2), it sets the name of the thread:

This is the same attribute that can be set via pthread_setname_np(3) and retrieved using pthread_getname_np(3). The attribute is likewise accessible via /proc/self/task/[tid]/comm (see proc(5)), where [tid] is the thread ID of the calling thread, as returned by gettid(2).

As for reason of doing that, the code has the following comment:

// Update the process name so about:memory's process names are more obvious.

man 5 proc is very helpful here: for cmdline, it explains that the program can change it in a couple of ways, and defines the file as 'Think of this file as the command line that the process wants you to see'. comm is defined as 'the command name associated with the process', and it also explains how it can be changed.

So, there are at least two ways of 'changing process name', and each will make pidof and pgrep (and actually, other tools) work differently:

• The argv[0] method changes the process' argv at process start or later, and affects /proc/PID/cmdline
• The prctl (PR_SET_NAME,...) actually changes the name of the main thread of the process, and affects both /proc/PID/comm and /proc/PID/task/PID/comm

What	argv[0]	prctl (PR_SET_NAME,...)
pidof	Original and new	Original only
pgrep	Original only	New only
pgrep -f	New only	Original only
ps -o comm	Original	New
ps -o cmd	New	Original

pidof, ps, top and pgrep are apparently all on the procps-ng project.

pidof checks both the cmdline and the link on /proc/PID/exe to the actual binary, so it works for both original and new on the argv[0] method, but only original for the other method.

Conclusion

What the pgrep man page calls process names is /proc/PID/comm. That is not necessarily the same name as argv[0], which is stored on /proc/PID/cmdline, and both of these can be changed independently in a variety of ways.

The main uses for that functionality are, apparently, for debugging and ease of maintenance.