On Tuesday 03 March 2009, William A. Rowe, Jr. wrote:
Let's review what -should- happen today;
apr_file_open_stderr(stderr_log, p)
should return stderr_log apr_file_t indicating the INHERIT flag
set.
OK, this was the missing bit. apr_file_open_stderr() uses
apr_os_file_put(), which
On Tue, 2009-03-03 at 21:51 +0100, Stefan Fritsch wrote:
The problem with the CLOEXEC-patch is that apr_file_dup2() now only
checks for APR_INHERIT but not for APR_FILE_NOCLEANUP to determine if
FD_CLOEXEC should be set. But APR_FILE_NOCLEANUP should imply
APR_INHERIT and the new
On Tue, 2009-03-03 at 21:51 +0100, Stefan Fritsch wrote:
The problem with the CLOEXEC-patch is that apr_file_dup2() now only
checks for APR_INHERIT but not for APR_FILE_NOCLEANUP to determine if
FD_CLOEXEC should be set. But APR_FILE_NOCLEANUP should imply
APR_INHERIT and the new
On Tuesday 03 March 2009, Bojan Smojver wrote:
On Tue, 2009-03-03 at 21:51 +0100, Stefan Fritsch wrote:
The problem with the CLOEXEC-patch is that apr_file_dup2() now
only checks for APR_INHERIT but not for APR_FILE_NOCLEANUP to
determine if FD_CLOEXEC should be set. But APR_FILE_NOCLEANUP
On Tue, 2009-03-03 at 22:57 +0100, Stefan Fritsch wrote:
Yes (with old_file-flags instead of flag).
Cut'n'paste is a wonderful thing. Most of the time ;-)
--
Bojan
Bojan Smojver wrote:
On Tue, 2009-03-03 at 21:51 +0100, Stefan Fritsch wrote:
The problem with the CLOEXEC-patch is that apr_file_dup2() now only
checks for APR_INHERIT but not for APR_FILE_NOCLEANUP to determine if
FD_CLOEXEC should be set. But APR_FILE_NOCLEANUP should imply
APR_INHERIT
Bojan Smojver wrote:
On Tue, 2009-03-03 at 17:02 -0600, William A. Rowe, Jr. wrote:
No; the apr_file_open_stderr structure is still -wrong-.
Maybe we should then just call apr_file_inherit_set() inside
apr_file_open_stdin/stdout/stderr() to make sure these get inherited. Is
this what you
On Tue, 2009-03-03 at 17:57 -0600, William A. Rowe, Jr. wrote:
Setting the flag is sufficient.
The fact that a handle shouldn't be closed on exec in an apr-sense makes
no difference to whether it should be closed on non-apr exec() calls.
Just before I make the change, let me understand this
On Tue, 2009-03-03 at 18:08 -0600, William A. Rowe, Jr. wrote:
I believe that is correct. Anyone else care to validate? As far as I know
this change is a noop, until the introduction of this most recent file
inheritance patch for CLOEXEC.
After reading apr_os_file_put() (which is used to
On Sunday 01 March 2009, Bojan Smojver wrote:
The change for
files is probably not, as it can leave exec'ed programs without
stdin/stdout/stderr.
We just need to make sure these fds are marked so that they can be
inherited, right?
Who needs to make sure, the application or apr? Currenty
Stefan Fritsch wrote:
Who needs to make sure, the application or apr? Currenty httpd 2.2.x
does not mark stderr as inheritable. It doesn't sound good if a
change in stable apr requires a change in stable httpd. But I guess
you could argue that apps relying on the current behaviour are buggy.
On Monday 02 March 2009, William A. Rowe, Jr. wrote:
Stefan Fritsch wrote:
Who needs to make sure, the application or apr? Currenty httpd
2.2.x does not mark stderr as inheritable. It doesn't sound good
if a change in stable apr requires a change in stable httpd. But
I guess you could
Stefan Fritsch wrote:
Do you think it would be ok if this changed for 1.3/1.4 for
stdin/out/err?
This entire patch set has me increasingly worried, as it has the strong
potential of destabilizing many apr apps. I'm already -1 on this for the
1.3 release, and am torn between -0 and -1 to
On Mon, 2009-03-02 at 17:07 -0600, William A. Rowe, Jr. wrote:
This entire patch set has me increasingly worried, as it has the strong
potential of destabilizing many apr apps.
The _intention_ of the patch (at least as interpreted by me) is that if
the file has APR_INHERIT_SET flag turned
On Sat, 2009-02-28 at 17:27 +0100, Stefan Fritsch wrote:
No problem. Thanks for commiting the patch. BTW, I think a CHANGES
entry would be good, too. And Arkadiusz Miskiewicz did a part of the
patch.
Done.
Are parts of this suitable for backport to 1.3/1.4?
I would hope so.
The change
On Friday 27 February 2009, Bojan Smojver wrote:
On Fri, 2009-02-27 at 20:22 +, bo...@apache.org wrote:
+Patch by Stefan Fritsch sf sfritsch.de.
Apologies Stefan for not doing this earlier. Not sure how I missed
it.
No problem. Thanks for commiting the patch. BTW, I think a CHANGES
On Fri, 2009-02-27 at 20:22 +, bo...@apache.org wrote:
+Patch by Stefan Fritsch sf sfritsch.de.
Apologies Stefan for not doing this earlier. Not sure how I missed it.
--
Bojan
17 matches
Mail list logo
