-1

We migrated an app, changed its name in Makefile from flex_camera to flex_camera_lucid.

After deploying it to the target board(the original app is removed), as shown in the following screenshot, we get 3 different names of one process! But why?

For the original app flex_camera, we can find it by ps -e or pgrep. But for the migrated app, neither ps -e | grep flex_camera_lucid nor pgrep flex_camera_lucid works. So, why?

Finally,what are the determinations of the name of a process in Linux ?

Makefile:

TARGETS = flex_camera_lucid #... .PHONY: default default: $(TARGETS) $(TARGETS): $(OBJS) $(LD) $(LDFLAGS) -o $@ $^ $(LDLIBS)

Linux console screenshot: enter image description here

Improve this question
3
  • 3
    How do you mean "three"? ps prints you one name, flex_camera_luc. Now, of course flex_camera happens to be a substring of the former, and both grep and pgrep by default match on substrings too. Why it shows flex_camera_luc and not flex_camera_lucid is interesting, but it's likely just a 15 char limit [citation needed]. Commented Jun 20 at 8:36
  • Three names are flex_camera, flex_camera_luc and flex_camera_lucid. ps -e will show matched characters in bold font, but it ouputs none. Commented Jun 20 at 8:59
  • Right, you've left out the part where the full flex_camera_lucid would be showing, sigh. Commented Jun 20 at 10:03

1 Answer 1

Reset to default
4

Without the -f option pgrep attempts to match the pattern argument against the process name in /proc/pid/comm. As per man proc_pid_comm the comm file has a maximum length 1:

Strings longer than TASK_COMM_LEN (16) characters (including the terminating null byte) are silently truncated.

On a Ubuntu 24.04.2 LTS system with pgrep from procps-ng 4.0.4 attempting to use a pattern with a string longer than 15 characters reports the following helpful message (as well as no matches):

$ pgrep gnome-terminal-server pgrep: pattern that searches for process name longer than 15 characters will result in zero matches Try `pgrep -f' option to match against the complete command line.

Whereas using the -f option produces a match:

$ pgrep -f gnome-terminal-server 8814

This is the truncated name that pgrep searches for without the -f option:

$ cat /proc/8814/comm gnome-terminal-

And this the complete command line searched when the -f option is used:

$ cat /proc/8814/cmdline /usr/libexec/gnome-terminal-server

1 On a 6.8.0-60-generic Kernel I noticed that Kernel threads can have a comm file with more than 15 characters, which pgrep can then find with the full name without needing to use -f. E.g.:

mr_halfword@Haswell-Ubuntu:~$ cat /proc/7741/comm kworker/u25:1-flush-8:0 mr_halfword@Haswell-Ubuntu:~$ pgrep kworker/u25:1-flush-8:0 7741

I haven't investigated why Kernel threads don't have their name limited by TASK_COMM_LEN in the same way as user space processes.

Improve this answer
2
  • 1
    perhaps more to the point, pgrep matches on substrings too, unless you use -x/--exact Commented Jun 20 at 8:39
  • Yep. -f works. All issues are caused by TASK_COMM_LEN defined in sched.h in linux kernel. That's for the task or thread. But what's exactly the process name should be in Linux? Commented Jun 20 at 9:49

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.