-1

If the command ps awx | grep -v grep is run the following output is produced. The list below is the last 20 lines of the complete output. 

 4247 pts/1    Ss+    0:00 /bin/bash
 4442 ?        S<     0:00 [kworker/u17:1]
 4661 ?        S<     0:00 [kworker/u17:3]
 4731 ?        S<     0:00 [kworker/u17:5]
 4734 ?        S      0:00 pickup -l -t fifo -u
 4847 ?        S<     0:00 [kworker/u17:7]
 4850 ?        S      0:00 [kworker/u16:3]
 4878 ?        S      0:00 [kworker/u16:0]
 5201 ?        S<     0:00 [kworker/u17:8]
 5353 ?        S      0:00 [kworker/0:1]
 5354 ?        S      0:00 [kworker/7:2]
 5355 ?        S      0:00 [kworker/u16:2]
 5361 ?        S      0:00 [kworker/4:0]
 5362 tty1     Ss     0:00 -bash
 5396 ?        S      0:00 [kworker/6:0]
 5418 ?        S      0:00 [kworker/0:0]
 5420 ?        S      0:00 [kworker/2:2]
 5431 ?        S      0:00 [kworker/7:0]
 5562 ?        S      0:00 [kworker/4:2]
 5620 tty1     R+     0:00 ps awx

If a subsequent command ps awx | grep grep is run the following output is generated.

5646 tty1     S+     0:00 grep --color=auto grep

Additionally if the following command ps awx | grep agetty is run, the following output is displayed.

5669 tty1     S+     0:00 grep --color=auto agetty

Why does the command ps awx not display the process identification numbers 5646 and 5669? In fact there are no other processes listed after 5620.

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
Motivated
  • 309
  • Show the complete list of ps awx. From the initial looks 5646 is not even there in your given information – Inian Jan 28 '19 at 05:28
  • @Inian OP already mentioned 5646 showed up in subsequent command, so it's a new process and couldn't have been in the original (or complete list) of ps awx in the first place – Sergiy Kolodyazhnyy Jan 28 '19 at 05:32
  • @Motivated Let me make sure before I write an answer: are you asking why there is no 5647, 5648, 5649...and so on ? Is that correct ? – Sergiy Kolodyazhnyy Jan 28 '19 at 05:35
  • @SergiyKolodyazhnyy - That is correct. I also updated the preceding command in the question. – Motivated Jan 28 '19 at 05:35
  • @Motivated So I've posted an answer, and I think it's fairly solid, though let me know if anything is unclear there or something needs to be added. And hope it clarifies a thing or two. – Sergiy Kolodyazhnyy Jan 28 '19 at 05:53
  • It would be useful & valuable understand the downvote. – Motivated Jan 28 '19 at 15:51

2 Answers2

2

Processes can come and go within microseconds via fork(), both inside kernel and outside. In fact, to quote Michael Foukarakis:

The reason for PIDs not appearing sequential in user space is because kernel scheduling might fork a process in between your process' fork() calls. It's very common, in fact.

So between ps awx | grep -v grep and ps awx | grep grep a lot of things happened. There were new processes and threads - they just exited before ps could capture them. The same logic occurs in your ps awx | grep grep and last example. But also note that grep PID may not in fact be newest, because as Gilles in related answer points out:

[p]iped commands run concurrently. When you run ps | grep …, it's the luck of the draw (or a matter of details of the workings of the shell combined with scheduler fine-tuning deep in the bowels of the kernel) as to whether ps or grep starts first, and in any case they continue to execute concurrently.

Note also that grep -v grep is intended to remove itself from ps output (and generally it is actually recommended to use | grep -v [g]rep in such case, see related post ).

