php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #43290 Proposed new socket function: socket_set_close_on_exec
Submitted: 2007-11-14 08:58 UTC Modified: 2014-08-04 19:46 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: roelf at neology dot co dot za Assigned:
Status: Open Package: *General Issues
PHP Version: 5.2.5 OS: Debian GNU/Linux Etch
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 this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: roelf at neology dot co dot za
New email:
PHP Version: OS:

 

 [2007-11-14 08:58 UTC] roelf at neology dot co dot za
Description:
------------
I would like to propose a new socket function:

socket_set_close_on_exec

Reasoning:
I have a case where I developed a php CLI sapi script, that manages an entire Linux system's bootup process, and acts as a system process supervisor, similar to 'init'. The supervisor listens using php socket functions on port 19992, in order to receive text commands that administer the supervisor.

One of the processes that my script supervises, is a PHP CLI implementation of a webserver, called 'nanoweb'.

When the supervisor 'exec()'s the nanoweb server (and any other process for that matter) the child inherits the listening socket, port 19992.

If the supervisor is unexpectedly killed e.g. 'kill -9' nanoweb typically starts listening on this socket. The problem is that the supervisor is incapable now of being restarted, due to the fact that it's port is in use, and the supervisor is unable to bind the port.

The problem is not with nanoweb, itsself, but the behaviour where the listening socket is inherited.

I propose an additional socket function socket_set_close_on_exec() which will do the appropriate fcntl() on the socket handle, so that child processes do not inherit the socket. This elegantly solves the problem in my case without changing the default behaviour of php.

Below is the example code I used to patch my PHP - it is based entirely on the socket_set_nonblock() function's code.





Reproduce code:
---------------
/* {{{ proto bool socket_set_close_on_exec(resource socket)
   Sets close-on-exec mode on a socket resource */
PHP_FUNCTION(socket_set_close_on_exec)
{
    zval        *arg1;
    php_socket  *php_sock;
    int         flags;

    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "r", &arg1) == FAILURE)
        return;

    ZEND_FETCH_RESOURCE(php_sock, php_socket *, &arg1, -1, le_socket_name, le_socket);

    flags = fcntl(php_sock->bsd_socket, F_GETFD);

    /* Safely append close-on-exec to other flags unless the get fails. */
    if (flags > -1) flags |= FD_CLOEXEC;
        else flags = FD_CLOEXEC;

    if (fcntl(php_sock->bsd_socket, F_SETFD, flags) > -1) {
        RETURN_TRUE;
    }

    RETURN_FALSE;
}
/* }}} */


Expected result:
----------------
I expect a function to be available to set the FD_CLOEXEC flag on socket handles

Actual result:
--------------
There is no such function available

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-08-04 19:46 UTC] langemeijer@php.net
-Package: Feature/Change Request +Package: *General Issues
 [2014-08-04 19:46 UTC] langemeijer@php.net
Related to bug #67383. Really the same issue, but that bug report is saying it's a bug, not a missing feature.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Wed Oct 23 20:01:30 2019 UTC