php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49340 Signals not catchable when certain functions are in execution
Submitted: 2009-08-23 22:12 UTC Modified: 2009-08-31 13:42 UTC
Votes:6
Avg. Score:3.5 ± 1.1
Reproduced:3 of 3 (100.0%)
Same Version:1 (33.3%)
Same OS:3 (100.0%)
From: alexmontoanelli at gmail dot com Assigned:
Status: Open Package: PCNTL related
PHP Version: 5.2.10 OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: alexmontoanelli at gmail dot com
New email:
PHP Version: OS:

 

 [2009-08-23 22:12 UTC] alexmontoanelli at gmail dot com
Description:
------------
After executions of certain functions,
the handler configured by
posix_singal, are not called where the 
funcion are in execution - like freads.

Reproduce code:
---------------
#!/usr/bin/php
<?php

declare(ticks = 1);

function handler($a){
    echo "Calling handler on signal :  $a\n";
}

//define handlers for signals
pcntl_signal(SIGTERM, 'handler');
pcntl_signal(SIGINT, 'handler');

//if you send a signal, the function fgets are waiting for a user input, he is not called, until you enter something
$foo = fgets(STDIN);

echo $foo;


Expected result:
----------------
alexmm tmp # php a.php 
^C
Calling handler on signal :  2


Actual result:
--------------
alexmm tmp # php a.php 
^C MY_INPUT_AFTER_SEND_CTRL_C
Calling handler on signal :  2
 MY_INPUT_AFTER_SEND_CTRL_C

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-24 08:54 UTC] sjoerd@php.net
Thank you for your bug report.

I don't fully understand the problem.

Is the problem that you have to hit enter for the signal handler to run? Or that the line with 'echo $foo' is ran after the fgets?
 [2009-08-24 11:41 UTC] alexmontoanelli at gmail dot com
The problem is that I need hit enter - exit from fgets - to run the signal handler - but this is not the correct way - in python for example, the signal handler are calling when the function are waiting for a user input.

I found this page - http://br2.php.net/manual/en/function.pcntl-signal.php - the commentary above:

'28-Mar-2006 07:26
Process handling is not available when using a blocking socket! Bear this in mind.'

There is true?

Regards
 [2009-08-24 13:04 UTC] alexmontoanelli at gmail dot com
Where I say:

'There is true?',

is

'That's true?'

Regards
 [2009-08-27 11:28 UTC] alexmontoanelli at gmail dot com
some position ?
 [2009-08-27 19:30 UTC] sjoerd@php.net
PHP signals are implemented with ticks (http://us3.php.net/manual/en/control-structures.declare.php). Ticks are events that occur every so much statements in a script. Since fgets() blocks, no more statements are executed and no more ticks are fired. This means that no signal arrives.

I do not know whether the current behavior is by design or by mistake, so I cannot determine whether it is a bug or not. It would certainly be desirable to be able to interrupt a blocking read by doing Ctrl-C.
 [2009-08-31 13:42 UTC] alexmontoanelli at gmail dot com
Ok.But I guess that this behavior is not that anyone expect.

Some one else can give the final word ?

Regards
 [2012-01-31 13:53 UTC] nasretdinov at gmail dot com
Actually it is due to syscall restarting by default. You should pass third 
argument as "false" to pcntl_signal and you will be able to catch SIGINT, but 
only after second attempt. The other bug I created (https://bugs.php.net/bug.php?
id=52121) addresses more severe case, I suppose
 [2016-07-13 00:24 UTC] anthonyryan1 at gmail dot com
Just encountered this in PHP 7.0.6. The fgets blocking operation still prevents signal handlers from firing.
 [2017-01-01 21:53 UTC] dave at mudsite dot com
Another oddity with this is that using pcntl_async_signals() rather than declare(ticks=1) results with no handling of your ^C's
 [2018-06-12 12:20 UTC] dnt at gmx dot gom
I also stumbled upon this, I as well think this is not the expected behavior. There exists a third party extension that should work with blocking PHP scripts. I haven't tested it, though. 
https://github.com/rstgroup/php-signal-handler
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 19:01:29 2024 UTC