Sergiy Kolodyazhnyy
  • 16,527
  • Do you mean to say that each time i run ps awx for example, the output could differ? Additionally, what do you mean by 'inside the kernel and outside`? – Motivated Jan 28 '19 at 05:52
  • 1
    @Motivated Yes, each time you run ps awx the difference in time between when you run the commands can be seconds (depending on how fast you type). But processes come and co within microseconds or nanoseconds. As for the other question, there's two notions: userspace and kernel space. Userspace is where user stuff runs - like commands, services, terminal, root services. Kernel processes come from kernel. [kworker] is an example. Those processes manage low level stuff - memory, hardware, disks and filesystems. – Sergiy Kolodyazhnyy Jan 28 '19 at 05:58
  • If the command ps awx results in differing output each time, how does one monitor the behavior of a particular process? As for the differences in userspace and the kernel, do you mean to say that there are 2 sets of processes being produced? Are the independent of one another? I would imagine that processes in the userspace are dependent on the processes that the kernel is running? – Motivated Jan 28 '19 at 06:02
  • 1
    I can't say if userspace processes depend on kernel processes. Some might, in order to query information only kernel can provide. By the way, Are threads implemented as processes on Linux might be interesting as well. As for monitoring specific process, well, it depends: you can either start a process, record its PID, and keep watching until that PID is on the list of processes, or have to brute force - run ps or pgrep frequently, which traverses all /proc directory till it finds matching process – Sergiy Kolodyazhnyy Jan 28 '19 at 06:06
  • 1
    @Motivated Difference between userspace and kernelspace: https://unix.stackexchange.com/q/87625/85039 – Sergiy Kolodyazhnyy Jan 28 '19 at 06:07
  • According to man grep -v is or --invert match is Invert the sense of matching, to select non-matching lines.. That suggests that it lists all other findings other than grep in this instance. – Motivated Jan 28 '19 at 06:25
  • @Motivated Yes, correct. grep -v 'pattern' will not show pattern - it will be filtered out. But remember that even though grep will filter itself out from output of ps it still exists as process. In other words, just because you don't see its PID it doesn't mean it doesn't exist – Sergiy Kolodyazhnyy Jan 28 '19 at 06:56
  • | grep [g]rep doesn't make much sense, the pattern [g]rep would still match the process name grep on the same command. – ilkkachu Jan 28 '19 at 12:08
2

Why does the command ps awx not display the process identification numbers 5646 and 5669?

Because you only started 5646 as part of the command ps awx | grep grep, and 5669 as part of the ps awx | grep agetty command. They were started after that initial listing, so weren't visible in it. Both ran until they had processed the input from the ps process in that particular pipeline, so they wouldn't be visible in any later listings either.

Similarly, if you run ps repeatedly, you'll see the process id change: every time you run the command, a new process is started.

More specifically, the second process in question was this:

5669 tty1     S+     0:00 grep --color=auto agetty

This is grep, which has been given the arguments --color=auto and agetty. This matches the grep command in ps awx | grep agetty, the --color=auto flag probably comes from some alias. It's not an agetty process. One of those would probably have agetty or /sbin/agetty as the first part of the command line, as in this example from a Debian system:

1269 tty3     Ss+    0:00 /sbin/agetty --noclear tty3 linux
ilkkachu
  • 138,973
  • I would have thought that agetty would have existed prior to the command ps awx | grep agetty being executed. This is because it launched the shell and other services once the user logged in. Do you mean to say that agetty is terminated once logged in. The feedback regarding ps awx | grep grep makes sense. – Motivated Jan 28 '19 at 15:55
  • @Motivated, no, that's not agetty, that's grep. Edited. – ilkkachu Jan 28 '19 at 18:48
  • To clarify, do you mean to say the output 5669 tty1 S+ 0:00 grep --color=auto agetty is not a representation of agetty and that itsgrep? If yes, is 5669 indicating a grep process? If so, isagettyat the end noting that its the output of the command5669 tty1 S+ 0:00 grep --color=auto agetty? If that's the case, i wasn't aware of that. My impression had been thatagetty` was the process associated with the process identification number 5669. – Motivated Jan 29 '19 at 07:04
  • 1
    @Motivated, I'm not sure how to clarify that without repeating myself. In the listings in your question, it should be clear that 5620 is ps with the argument awx. Similarly, 5646 is grep with the arguments --color=auto grep, and 5669 is grep with the arguments --color=auto agetty. In all cases, the arguments given to the commands show in last columns. There's no reason for an agetty process to have a name of grep, but if you're grepping for agetty, there's very much a reason for grep to have an argument of agetty. – ilkkachu Jan 29 '19 at 10:17
  • Thanks for clarifying that since i was operating under the assumption that the output was an indication of the process for which grep was used for e.g. agetty. – Motivated Jan 29 '19 at 16:34