.

fix bug :
$proc = proc_open('php test2.php',[],$_);
sleep(1); #fix
posix_kill(proc_get_status($proc)['pid'],SIGUSR1);

Can you clarify what the actual issue here is? Is it the "does not run" part? That seems expected to me, because the SIGUSR1 default action is to terminate the process, so if the signal arrives before the echo can execute, nothing will be printed.

Or is there an actual hang here, and if so, how does it look like. Does the outer "php test1.php" call itself hang indefinitely?

The main problem is : test2.php does not run when sending SIGUSR1.

> because the SIGUSR1 default action is to terminate the process
Why?

SIGUSR1 and SIGUSR2 are User-defined signals.
I thought these signals were for me.
Why the php using this signals for terminate the process?

Ok i put assume that signals are for terminate the process but why does the SIGALRM signal behave similarly(acts like SIGUSR1)?


New Example :

test1.php
$proc = proc_open('php /root/test2.php',[],$p);
posix_kill(proc_get_status($proc)['pid'],SIGALRM);

while(proc_get_status($proc)['running'])
    sleep(1);

echo "End !";


test2.php
mkdir('/root/a');

In this example, directory `a` is not created and test2.php does not actually run.

> SIGUSR1 and SIGUSR2 are User-defined signals.
> I thought these signals were for me.
> Why the php using this signals for terminate the process?

PHP isn't doing anything -- signals have a default disposition, which is Terminate for all of SIGALRM, SIGUSR1 and SIGUSR2. Check "man 7 signal" for a list of default dispositions.

You can define a custom signal action using pcntl_signal(), which will override the default disposition. Of course, it will only take effect after the pcntl_signal() call actually happens, so it won't make a difference if SIGUSR1 arrives too early.

Yes, I realized.
I did not pay attention to their default value. 


nikic thanks.