Re: And 2.2.6 Re: Notice of Intent: TR 2.0.61
Hi, The fact that the apr_proc* API is so horribly convoluted yet still broken on Win32 is kind of ironic. If it's not fixable can we just abandon it? The code to implement piped loggers can be much simpler and more efficient on Unix if implemented natively. may I ask a question on this topic: why is piped logging so important, and why dont we add f.e. mod_log_rotate which does the job of rotating logs more nicerly on every platform? That would avoid 95% usage of piped logging: http://www.hexten.net/wiki/index.php/Mod-log-rotate sure, maybe there are other implementations like mysqllog or pgsqllog, and such which use piped logging; however I've tried already a lot, and none of all these 'solutions' work really reliable... Guen.
Re: And 2.2.6 Re: Notice of Intent: TR 2.0.61
Guenter Knauf wrote: may I ask a question on this topic: why is piped logging so important, and why dont we add f.e. mod_log_rotate which does the job of rotating logs more nicerly on every platform? That would avoid 95% usage of piped logging: http://www.hexten.net/wiki/index.php/Mod-log-rotate piped logging enables rotation for any kind of log file (at least log files of the modules that use the piped logging API). Examples: - SSL log - rewrite log - mod_jk log So it's not only about access logging. sure, maybe there are other implementations like mysqllog or pgsqllog, and such which use piped logging; however I've tried already a lot, and none of all these 'solutions' work really reliable... Guen. Regards, Rainer
Re: And 2.2.6 Re: Notice of Intent: TR 2.0.61
Status Update: There are issues in the current shipping version of APR 0.9 that must be resolved before we can reroll 2.0.x. Furthermore, there are issues in APR 1.2 that should be fixed (although not regression related) before we redo 2.2.x... Once APR is tagged and rolled, we will use that to TR 2.0.x and 2.2.x. If APR takes too much longer I may reconsider going ahead and releasing the 2.2.5 tarball anyway, since I don't want to delay 1.3/2.2 much further. We *need* to wait for 0.9 for 2.0 because of the regression...
Re: And 2.2.6 Re: Notice of Intent: TR 2.0.61
Jim Jagielski wrote: Status Update: There are issues in the current shipping version of APR 0.9 that must be resolved before we can reroll 2.0.x. Furthermore, there are issues in APR 1.2 that should be fixed (although not regression related) before we redo 2.2.x... Once APR is tagged and rolled, we will use that to TR 2.0.x and 2.2.x. If APR takes too much longer I may reconsider going ahead and releasing the 2.2.5 tarball anyway, since I don't want to delay 1.3/2.2 much further. We *need* to wait for 0.9 for 2.0 because of the regression... It turns out that in 2.2, we have a regression 8 mos old. Unfortunately we didn't pick up on it, because piped logs aren't something that the perl-framework understands. The crux of the problem is that we create processes without a full host of three fd's. Then we inflict them against sh. Linux/bash doesn't seem to mind, but solaris sh, and I'm guessing aix and hpux stock /bin/sh are not going to like this situation either. Obviously win32 minded, but this is an artifact of how we assembled things. We need three fd's to each logger process, but it's not as simple as that. We've collectively tacked on so much bubblegum and bailing wire trying to make the piped logger behave that it's missing any sensibility :) I'm trying to restore that back to a working state. I'd be +1 to releasing 2.2.6 today if we simply wanted to back out the entire pile of cruft added since we started invoking /bin/sh to launch log pipes. Till it behaves sensibly, I'll be -1 on release. Bill
Re: And 2.2.6 Re: Notice of Intent: TR 2.0.61
On Aug 20, 2007, at 4:36 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Status Update: There are issues in the current shipping version of APR 0.9 that must be resolved before we can reroll 2.0.x. Furthermore, there are issues in APR 1.2 that should be fixed (although not regression related) before we redo 2.2.x... Once APR is tagged and rolled, we will use that to TR 2.0.x and 2.2.x. If APR takes too much longer I may reconsider going ahead and releasing the 2.2.5 tarball anyway, since I don't want to delay 1.3/2.2 much further. We *need* to wait for 0.9 for 2.0 because of the regression... It turns out that in 2.2, we have a regression 8 mos old. Unfortunately we didn't pick up on it, because piped logs aren't something that the perl-framework understands. The crux of the problem is that we create processes without a full host of three fd's. Then we inflict them against sh. Linux/bash doesn't seem to mind, but solaris sh, and I'm guessing aix and hpux stock /bin/ sh are not going to like this situation either. Obviously win32 minded, but this is an artifact of how we assembled things. We need three fd's to each logger process, but it's not as simple as that. We've collectively tacked on so much bubblegum and bailing wire trying to make the piped logger behave that it's missing any sensibility :) I'm trying to restore that back to a working state. I'd be +1 to releasing 2.2.6 today if we simply wanted to back out the entire pile of cruft added since we started invoking /bin/sh to launch log pipes. Till it behaves sensibly, I'll be -1 on release. Of course, releases can't be vetoed, but doing further research indicates that Bill looks to be spot on with this issue...
Re: And 2.2.6 Re: Notice of Intent: TR 2.0.61
Jim Jagielski wrote: Of course, releases can't be vetoed, but doing further research indicates that Bill looks to be spot on with this issue... The point is, this was released. Iteratively. I'm just not in a mood to keep +1'ing releases while the code remains in this broken state. It becomes more complex when you factor in the issue that on restart today we are losing stderr before we go through the process of the next restart loop. The recent patch sort-of-half fixed things, and they understood the issue, but at least on windows the stderr pipe was still inherited, so the logprocess still would not die until the last generation had been killed. It looks that leaving plog alone until we've run the new open log phase, then closing the older plog, combined with setting the old stderr pipe as not-inherited before we launch the new stderr pipe and replace stderr, we go a significant distance to fix this error. If my understanding on the [EMAIL PROTECTED] thread is correct, the issue further resolves itself with better win (os2? netware?) apr create_process changes. If not, it's another flaw in log.c to correct. My current stomach ache is mpm_winnt, which is also leaving inherited resources around long enough to be picked up by the logging processes. Once I'm done isolating those, it's a matter of ensuring what still goes on with launching cgi processes, and then the situation should be much better all the way around. Bill
Re: And 2.2.6 Re: Notice of Intent: TR 2.0.61
On Mon, Aug 20, 2007 at 03:36:59PM -0500, William Rowe wrote: The crux of the problem is that we create processes without a full host of three fd's. Then we inflict them against sh. Linux/bash doesn't seem to mind, but solaris sh, and I'm guessing aix and hpux stock /bin/sh are not going to like this situation either. Why not? This is not unusual behaviour for Unix. Obviously win32 minded, but this is an artifact of how we assembled things. As I mentioned before, why not just fix the apr_proc* implementation on Win32? The fact that the apr_proc* API is so horribly convoluted yet still broken on Win32 is kind of ironic. If it's not fixable can we just abandon it? The code to implement piped loggers can be much simpler and more efficient on Unix if implemented natively. joe
Re: And 2.2.6 Re: Notice of Intent: TR 2.0.61
William A. Rowe, Jr. wrote: Jim Jagielski wrote: Of course, releases can't be vetoed, but doing further research indicates that Bill looks to be spot on with this issue... The point is, this was released. Iteratively. I'm just not in a mood to keep +1'ing releases while the code remains in this broken state. In case I wasn't clear, as RM I'm cool with holding off on 2.2.6 until this is fixed. But as a matter of policy, one cannot veto a release; that was the only point I was making. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
And 2.2.6 Re: Notice of Intent: TR 2.0.61
On Aug 13, 2007, at 3:59 PM, Jim Jagielski wrote: William A. Rowe, Jr. wrote: Sander Temme wrote: On Aug 13, 2007, at 11:37 AM, Roy T. Fielding wrote: It is mostly the same people, regardless. Bill could tag 0.9.15 and start a release vote on APR while Jim rebuilds 2.0.x based on that tag and starts another release vote here. That way, lazy folks like me can test both at once. I'm rolling APR snaps no later than first thing Wed a.m. No issue if Jim combines an apr release candidate with an httpd candidate, as long as everyone is ok that if apr goes boom, httpd would need to be rerolled. This is pretty stable code, so I'm not worried. With the Darwin fixes, I'd almost like to see 2.2.6 rerolled, with no change to httpd. Does anyone else find an objection to that? Jim, would it inflict too much pain to do this wed/thus? I've no problem with 2.0 and 2.2 being re-tagged and re-rolled to incorporate the latest APR fixes... Wed/Thurs is fine with me :) Just a FYI... 2.2.6 (httpd-2.2 head) with apr 1.2.10 (apr-1.2 head) show no regressions from the 2.2.5 tarball, so even though we don't need to reroll 2.2.5, I think it's best to do so, since we need to redo 2.0.x anyway... Once Bill tags APR, I'll do more pre-tag regressions, re-roll 2.x and then look at releasing next week.
Re: And 2.2.6 Re: Notice of Intent: TR 2.0.61
Jim Jagielski wrote: Once Bill tags APR, I'll do more pre-tag regressions, re-roll 2.x and then look at releasing next week. +1 I'll be looking out for the tarball. I did have a configure failure on netbsd 3.1 where it failed a sed script looking for APR... this was a regression from 2.2.4. I'll look to throw that on the list tonight when I get home. S. smime.p7s Description: S/MIME Cryptographic Signature
