Summary: | New function for apr_proc_detach() + close ALL file descriptors | ||
---|---|---|---|
Product: | APR | Reporter: | Philipp Hahn <hahn> |
Component: | APR | Assignee: | Apache Portable Runtime bugs mailinglist <bugs> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | ylavic.dev |
Priority: | P2 | ||
Version: | HEAD | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Attachments: | Demo-implementation of close_fds() |
Description
Philipp Hahn
2015-03-06 10:13:25 UTC
Created attachment 32548 [details]
Demo-implementation of close_fds()
gcc -Wall -o apache-closefd apache-closefd.c && ./apache-closefd 42>/dev/null
apr_proc_detach() does exactly what it is meant to: make the current process detach from the terminal (close STDIN/OUT/ERR) and, if daemonize is specified (not the daemonize tool!), make the current process have its own session (go background). Should it close all open descriptors now that could/would break existing applications, those which currently open file descriptors before apr_proc_detach() and use them after (note that apr_proc_detach() already takes care of not closing the standard descriptors, but rather reopen them so that next opened descriptors won't "hijack" STDIN/OUT/ERR). Maybe the APR could introduce a new function for this, but IMHO this already as simple as opening fds on a dedicated pool which could then be cleared before apr_proc_detach() is called. For fds that are not handled by the APR, it seems quite tricky to let the APR close them... I also don't think apr has a role here to free arbitrary handles (other devs can of course disagree and re-open). The best place to address this issue is in the caller of httpd, but maybe httpd could have a role, controlled by some -Dxxx command-line arg. (Does httpd and its arbitrary plug-in modules have no fds it needs to preserve across the detach? I don't understand how any code would know, but that's not a concern for this apr bug ;) ) |