Bug #20745 [Com]: socket_accept() in blocking mode doesn't handle signal interrupts

Edit report at http://bugs.php.net/bug.php?id=20745&edit=1 ID: 20745 Comment by: contact at aldrik dot net Reported by: polone at townnews dot com Summary: socket_accept() in blocking mode doesn't handle signal interrupts Status: Closed Type: Bug Package: Sockets related Operating System: Linux PHP Version: 4.2.3 Block user comment: N Private report: N New Comment: Could this bug be reopened ? Mapping of posix API isn't well done, the workaround introduce latency and make people loose their time. Signal are made to interrupt workflow, even on blocking situation. Previous Comments: ------------------------------------------------------------------------ [2008-03-06 15:25:36] polone at townnews dot com This IS a bug - all you've stated is _another_ workaround - less elegant than just setting the socket_accept() call to non-blocking and sleeping for 1 second (or you can sleep for microseconds in PHP 5) in the loop. It doesn't fix the underlying problem - which is that socket_accept() does not behave like accept(). If I issue SIGUSR1 - I should not have to set SIGALRM to 'reap' signals. Signals are suppose to interrupt blocking waits like this. I shoudn't have to make the accept() call non-blocking. At the very least - the non-standard behavior of this function (and it's caveats) should be documented. ------------------------------------------------------------------------ [2008-03-06 14:47:48] rose dot andrew at gmail dot com This is not a bug. socket_accept() will ignore all signals expect an alarm. I have documented how to use this method of interrupting socket_accept() here: http://andrew-rose.blogspot.com/2008/02/php-getting-signals-through-to-blocking.html ------------------------------------------------------------------------ [2007-11-29 01:51:59] steven dot gilberd at gmail dot com This bug still appears to exist (PHP 5.2.3-1+b1 (cli)), on at least socket_accept(). The signals just queue up until the socket receives a connection and unblocks, at which point the signals are processed as normal. I would like to request that this bug be reactivated; leaving it sitting here as 'No Feedback' isn't helping anyone. ------------------------------------------------------------------------ [2007-03-12 18:54:30] antoine dot bajolet at tdf dot fr Hello, The issue still exists, PHP Version => 4.4.6 System => Linux pentium2.antoine 2.6.20 #5 Sun Feb 18 16:28:17 CET 2007 i686 Build Date => Mar 6 2007 21:15:38 Complete code to reproduce error : script.php ------------------------------------------------------------------ #!/usr/local/bin/php <?php define ( 'BIND_PORT', 3333 ); /* Signal Handler */ function signalHandler( $sig ) { switch ( $sig ) { case SIGTERM : exit( 0 ); break; case SIGCHLD : pcntl_waitpid(-1,$status,WNOHANG); break; } } print "My PID is ".posix_getpid()."\n"; declare ( ticks = 1 ); pcntl_signal( SIGTERM, 'signalHandler' ); pcntl_signal( SIGCHLD, 'signalHandler' ); // infinite execution time set_time_limit( 0 ); // Socket creation $sock = socket_create ( AF_INET, SOCK_STREAM, SOL_TCP ); // Bind sur le port BIND_PORT if ( !socket_bind( $sock, '0.0.0.0', BIND_PORT ) ) { print "Unable to bind to port " . BIND_PORT . " !\n"; exit( 1 ); } // Listening up to 16 buffets socket_listen ( $sock, 16 ); // Infinite loop while ( true ) { // Wait for incoming connections, hangs signal handling $subsock = socket_accept ( $sock ); // Connection received, forking sub-process $subPid = pcntl_fork(); if ( $subPid === 0 ) { // Get remote informations socket_getpeername( $subsock , $remoteAddr , $remotePort ); socket_write( $subsock, 'Simple Socket Server accepting commands from ' . $remoteAddr . "\n" ); // Whe are in interactive mode while ( true ) { $received = socket_read ( $subsock, 65536, PHP_NORMAL_READ ); // Clean shutdown if ( !$received ) { socket_shutdown( $subsock, 2 ); socket_close( $subsock ); exit( 0 ); } // Cleaning entry $received = trim( $received ); if ( $received ) { // two commands : HELLO and QUIT switch ( $received ) { case 'HELLO': socket_write( $subsock, 'HELLO ' . $remoteAddr . "\n" ); break; case 'QUIT': // (shutdown) socket_write( $subsock, 'BYE' . "\n" ); socket_shutdown( $subsock, 2 ); socket_close( $subsock ); exit( 0 ); break; default : socket_write( $subsock, 'Unknown command...' . "\n" ); } } } } } // while ?> ------------------------------------------------------------------ Commands : [Shell1]$ ./script.php My PID is 18135 [Shell2]$ kill 18135 <Happens nothing on Shell1...> [Shell2]$ telnet localhost 3333 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host [Shell1] : The script exits. => The signal is properly intercepted but the handler is only called when the script continues after socket_accept(). Whe are using a little more complex code when the fist process is a child of a fork itself : At this time, the only way to end it is a not very clean SIGKILL. Regards, AB ------------------------------------------------------------------------ [2006-05-25 19:31:39] lindsay at bitleap dot com I still see this issue with php 5.1.4. I did notice that the signal will queue up and on the next inbound connection the queued signal executes. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=20745 -- Edit this bug report at http://bugs.php.net/bug.php?id=20745&edit=1