Re: disable IPv6 debian

[Greg Wooledge <greg@wooledge.org>]

On Sat, Apr 16, 2022 at 08:07:09AM -0400, The Wanderer wrote:
> ...Huh. That's so unintuitive that it hadn't even occurred to me to test
> it before posting, but I just did test it (with 'ps', not 'foobar',
> because there's a reason why 'ps' would be special for this purpose),
> and you're correct.
> 
> I *think* it makes sense on examination? In that the fact that the first
> grep command occurs in the ps output in the first place must mean that
> its process is in some sense started before the ps command is run, even
> though the ps command comes earlier in the pipeline, so the same must
> logically hold true for the *second* grep command as well.

All of the commands in a pipeline are executed simultaneously, in
parallel.

Except of course nothing is truly simultaneous.  The shell will attempt
to start them all at roughly the same time, but individual timing
issues across three child processes cause what we call a "race condition".
Sometimes, one of them runs a bit too fast, or a bit too slow, and
you get weird results.

For this pipeline,

  ps -ef | grep foobar | grep -v grep

the race condition is that the ps command could execute so quickly
that the 'grep foobar' process hasn't even started yet.  And then, you
would *not* see 'grep foobar' in the output of ps, and so the final
'grep -v grep' wouldn't match any lines.  In practice, you might not
ever see this happen, at least not in a small number of trials.  But
if you do this thousands of times, on systems with varying loads, you
might.

And of course, tomas raised the excellent point that this is not the
best way to show a process when you already know its PID.

  ps -ef | grep "$mypid"

is silly.  You can simply do

  ps -fp "$mypid"

instead.  You even get to see the headers, which are lost in the silly
variant.