proc_get_status() not returning correct pid

[email protected] (James Colannino)
Newsgroups php.general
Message-ID <CAJJG1Cn3eY-jmuGhGgm0u_iifVGke=o_ULpV1V0dd_xqSQf96g@mail.gmail.com>
Hi everyone,

It seems proc_get_status() isn't returning the correct pid when I spawn a
background php process using proc_open (or at least not the pid I'm
expecting.) I'm calling it like this (I'll ommit the descriptorspec and
other parameters for brevity's sake):

$this->process = proc_open(
'php worker.php',
$descriptorspec,
$pipes,
$cwd,
$env
);

Later, if I var_dump the output of proc_get_status($this->process), I'll
get something like this:

array(8) {
  ["command"]=>
  string(14) "php worker.php"
  ["pid"]=>
  int(24173)
  ["running"]=>
  bool(true)
  ["signaled"]=>
  bool(false)
  ["stopped"]=>
  bool(false)
  ["exitcode"]=>
  int(-1)
  ["termsig"]=>
  int(0)
  ["stopsig"]=>
  int(0)
}

However, when I check on the system as it's running, I see that the above
pid doesn't belong to the executing php process, but rather to a process
with the command "sh -c php worker.php." As a result, when I try to kill
the process, I still have processes with the command "php worker.php" left
behind (these are backgrounded consumers that are waiting on input they'll
never receive.)

This is the output of ps aux | grep php as an example:

user+ 24173  0.0  0.0   4508   764 pts/0    S+   18:51   0:00 sh -c php
worker.php
user+ 24174  0.0  0.7 312180 31544 pts/0    S+   18:51   0:00 php worker.php

After running either proc_terminate($this-process) or
posix_kill(proc_get_status($this->process)['pid'], SIGKILL), I still have
the following left behind:

user+ 24174  0.0  0.7 312180 31544 pts/0    S+   18:51   0:00 php worker.php

Only the "sh -c php worker.php" process disappears.

Does anyone have an idea of what's going on and how I can get the pid for
the correct process so I can kill it from inside PHP?

Thanks!

This is on PHP 7.0.21.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.