Re: apxs in 2.0.36
"Rob Emanuele" <[EMAIL PROTECTED]> writes: > I can't make apxs generate so's by default. It makes an lo > instead. look in the .libs that is created apxs -c mod_foo.c compile, creates shared object in .libs/ the name can vary between platforms apxs -i mod_foo.lainstall, figures out name of file in .libs/ to grab and install as mod_foo.so -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
apxs in 2.0.36
I can't make apxs generate so's by default. It makes an lo instead. If I force it to make an so with the -o option it get many link errors about the apache API calls. Ran this: /usr/sbin/apxs -o mod_access.so -c mod_access.c Got this: /etc/httpd/build/libtool --silent --mode=compile cc -prefer-pic -DAP_HAVE_DESIGNATED_INITIALIZER -DLINUX=2 -D_REE NTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -g -O2 -p thread -DNO_DBM_REWRITEMAP -I/usr/include/httpd -c -o mod_access.lo mod_access.c && touch mod_access.slo /etc/httpd/build/libtool --silent --mode=link gcc -o mod_access.so -rpath /usr/lib/httpd/modules -module -avoid-version mod_access.lo /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x1 8): undefined reference to `main' mod_access.o: In function `create_access_dir_config': /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:118: undefined reference to `apr_pcalloc' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:124: undefined reference to `apr_array_make' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:125: undefined reference to `apr_array_make' mod_access.o: In function `allow_cmd': /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:156: undefined reference to `apr_pstrdup' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:164: undefined reference to `apr_array_push' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:178: undefined reference to `apr_ipsubnet_create' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:184: undefined reference to `apr_strerror' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:185: undefined reference to `apr_pstrdup' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:189: undefined reference to `apr_ipsubnet_create' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:191: undefined reference to `apr_strerror' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:192: undefined reference to `apr_pstrdup' mod_access.o: In function `find_allowdeny': /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:254: undefined reference to `apr_table_get' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:263: undefined reference to `apr_ipsubnet_test' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:272: undefined reference to `ap_get_remote_host' mod_access.o: In function `check_dir_access': /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:322: undefined reference to `ap_satisfies' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:322: undefined reference to `ap_some_auth_required' /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:324: undefined reference to `ap_log_rerror' mod_access.o: In function `register_hooks': /home/rje/httpd-2.0.39/modules/aaa/mod_access.c:334: undefined reference to `ap_hook_access_checker' collect2: ld returned 1 exit status apxs:Error: Command failed with rc=65536 . Any ideas? Thanks, Rob
Re: problems building modules with 2.0.36
On Wed, 5 Jun 2002, [ISO-8859-1] Heinrich Götzger wrote: > thanks, seems as it would work now. Yep, I was able to reproduce the problem and that does in fact fix it. I committed that plus a similar change a few lines up. Thanks! --Cliff
Re: problems building modules with 2.0.36
Stas,
thanks, seems as it would work now.
regards
Heinrich
On Wed, 5 Jun 2002, Stas Bekman wrote:
>Heinrich Götzger wrote:
>> Hi,
>>
>> I discovered problems today with building and compiling some own modules
>> for httpd 2.0.36 on a SuSE 7.2 Box.
>>
>> The Server runs fine.
>>
>> Using apxs brought some things which I'm not clear on (I'm not a perl
>> Guru):
>>
>> $ echo `./apxs -q CC`
>> gcc
>> $ echo `./apxs -q TARGET`
>> httpd
>> ...
>>
>> it goes wrong for CFLAGS_SHLIB, LD_SHLIB, LDFLAGS_SHLIB, LIBS_SHLIB
>> $ echo `./apxs -q CFLAGS_SHLIB`
>> Use of uninitialized value in concatenation (.) at ./apxs line 278.
>> echo `./apxs -q LD_SHLIB`
>> Use of uninitialized value in concatenation (.) at ./apxs line 278.
>> $ echo `./apxs -q LDFLAGS_SHLIB`
>> Use of uninitialized value in concatenation (.) at ./apxs line 278.
>> $ echo `./apxs -q LIBS_SHLIB`
>> Use of uninitialized value in concatenation (.) at ./apxs line 278.
>
>if the line is reported correctly here is the fix:
>
>Index: support/apxs.in
>===
>RCS file: /home/cvspublic/httpd-2.0/support/apxs.in,v
>retrieving revision 1.38
>diff -u -r1.38 apxs.in
>--- support/apxs.in13 May 2002 17:16:55 - 1.38
>+++ support/apxs.in5 Jun 2002 04:35:24 -
>@@ -275,7 +275,7 @@
> if (exists $internal_vars{$arg} or exists
>$internal_vars{lc $arg}) {
> my $val = exists $internal_vars{$arg} ? $arg : lc $arg;
> $val = eval "\$CFG_$val";
>-$result .= eval "qq($val)";
>+$result .= eval "qq($val)" if defined $val;
> $result .= ";;";
> $ok = 1;
> }
>
>
>__
>Stas BekmanJAm_pH --> Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
>http://modperlbook.org http://apache.org http://ticketmaster.com
>
--
http://www.xmlBlaster.org
Re: problems building modules with 2.0.36
Heinrich Götzger wrote:
> Hi,
>
> I discovered problems today with building and compiling some own modules
> for httpd 2.0.36 on a SuSE 7.2 Box.
>
> The Server runs fine.
>
> Using apxs brought some things which I'm not clear on (I'm not a perl
> Guru):
>
> $ echo `./apxs -q CC`
> gcc
> $ echo `./apxs -q TARGET`
> httpd
> ...
>
> it goes wrong for CFLAGS_SHLIB, LD_SHLIB, LDFLAGS_SHLIB, LIBS_SHLIB
> $ echo `./apxs -q CFLAGS_SHLIB`
> Use of uninitialized value in concatenation (.) at ./apxs line 278.
> echo `./apxs -q LD_SHLIB`
> Use of uninitialized value in concatenation (.) at ./apxs line 278.
> $ echo `./apxs -q LDFLAGS_SHLIB`
> Use of uninitialized value in concatenation (.) at ./apxs line 278.
> $ echo `./apxs -q LIBS_SHLIB`
> Use of uninitialized value in concatenation (.) at ./apxs line 278.
if the line is reported correctly here is the fix:
Index: support/apxs.in
===
RCS file: /home/cvspublic/httpd-2.0/support/apxs.in,v
retrieving revision 1.38
diff -u -r1.38 apxs.in
--- support/apxs.in 13 May 2002 17:16:55 - 1.38
+++ support/apxs.in 5 Jun 2002 04:35:24 -
@@ -275,7 +275,7 @@
if (exists $internal_vars{$arg} or exists
$internal_vars{lc $arg}) {
my $val = exists $internal_vars{$arg} ? $arg : lc $arg;
$val = eval "\$CFG_$val";
-$result .= eval "qq($val)";
+$result .= eval "qq($val)" if defined $val;
$result .= ";;";
$ok = 1;
}
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
problems building modules with 2.0.36
Hi, I discovered problems today with building and compiling some own modules for httpd 2.0.36 on a SuSE 7.2 Box. The Server runs fine. Using apxs brought some things which I'm not clear on (I'm not a perl Guru): $ echo `./apxs -q CC` gcc $ echo `./apxs -q TARGET` httpd ... it goes wrong for CFLAGS_SHLIB, LD_SHLIB, LDFLAGS_SHLIB, LIBS_SHLIB $ echo `./apxs -q CFLAGS_SHLIB` Use of uninitialized value in concatenation (.) at ./apxs line 278. echo `./apxs -q LD_SHLIB` Use of uninitialized value in concatenation (.) at ./apxs line 278. $ echo `./apxs -q LDFLAGS_SHLIB` Use of uninitialized value in concatenation (.) at ./apxs line 278. $ echo `./apxs -q LIBS_SHLIB` Use of uninitialized value in concatenation (.) at ./apxs line 278. However I'm not clear if I did it all correct because I just want to know how it works basicly. Furtheron I discovered a typo: May it be the case that there is a typo in 'srclib/apr-util/include/apr_uri.h' the line #include should read #include "apr_network_io.h" thanks and best regards Heinrich -- http://www.xmlBlaster.org
Building apache_1.3.24 and httpd-2.0.36 under Mac OS 10.1.4?
Does anybody know how the redefinition of duplicate symbols problems are resolved under MacOS 10.1.4? Is it just a matter of not linking against the supplied regex libraries?
Re: httpd-2.0.36 - mod_cache problems
Hi,
Why do we need to set the content type at cache_storage.c at line
240, i just commented it out and it seems to be working. Sorry about
my ignorance, but may it cause a side effect?
Thanks,
Tacio
PS:
diff -u cache_storage.c-orig cache_storage.c
--- cache_storage.c-origThu May 23 17:33:31 2002
+++ cache_storage.c Thu May 23 17:32:59 2002
@@ -237,7 +237,7 @@
return rv;
}
-ap_set_content_type(r, apr_pstrdup(r->pool, info->content_type));
+/*ap_set_content_type(r, apr_pstrdup(r->pool, info->content_type));*/
r->filename = apr_pstrdup(r->pool, info->filename );
return APR_SUCCESS;
Tacio A.G. Santos wrote:
> Thanks ,
> It solved the problem with file permission, but there's still a
> problem with the content type.
> For example getting a index.html file i get in the first request:
>
> 2 Date: Thu, 23 May 2002 14:14:46 GMT
> 3 Server: Apache/1.3.23 (Unix) mod_perl/1.26
> 4 Content-Location: index.html.en
> 5 Vary: negotiate,accept-language,accept-charset
> 6 TCN: choice
> 7 Last-Modified: Tue, 23 Apr 2002 14:56:35 GMT
> 8 ETag: "6cb4-5b1-3cc57623;3cc57623"
> 9 Accept-Ranges: bytes
> 10 Content-Type: text/html; charset=ISO-8859-1
> 11 Content-Language: en
> 12 Via: 1.0 sitak:8080
> 13 Content-Length: 1457
> 14 Connection: close
>
> If i try to get it again the following headers are returned:
>
>
> 2 Date: Thu, 23 May 2002 14:21:24 GMT
> 3 Server: Apache/1.3.23 (Unix) mod_perl/1.26
> 4 Content-Location: index.html.en
> 5 Vary: negotiate,accept-language,accept-charset
> 6 TCN: choice
> 7 ETag: "6cb4-5b1-3cc57623;3cc57623"
> 8 Accept-Ranges: bytes
> 9 Content-Language: en
> 10 Via: 1.0 sitak:8080
> 11 Last-Modified: Tue, 23 Apr 2002 14:56:35 GMT
> 12 Content-Type: text/plain; charset=ISO-8859-1
> 13 Content-Length: 1457
> 14 Connection: close
>
>
> It just changed the Content-Type to text/plain. It also happens with
> image files. Somehow mod_cache is not taking into account the
> Content-Type written in the respective cache header file. Does anybody
> know where is it set?
>
> Thanks again,
> Tacio
>
>
> Jeff Trawick wrote:
>
>> "Tacio A.G. Santos" <[EMAIL PROTECTED]> writes:
>>
>>
>>> Hi,
>>> I'm trying to configure mod_cache+mod_proxy, but mod_cache is not
>>> working properly. One thing i found strange is that if you look in the
>>> cache directory we have the following strange file permissions:
>>>
>>> -rw---1 webu webg 2326 May 22 16:41
>>> wkL1JcPol1pQ.data
>>> --1 webu webg 355 May 22 16:41
>>> wkL1JcPol1pQ.header
>>
>>
>>
>> Perhaps you could try this patch?
>>
>> Index: mod_disk_cache.c
>> ===
>> RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_disk_cache.c,v
>> retrieving revision 1.33
>> diff -u -r1.33 mod_disk_cache.c
>> --- mod_disk_cache.c17 May 2002 11:33:09 -1.33
>> +++ mod_disk_cache.c23 May 2002 11:59:03 -
>> @@ -548,7 +548,7 @@
>>
>> rv = apr_file_open(&dobj->hfd, dobj->hdrsfile,
>> APR_WRITE | APR_CREATE | APR_EXCL,
>> - 0, r->pool);
>> + APR_OS_DEFAULT, r->pool);
>> if (rv != APR_SUCCESS) {
>> return rv;
>> }
>>
>> Thanks,
>>
>> Jeff
>
>
>
>
--
Tacio A.G. dos SantosE-mail: [EMAIL PROTECTED]
FhI FOKUS / Global Networking (GloNe)Tel: +49-30-3463-7154
Kaiserin-Augusta-Allee 31Fax: +49-30-3463-8287
D-10589 Berlin, Germany
Re: httpd-2.0.36 - mod_cache problems
"Tacio A.G. Santos" <[EMAIL PROTECTED]> writes: > Thanks , >It solved the problem with file permission, but there's still a > problem with the content type. Thanks for the quick feedback on my simple fix. Hopefully the smart people can help you with the content type problem. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: httpd-2.0.36 - mod_cache problems
Thanks ,
It solved the problem with file permission, but there's still a
problem with the content type.
For example getting a index.html file i get in the first request:
2 Date: Thu, 23 May 2002 14:14:46 GMT
3 Server: Apache/1.3.23 (Unix) mod_perl/1.26
4 Content-Location: index.html.en
5 Vary: negotiate,accept-language,accept-charset
6 TCN: choice
7 Last-Modified: Tue, 23 Apr 2002 14:56:35 GMT
8 ETag: "6cb4-5b1-3cc57623;3cc57623"
9 Accept-Ranges: bytes
10 Content-Type: text/html; charset=ISO-8859-1
11 Content-Language: en
12 Via: 1.0 sitak:8080
13 Content-Length: 1457
14 Connection: close
If i try to get it again the following headers are returned:
2 Date: Thu, 23 May 2002 14:21:24 GMT
3 Server: Apache/1.3.23 (Unix) mod_perl/1.26
4 Content-Location: index.html.en
5 Vary: negotiate,accept-language,accept-charset
6 TCN: choice
7 ETag: "6cb4-5b1-3cc57623;3cc57623"
8 Accept-Ranges: bytes
9 Content-Language: en
10 Via: 1.0 sitak:8080
11 Last-Modified: Tue, 23 Apr 2002 14:56:35 GMT
12 Content-Type: text/plain; charset=ISO-8859-1
13 Content-Length: 1457
14 Connection: close
It just changed the Content-Type to text/plain. It also happens with
image files. Somehow mod_cache is not taking into account the
Content-Type written in the respective cache header file. Does anybody
know where is it set?
Thanks again,
Tacio
Jeff Trawick wrote:
> "Tacio A.G. Santos" <[EMAIL PROTECTED]> writes:
>
>
>>Hi,
>> I'm trying to configure mod_cache+mod_proxy, but mod_cache is not
>>working properly. One thing i found strange is that if you look in the
>>cache directory we have the following strange file permissions:
>>
>>-rw---1 webu webg 2326 May 22 16:41 wkL1JcPol1pQ.data
>>--1 webu webg 355 May 22 16:41
>>wkL1JcPol1pQ.header
>
>
> Perhaps you could try this patch?
>
> Index: mod_disk_cache.c
> ===
> RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_disk_cache.c,v
> retrieving revision 1.33
> diff -u -r1.33 mod_disk_cache.c
> --- mod_disk_cache.c 17 May 2002 11:33:09 - 1.33
> +++ mod_disk_cache.c 23 May 2002 11:59:03 -
> @@ -548,7 +548,7 @@
>
> rv = apr_file_open(&dobj->hfd, dobj->hdrsfile,
> APR_WRITE | APR_CREATE | APR_EXCL,
> - 0, r->pool);
> + APR_OS_DEFAULT, r->pool);
> if (rv != APR_SUCCESS) {
> return rv;
> }
>
> Thanks,
>
> Jeff
Re: httpd-2.0.36 - mod_cache problems
"Tacio A.G. Santos" <[EMAIL PROTECTED]> writes:
> Hi,
>I'm trying to configure mod_cache+mod_proxy, but mod_cache is not
> working properly. One thing i found strange is that if you look in the
> cache directory we have the following strange file permissions:
>
> -rw---1 webu webg 2326 May 22 16:41 wkL1JcPol1pQ.data
> --1 webu webg 355 May 22 16:41
> wkL1JcPol1pQ.header
Perhaps you could try this patch?
Index: mod_disk_cache.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_disk_cache.c,v
retrieving revision 1.33
diff -u -r1.33 mod_disk_cache.c
--- mod_disk_cache.c17 May 2002 11:33:09 - 1.33
+++ mod_disk_cache.c23 May 2002 11:59:03 -
@@ -548,7 +548,7 @@
rv = apr_file_open(&dobj->hfd, dobj->hdrsfile,
APR_WRITE | APR_CREATE | APR_EXCL,
- 0, r->pool);
+ APR_OS_DEFAULT, r->pool);
if (rv != APR_SUCCESS) {
return rv;
}
Thanks,
Jeff
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
httpd-2.0.36 - mod_cache problems
Hi, I'm trying to configure mod_cache+mod_proxy, but mod_cache is not working properly. One thing i found strange is that if you look in the cache directory we have the following strange file permissions: -rw---1 webu webg 2326 May 22 16:41 wkL1JcPol1pQ.data --1 webu webg 355 May 22 16:41 wkL1JcPol1pQ.header If we manually changed it (chmod 600 *) the file is served from disk (cache) otherwise apache gets it again from the originating server. Another problem is that even if it gets from the cache it somehow changes the Content-Type header to text/plain so the browser shows the html source file instead of rendering the page. This test was also performed using the latest (actually yesterday version) httpd2 cvs version. I've started attaching a debugger and digging into the code but i do need some help. Could someone point me where can i get more info about mod_cache? Have i overlooked some simple thing? Does anybody have a suggestion what else should i try? Thanks in advance, Tacio PS: I configure it with: ./configure --prefix=/home2/apps/web/apache2 --enable-proxy=shared \ --enable-proxy-connect=shared --enable-proxy-ftp=shared \ --enable-proxy-http=shared --enable-cache=shared --enable-disk-cache=shared \ --enable-mem-cache=shared 2>&1> log_configure.txt In my httpd.conf i have: ProxyRequests On Order deny,allow Deny from all Allow from .fokus.gmd.de sitak localhost localhost.ailab.fokus.gmd.de ProxyVia On CacheOn On CacheRoot /home2/apps/web/apache2/proxy CacheSize 4096 CacheEnable disk / CacheDirLevels 1 CacheDirLength 5
Re: Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
On Tue, May 21, 2002 at 01:45:25PM -0400, Cliff Woolley wrote: > It's unclear from > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc_r/uthread/uthread_sendfile.c > whether or not the problem is fixed in 4.6PRERELEASE, unless that is > strictly based off of HEAD. There's no tag in that file for it. Changes > definitely went in after 4.5 that would affect this problem. The sendfile libc_r problem was fixed before 4.5 was released and made it into 4.5. That allows files to get served without sending corrupt data. However, threads are only partially supported with -CURRENT (5.0) and are not supported with 4.x at all. BUT, I've heard some success with people using linuxthreads on FreeBSD. I certainly don't have the time (or the platforms) to research this more. -- justin
Re: Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
On Tue, 21 May 2002, Marc G. Fournier wrote: > Okay, I had heard that the 'broken pthreads' was something that was fixed > since 4.5 ... are you saying that this isn't the case? :( Going to > threads was one of my key reasons for moving to Apache2 :( It's unclear from http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc_r/uthread/uthread_sendfile.c whether or not the problem is fixed in 4.6PRERELEASE, unless that is strictly based off of HEAD. There's no tag in that file for it. Changes definitely went in after 4.5 that would affect this problem. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
RE: Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
> From: Marc G. Fournier [mailto:[EMAIL PROTECTED]] > > > Okay, but this is the scenario that I do want (one worker, many threads) > ... so I setup my httpd.conf as: > > > StartServers 1 > MaxClients 150 > MinSpareThreads 25 > MaxSpareThreads 75 > ThreadsPerChild 25 > MaxRequestsPerChild 0 > > > But as soon as I start up, it starts 3 servers (I would expect 2 ... one > root, one nobody): > > atelier# ps aux | grep http > root 59418 0.0 0.1 1416 1052 ph RV+ 1:41PM 0:00.00 grep http > (csh) > root 59405 0.0 0.4 5316 3708 ?? Ss1:39PM 0:00.03 > /usr/local/sbin/httpd > www59406 0.0 0.3 5096 3480 ?? I 1:39PM 0:00.00 > /usr/local/sbin/httpd > www59409 0.0 0.4 7420 4000 ?? I 1:39PM 0:00.00 > /usr/local/sbin/httpd > > With the second one be a good 50% larger then the other two ... > > So, am I mis-understanding below, *or*, mis-understanding the conf file > ... Did you configure cgi? If so, one of those two processes owned by "www" is the CGId process. Ryan
Re: Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
Okay, but this is the scenario that I do want (one worker, many threads) ... so I setup my httpd.conf as: StartServers 1 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 But as soon as I start up, it starts 3 servers (I would expect 2 ... one root, one nobody): atelier# ps aux | grep http root 59418 0.0 0.1 1416 1052 ph RV+ 1:41PM 0:00.00 grep http (csh) root 59405 0.0 0.4 5316 3708 ?? Ss1:39PM 0:00.03 /usr/local/sbin/httpd www59406 0.0 0.3 5096 3480 ?? I 1:39PM 0:00.00 /usr/local/sbin/httpd www59409 0.0 0.4 7420 4000 ?? I 1:39PM 0:00.00 /usr/local/sbin/httpd With the second one be a good 50% larger then the other two ... So, am I mis-understanding below, *or*, mis-understanding the conf file ... On Tue, 21 May 2002, Aaron Bannert wrote: > On Tue, May 21, 2002 at 01:14:00PM -0300, Marc G. Fournier wrote: > > Just to confirm, would it be the following that I'm looking at: > ... > > Nope, further down: > > * FreeBSD, threads, and worker MPM. All seems to work fine > if you only have one worker process with many threads. Add > a second worker process and the accept lock seems to be > lost. This might be an APR issue with how it deals with > the child_init hook (i.e. the fcntl lock needs to be resynced). > More examination and analysis is required. > Status: This has also been reported on Cygwin. > Message-ID: <[EMAIL PROTECTED]> (cygnus) > > Justin says: So, FreeBSD-CURRENT and Cywin have the same >problem. Yum. If another platform has this >with worker, this becomes a showstopper. > Aaron says: I spent some time disecting this and have come to > the conclusion that it is not a problem in the worker MPM > (or at least, it is not isolated to a problem in worker). > I'll list some of the problems I'm seeing in case someone > else wants to pick up where I've left off: >- Delivery of just about any signal to one of the child > processes will send it into an infinite loop as well. >- Even though the parent is spinning out of control, > at first the child or children will appear to work > properly. At times it is possible to get it into a state, > however, where a request will hang until another concurrent > request "kicks" the first, at which point the second will > hang. My theory is that this has to do with the > pthread_cond_*() implementation in FreeBSD, but it's still > possible that it is in APR. > > Justin adds: Oh, FreeBSD threads are implemented entirely with >select()/poll()/longjmp(). Welcome to the nightmare. >So, that means a ktrace output also has the thread >scheduling internals in it (since it is all the same to >the kernel). Which makes it hard to distinguish between >our select() calls and their select() calls. >*bangs head on wall repeatedly* But, some of the libc_r >files have a DBG_MSG #define. This is moderately helpful >when used with -DNO_DETACH. The kernel scheduler isn't >waking up the threads on a select(). Yum. And, I bet >those decrementing select calls have to do with the >scheduler. Time to brush up on our OS fundamentals. > > -aaron >
Re: Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
On Tue, May 21, 2002 at 01:14:00PM -0300, Marc G. Fournier wrote: > Just to confirm, would it be the following that I'm looking at: ... Nope, further down: * FreeBSD, threads, and worker MPM. All seems to work fine if you only have one worker process with many threads. Add a second worker process and the accept lock seems to be lost. This might be an APR issue with how it deals with the child_init hook (i.e. the fcntl lock needs to be resynced). More examination and analysis is required. Status: This has also been reported on Cygwin. Message-ID: <[EMAIL PROTECTED]> (cygnus) Justin says: So, FreeBSD-CURRENT and Cywin have the same problem. Yum. If another platform has this with worker, this becomes a showstopper. Aaron says: I spent some time disecting this and have come to the conclusion that it is not a problem in the worker MPM (or at least, it is not isolated to a problem in worker). I'll list some of the problems I'm seeing in case someone else wants to pick up where I've left off: - Delivery of just about any signal to one of the child processes will send it into an infinite loop as well. - Even though the parent is spinning out of control, at first the child or children will appear to work properly. At times it is possible to get it into a state, however, where a request will hang until another concurrent request "kicks" the first, at which point the second will hang. My theory is that this has to do with the pthread_cond_*() implementation in FreeBSD, but it's still possible that it is in APR. Justin adds: Oh, FreeBSD threads are implemented entirely with select()/poll()/longjmp(). Welcome to the nightmare. So, that means a ktrace output also has the thread scheduling internals in it (since it is all the same to the kernel). Which makes it hard to distinguish between our select() calls and their select() calls. *bangs head on wall repeatedly* But, some of the libc_r files have a DBG_MSG #define. This is moderately helpful when used with -DNO_DETACH. The kernel scheduler isn't waking up the threads on a select(). Yum. And, I bet those decrementing select calls have to do with the scheduler. Time to brush up on our OS fundamentals. -aaron
Re: Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
Just to confirm, would it be the following that I'm looking at: * Generate a good bug report to send to the FreeBSD hackers that details the problems we have seen with threads and system calls (specifically sendfile data is corrupted). From our analysis so far, we don't think that this is an APR issue, but rather a FreeBSD kernel issue. Our current solution is to just disable threads across the board on FreeBSD. MsgID: <[EMAIL PROTECTED]> Status: Fixed in -CURRENT. MFC in about a week. Continuing testing with threads on FreeBSD. FreeBSD PR kern/32684: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/32684 On Tue, 21 May 2002, Aaron Bannert wrote: > > > Just tried the same config on a seperate FreeBSD machine ... both are > > > running 4.6-PRERELEASE right now, and the problem(s) are the same ... > > > connect, hang, kill server and page gets sent across then server goes down > ... > > AFAIK it is still unclear whether APR is the reason, or rather the > > somewhat broken pthreads on FreeBSD Most developers think it's the > > latter. > > A few of us spent some time diagnosing this awhile back, and you > may find our notes in the STATUS file to be of some use. > > -aaron >
Re: Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
> > Just tried the same config on a seperate FreeBSD machine ... both are > > running 4.6-PRERELEASE right now, and the problem(s) are the same ... > > connect, hang, kill server and page gets sent across then server goes down ... > AFAIK it is still unclear whether APR is the reason, or rather the > somewhat broken pthreads on FreeBSD Most developers think it's the > latter. A few of us spent some time diagnosing this awhile back, and you may find our notes in the STATUS file to be of some use. -aaron
Re: Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
On Tue, 21 May 2002, Martin Kraemer wrote: > On Tue, May 21, 2002 at 10:12:17AM -0300, Marc G. Fournier wrote: > > > > Just tried the same config on a seperate FreeBSD machine ... both are > > running 4.6-PRERELEASE right now, and the problem(s) are the same ... > > connect, hang, kill server and page gets sent across then server goes down > > ... > > Same here. And the same probably on every FreeBSD. > Try --with-mpm=prefork which works better. > > AFAIK it is still unclear whether APR is the reason, or rather the > somewhat broken pthreads on FreeBSD Most developers think it's the > latter. Okay, I had heard that the 'broken pthreads' was something that was fixed since 4.5 ... are you saying that this isn't the case? :( Going to threads was one of my key reasons for moving to Apache2 :(
Re: Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
On Tue, May 21, 2002 at 10:12:17AM -0300, Marc G. Fournier wrote: > > Just tried the same config on a seperate FreeBSD machine ... both are > running 4.6-PRERELEASE right now, and the problem(s) are the same ... > connect, hang, kill server and page gets sent across then server goes down > ... Same here. And the same probably on every FreeBSD. Try --with-mpm=prefork which works better. AFAIK it is still unclear whether APR is the reason, or rather the somewhat broken pthreads on FreeBSD Most developers think it's the latter. Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
Just tried the same config on a seperate FreeBSD machine ... both are running 4.6-PRERELEASE right now, and the problem(s) are the same ... connect, hang, kill server and page gets sent across then server goes down ... On Tue, 21 May 2002, Marc G. Fournier wrote: > > Can't describe it much better then that ... I've got it compiled > WITH_THREADS and MPM=worker ... starts fine, get a line in > /var/log/httpd-error.log: > > [Tue May 21 10:01:47 2002] [notice] Digest: generating secret for digest >authentication ... > [Tue May 21 10:01:52 2002] [notice] Digest: done > [Tue May 21 10:01:53 2002] [notice] Apache/2.0.36 (Unix) DAV/2 PHP/4.2.1 configured >-- resuming normal operations > > But when I try to connect to the site in question, the connection just > hangs there ... as soon as I do a 'stop' of the server, though, the page > is sent and then httpd terminates ... > > I'm running with settings of: > > > StartServers 1 > MaxClients 128 > MinSpareThreads 5 > MaxSpareThreads 15 > ThreadsPerChild 64 > MaxRequestsPerChild 0 > > > And am getting no errors that I can find ... > > ps shows: > > earth# ps aux | grep http > root78796 0.0 0.1 9764 6012 ?? SsJ 10:06AM 0:00.11 /usr/local/sbin/httpd > nobody 78799 0.0 0.1 9268 4944 ?? SJ 10:06AM 0:00.01 /usr/local/sbin/httpd > nobody 78825 0.0 0.2 15044 6640 ?? IJ 10:06AM 0:00.03 /usr/local/sbin/httpd > > Which I find kinda odd since I'm not getting that many hits, and told it > to only start with one :( > > Thoughts as to what I should look at here? I've even enabled the > 'apache_runtime_status' file, and that appears to make no difference ... > > > >
Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
Can't describe it much better then that ... I've got it compiled WITH_THREADS and MPM=worker ... starts fine, get a line in /var/log/httpd-error.log: [Tue May 21 10:01:47 2002] [notice] Digest: generating secret for digest authentication ... [Tue May 21 10:01:52 2002] [notice] Digest: done [Tue May 21 10:01:53 2002] [notice] Apache/2.0.36 (Unix) DAV/2 PHP/4.2.1 configured -- resuming normal operations But when I try to connect to the site in question, the connection just hangs there ... as soon as I do a 'stop' of the server, though, the page is sent and then httpd terminates ... I'm running with settings of: StartServers 1 MaxClients 128 MinSpareThreads 5 MaxSpareThreads 15 ThreadsPerChild 64 MaxRequestsPerChild 0 And am getting no errors that I can find ... ps shows: earth# ps aux | grep http root78796 0.0 0.1 9764 6012 ?? SsJ 10:06AM 0:00.11 /usr/local/sbin/httpd nobody 78799 0.0 0.1 9268 4944 ?? SJ 10:06AM 0:00.01 /usr/local/sbin/httpd nobody 78825 0.0 0.2 15044 6640 ?? IJ 10:06AM 0:00.03 /usr/local/sbin/httpd Which I find kinda odd since I'm not getting that many hits, and told it to only start with one :( Thoughts as to what I should look at here? I've even enabled the 'apache_runtime_status' file, and that appears to make no difference ...
Re: FW: Apache 2.0.36 and xcopy on WinNT
At 03:00 PM 05/10/2002, William A. Rowe, Jr. wrote: >At 01:18 PM 5/10/2002, you wrote: >>At 01:55 PM 05/10/2002, William A. Rowe, Jr. wrote: >>>Ahhh. Win95 and forward do support the /y flag. Since WinNT does >>>not, I'll revert the change that presumed our modern >>>command.com/cmd.exe based xcopy'ies all work. >>> >>>Expect a fix in .37 - thanks for the report! >> >>You can put the /y switch in the COPYCMD environment >>variable. WinNT's xcopy ignores this, but Win2K's will pick it up. > >Won't solve the problem. You have no idea how many 'Y's they must >push, nor how that will break in-IDE builds :-) Will revert to the >old <.y. What do you mean by "how many 'Y's they must push"? I also don't see how it can break in-IDE builds. We use it with in-IDE builds all the time. If you're worried about it affecting other xcopy commands, set the COPYCMD variable to /y, call xcopy, and then clear it again. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: FW: Apache 2.0.36 and xcopy on WinNT
At 01:18 PM 5/10/2002, you wrote: >At 01:55 PM 05/10/2002, William A. Rowe, Jr. wrote: >>Ahhh. Win95 and forward do support the /y flag. Since WinNT does not, >>I'll revert the change that presumed our modern command.com/cmd.exe based >>xcopy'ies all work. >> >>Expect a fix in .37 - thanks for the report! > >You can put the /y switch in the COPYCMD environment variable. WinNT's >xcopy ignores this, but Win2K's will pick it up. Won't solve the problem. You have no idea how many 'Y's they must push, nor how that will break in-IDE builds :-) Will revert to the old <.y.
Re: FW: Apache 2.0.36 and xcopy on WinNT
At 01:55 PM 05/10/2002, William A. Rowe, Jr. wrote: >Ahhh. Win95 and forward do support the /y flag. Since WinNT does >not, I'll revert the change that presumed our modern >command.com/cmd.exe based xcopy'ies all work. > >Expect a fix in .37 - thanks for the report! You can put the /y switch in the COPYCMD environment variable. WinNT's xcopy ignores this, but Win2K's will pick it up. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: FW: Apache 2.0.36 and xcopy on WinNT
Ahhh. Win95 and forward do support the /y flag. Since WinNT does not, I'll revert the change that presumed our modern command.com/cmd.exe based xcopy'ies all work. Expect a fix in .37 - thanks for the report! Bill At 12:11 PM 5/10/2002, you wrote: >Hello Sir, > >I sent this to [EMAIL PROTECTED] a couple days ago. I don't >know whether there's just a slow turnaround, or whether it was >deemed unworthy of posting? Anyway, I think it's worthy :-) > >I cannot seem to find a an xcopy.exe that works for the >httpd-2.0.36 build on NT. I've tried several versions and they >all have some problem. If I get one that works for libhttpd.dsp >(i.e., supports /y) then it barfs elsewhere like not supporting >/S or getting into an infinite loop in Makefile.win. Or if I try >the one from my Win98 machine (that works on that platform) it >won't run on NT (wrong DOS version it sez, or somesuch). I've >also had colleagues try xcopy /y on other installs of NT (e.g., >with SP 6), none support /y. So I suspect this will give lots >of people grief on NT. > >I haven't tried it, but maybe the same approach as used in >Makefile.win will work? > > echo Y > .y > del .\include\mpm.h > copy .\server\mpm\winnt\mpm.h .\include\mpm.h < .y > del .y > >Maybe not so pretty but at least it should be portable. > >Thanks for listening, > >-Roland > >-Original Message- >From: Mechler, Roland >Sent: Wednesday, May 08, 2002 6:03 PM >To: '[EMAIL PROTECTED]' >Subject: Apache 2.0.36 and xcopy on WinNT > > >Hi, the xcopy.exe on my installation of NT 4.0 (Service Pack 4) does >not support the /y switch, so the change in libhttpd.dsp broke the >build for me. I could get a version that works, but IMHO it >would be better to go back to the more portable way despite the >'foo.h not found' messages. > >Cheers, > >-Roland
Re: 2.0.36
Jerry Baker wrote: > > There is no "-no_src" version there that I can see. Just > apache_2.0.36-win32-x86-no_ssl.msi. > > -- > Jerry Baker It took me reading that a few times to realize that it was only applicable to the 1.3.X releases. I'm not sure how to make it more clear though. -- Jerry Baker
Re: 2.0.36
At 10:50 AM 5/10/2002, you wrote: >"William A. Rowe, Jr." wrote: > > > > Not acked. Would anyone care to reread the notes at /dist/httpd/ and > > /dist/httpd/binaries/win32/ and see if they can figure out how someone > > fails to get from 'here' to 'there'? As I just revised 'em, apparently my > > reasoning was incomplete. Another set of eyes would be great. > >Well, http://www.apache.org/dist/httpd/binaries/win32/ says: > >"The two -no_src versions, both the .exe and .msi installers DO NOT >contain the source code. There is no other difference, and if you do not >know the C language, or have no C compiler installed, these versions are >faster to download. There is no other difference between these packages >and the -src .msi version." > >There is no "-no_src" version there that I can see. Just >apache_2.0.36-win32-x86-no_ssl.msi. ahhh. Now I see confusion. You would be reading the 1.3 section. If you follow to the 2.0 section, I believe I spelled out that we don't know how we want to blend the source tree into a distro, so the 2.0 section spells out where to find the sources. For starters, it's probably time to reverse the 1.3 and 2.0 sections. And spell out apache_1.3.x-win32-x86-no_src.msi so it's not so ambigious. I'll get to those over the weekend.
Re: 2.0.36
"William A. Rowe, Jr." wrote: > > Not acked. Would anyone care to reread the notes at /dist/httpd/ and > /dist/httpd/binaries/win32/ and see if they can figure out how someone > fails to get from 'here' to 'there'? As I just revised 'em, apparently my > reasoning was incomplete. Another set of eyes would be great. Well, http://www.apache.org/dist/httpd/binaries/win32/ says: "The two -no_src versions, both the .exe and .msi installers DO NOT contain the source code. There is no other difference, and if you do not know the C language, or have no C compiler installed, these versions are faster to download. There is no other difference between these packages and the -src .msi version." There is no "-no_src" version there that I can see. Just apache_2.0.36-win32-x86-no_ssl.msi. -- Jerry Baker
Re: 2.0.36
Not acked. Would anyone care to reread the notes at /dist/httpd/ and /dist/httpd/binaries/win32/ and see if they can figure out how someone fails to get from 'here' to 'there'? As I just revised 'em, apparently my reasoning was incomplete. Another set of eyes would be great. At 09:57 AM 5/10/2002, Ken Coar writes: >Not acked. Please Cc me when responding. > >- Forwarded message from Marc Pitoniak <[EMAIL PROTECTED]> >- > >From: "Marc Pitoniak" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Subject: 2.0.36 >Date: Wed, 8 May 2002 14:42:14 -0500 >Importance: Normal > >Are you planning on providing a Win-32 no source-precompiled installation >for version 2.0.36? > >Thank you very much. > >Marc Pitoniak
Re: 2.0.36
Not acked. Please Cc me when responding. - Forwarded message from Marc Pitoniak <[EMAIL PROTECTED]> - From: "Marc Pitoniak" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: 2.0.36 Date: Wed, 8 May 2002 14:42:14 -0500 Importance: Normal Are you planning on providing a Win-32 no source-precompiled installation for version 2.0.36? Thank you very much. Marc Pitoniak - End forwarded message - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: 2.0.36 .zip files WAS, RE: 2.0.36 release
At 01:40 PM 5/6/2002, you wrote: >Hi, > >Is there any special voodoo to be performed to create the apache release >zip files? The nastiest. Need to build all, then export make files (so that all dependent files exist when creating dependencies) ... and pack up .mak, .dep, and .rc (awk version resource stubs) along with cr/lf'ed files. Really requires VC5 or 6. I started some of that jazz in my win_compiling.html file, and had started a file on how-to-roll-the-win32 zip files. I'll try to wrap that up. ITMT, I'll put together this .zip in a bit and try rolling a 2.0.36 binary for release. No later than tommorow morning. >Could we document this somewhere? I'll try to recall where I left things and pick them back up where I left off.
2.0.36 .zip files WAS, RE: 2.0.36 release
Hi, Is there any special voodoo to be performed to create the apache release zip files? Could we document this somewhere? Sander
Re: 2.0.36 release
"Cliff Woolley" <[EMAIL PROTECTED]> wrote: > On Mon, 6 May 2002, Pier Fumagalli wrote: > >> No segfaults on worker un nagoya whatsoever... > > Great! Thanks for testing it out. Was about time that we updated HTTPd on there... And Nagoya is the perfect place to test out multi-threaded stuff (6 procs on Solaris 8) >> The only thing "nagging" me is: >> [Mon May 06 00:01:15 2002] [warn] child process 18743 still did not exit, >> sending a SIGTERM >> Not always processes die nicely... > > Yeah, that's a known nastiness with 2.0.36's worker. At least it shuts > down, though. We'll clean it up for 2.0.37. Was also in 2.0.35... It's just a PITA because you have to wait 30 secs before doing a startup if one of the children didn't die... -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick
Re: 2.0.36 release
On Mon, 6 May 2002, Pier Fumagalli wrote: > No segfaults on worker un nagoya whatsoever... Great! Thanks for testing it out. > The only thing "nagging" me is: > [Mon May 06 00:01:15 2002] [warn] child process 18743 still did not exit, > sending a SIGTERM > Not always processes die nicely... Yeah, that's a known nastiness with 2.0.36's worker. At least it shuts down, though. We'll clean it up for 2.0.37. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: 2.0.36 release
+1 > > +1 for GA. Let's get this bad boy out the door. I'm sick of dealing with > duplicate PRs on the same three bugs in 2.0.35. :) > > --Cliff >
Re: 2.0.36 release
"Jeff Trawick" <[EMAIL PROTECTED]> wrote: > Cliff Woolley <[EMAIL PROTECTED]> writes: > >> +1 for GA. Let's get this bad boy out the door. > > +1 from me too No segfaults on worker un nagoya whatsoever... The only thing "nagging" me is: [Mon May 06 00:01:15 2002] [warn] child process 18743 still did not exit, sending a SIGTERM [Mon May 06 00:01:15 2002] [warn] child process 18744 still did not exit, sending a SIGTERM [Mon May 06 00:01:15 2002] [warn] child process 18744 still did not exit, sending a SIGTERM [Mon May 06 00:01:16 2002] [warn] child process 18744 still did not exit, sending a SIGTERM [Mon May 06 00:01:21 2002] [error] child process 18744 still did not exit, sending a SIGKILL [Mon May 06 00:01:37 2002] [notice] SIGHUP received. Attempting to restart [Mon May 06 00:01:38 2002] [notice] Apache/2.0.36 (Unix) mod_webapp/1.2.0-dev configured -- resuming normal operations Not always processes die nicely... Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick
Re: 2.0.36 release
Cliff Woolley <[EMAIL PROTECTED]> writes: > +1 for GA. Let's get this bad boy out the door. +1 from me too -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: 2.0.36 release
On Mon, May 06, 2002 at 09:08:53AM +0200, Sander Striker wrote: > If I counted right we have enough +1s for GA. I'll check back here in 12 hours > or so to do the release. I won't have time before that, so hold on until then ;) I'm +1 for GA here, but beware that byterange is broken when using dynamic content. It was broken in 2.0.35, so this isn't new (and why I'll still vote for GA). I'm finishing up a rewrite that should fix that. Expect a commit shortly. -- justin
RE: 2.0.36 release
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]] > Sent: 06 May 2002 07:02 > +1 for GA. Let's get this bad boy out the door. I'm sick of dealing with > duplicate PRs on the same three bugs in 2.0.35. :) > > --Cliff If I counted right we have enough +1s for GA. I'll check back here in 12 hours or so to do the release. I won't have time before that, so hold on until then ;) Sander PS. Unless it wasn't obvious already +1 for GA... :)
2.0.36 release
+1 for GA. Let's get this bad boy out the door. I'm sick of dealing with duplicate PRs on the same three bugs in 2.0.35. :) --Cliff
Re: Final bump and roll of 2.0.36
+1 2.0.36 is better, plain and simple :) Cliff Woolley wrote: > > On Thu, 2 May 2002, Greg Ames wrote: > > > ...and no emails reporting strange behavior on the site. +1 for beta. > > +1 for beta from me as well. > > > What about GA? > > IMO: > > pros: > * we do people more of a disservice by continue to have them use 2.0.35 >and find already fixed bugs than by throwing another release at them >three weeks later > * what you said > > cons: > * worker shutdown is still wonky, at least on linux. part of me would >have rather seen it segfault. but just stick a warning in the release >notes to be wary of the potential rough edges there, and I'm okay with >it > > --Cliff > > -- >Cliff Woolley >[EMAIL PROTECTED] >Charlottesville, VA > > -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
RE: Final bump and roll of 2.0.36
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]] > Sent: 02 May 2002 18:09 > On Thu, 2 May 2002, Greg Ames wrote: > >> ...and no emails reporting strange behavior on the site. +1 for beta. > > +1 for beta from me as well. Likewise. >> What about GA? > > IMO: > > pros: > * we do people more of a disservice by continue to have them use 2.0.35 >and find already fixed bugs than by throwing another release at them >three weeks later > * what you said > > cons: > * worker shutdown is still wonky, at least on linux. part of me would >have rather seen it segfault. but just stick a warning in the release >notes to be wary of the potential rough edges there, and I'm okay with >it +1. Lets give it the rest of the week and the weekend. Start moving for announce of GA on monday. Sander
Re: Final bump and roll of 2.0.36
On Thu, 2 May 2002, Greg Ames wrote: > ...and no emails reporting strange behavior on the site. +1 for beta. +1 for beta from me as well. > What about GA? IMO: pros: * we do people more of a disservice by continue to have them use 2.0.35 and find already fixed bugs than by throwing another release at them three weeks later * what you said cons: * worker shutdown is still wonky, at least on linux. part of me would have rather seen it segfault. but just stick a warning in the release notes to be wary of the potential rough edges there, and I'm okay with it --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: Final bump and roll of 2.0.36
I will be +1 for GA of 2.0.36 if it runs for 3 days w/o problems on daedalus. I'm not concerned with release announcements. 2.0.35 has some bugs which prevent it from being used in production. 2.0.36 eliminates these bugs. This really should have been our first GA release, not 2.0.35 :-) Bill > Greg Ames wrote: > > > > Sander Striker wrote: > > > > Tarballs are available at: > > > httpd.apache.org/dev/dist/ > > > > > Please test and vote accordingly ;) > > > > It's running on daedalus since Wednesday, 01-May-2002 18:18:16 PDT with no > > apparent problems. I'll check it tomorrow, then vote. > > [gregames@daedalus gregames]$ ls /tmp/httpd.core > ls: /tmp/httpd.core: No such file or directory > [gregames@daedalus gregames]$ ls /usr/local/apache/corefiles/ > [gregames@daedalus gregames]$ > > ...and no emails reporting strange behavior on the site. +1 for beta. > > What about GA? > > pros: > > * The code seems more stable than 2.0.35. No big surprise; .36 wasn't rushed. > * worker's performance has improved noticably > * bunches of PRs have been fixed > > cons: > > * The exact release tarball hasn't run problem free for 3 days on daedalus yet > * It hasn't been very long since 2.0.35 was released. I worry a little bit > about overloading people with release announcements, plus it's a bunch of work > for us. > > IMO, the pros outweigh the cons, especially if we wait a few days. > > Greg >
Re: Final bump and roll of 2.0.36
Greg Ames wrote: > > Sander Striker wrote: > > Tarballs are available at: > > httpd.apache.org/dev/dist/ > > > Please test and vote accordingly ;) > > It's running on daedalus since Wednesday, 01-May-2002 18:18:16 PDT with no > apparent problems. I'll check it tomorrow, then vote. [gregames@daedalus gregames]$ ls /tmp/httpd.core ls: /tmp/httpd.core: No such file or directory [gregames@daedalus gregames]$ ls /usr/local/apache/corefiles/ [gregames@daedalus gregames]$ ...and no emails reporting strange behavior on the site. +1 for beta. What about GA? pros: * The code seems more stable than 2.0.35. No big surprise; .36 wasn't rushed. * worker's performance has improved noticably * bunches of PRs have been fixed cons: * The exact release tarball hasn't run problem free for 3 days on daedalus yet * It hasn't been very long since 2.0.35 was released. I worry a little bit about overloading people with release announcements, plus it's a bunch of work for us. IMO, the pros outweigh the cons, especially if we wait a few days. Greg
Re: Final bump and roll of 2.0.36
"William A. Rowe, Jr." wrote: > > Ok... now I see your second post - tack on this discrepancy and retitle > the bug "Some versions of awk disagree with Win32 builds". Cygwin Awk Incompatible With Apache Build http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8726 -- Jerry Baker
Re: Final bump and roll of 2.0.36
At 06:15 PM 5/1/2002, Jerry Baker wrote: >I assume that pulling the APACHE_2_0_36 tag gets me the same things >as the aforementioned tarballs? If so, built and ran on Windows XP ok. > >PS - There is some trouble with a couple of the awk actions on >Windows XP at least. The following lines from makefile.win >result in a crash: > >awk -f <> "$(INSTDIR)\LICENSE.txt" >awk -f <"$(INSTDIR)\conf\httpd.default.conf" "$(INSTDIR)" >awk -f <"$(INSTDIR)\bin\dbmmanage.pl" > >Each one of these lines causes the following error: > >"The NTVDM CPU has encountered an illegal instruction. CS:0596 IP:001d >OP: ff ff ff ff ff Chose 'Close' to terminate the application." Sure sounds like a bug in your awk implementation. Which one/version number? We already have a report 8008 (djgpp 3.06)... you might want to note this discrepancy as well. If there is a syntax error in those scripts, I'm not seeing it. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8008 >Don't worry too much. This has been going on for quite some time. I won't... but keep us in the loop when things go nutty :-) Ok... now I see your second post - tack on this discrepancy and retitle the bug "Some versions of awk disagree with Win32 builds".
Re: Final bump and roll of 2.0.36
Sander Striker wrote: > > Hi, > > I've done the final bump. > > Tarballs are available at: > httpd.apache.org/dev/dist/ > Please test and vote accordingly ;) It's running on daedalus since Wednesday, 01-May-2002 18:18:16 PDT with no apparent problems. I'll check it tomorrow, then vote. Greg
Re: Final bump and roll of 2.0.36
Sander Striker wrote: >Hi, > >I've done the final bump. Files marked with a [T] have made it to the >roll. Files marked with [-] haven't. I have included the logs of the >changes for your convenience. Lines marked RM: are lines with my commentary. > >Tarballs are available at: > httpd.apache.org/dev/dist/ > >I haven't had the time to create zipfiles yet, sorry. > >Please test and vote accordingly ;) > Tested on Solaris (worker MPM) +1 --Brian
Re: Final bump and roll of 2.0.36
Jerry Baker wrote: > > Don't worry too much. This has been going on for quite some time. > Nevermind. Sorry. It was a problem with the Cygwin awk.exe. It isn't really an executable, but a symlink to gawk.exe. Problem is that Windows doesn't have symlinks. Renaming gawk.exe to awk.exe fixed it. :::stupid redhat::: -- Jerry Baker
Re: Final bump and roll of 2.0.36
Sander Striker wrote: > > Hi, > > I've done the final bump. Files marked with a [T] have made it to the > roll. Files marked with [-] haven't. I have included the logs of the > changes for your convenience. Lines marked RM: are lines with my commentary. > > Tarballs are available at: > httpd.apache.org/dev/dist/ > > I haven't had the time to create zipfiles yet, sorry. > > Please test and vote accordingly ;) > > Sander I assume that pulling the APACHE_2_0_36 tag gets me the same things as the aforementioned tarballs? If so, built and ran on Windows XP ok. PS - There is some trouble with a couple of the awk actions on Windows XP at least. The following lines from makefile.win result in a crash: awk -f <> "$(INSTDIR)\LICENSE.txt" awk -f <"$(INSTDIR)\bin\dbmmanage.pl" Each one of these lines causes the following error: "The NTVDM CPU has encountered an illegal instruction. CS:0596 IP:001d OP: ff ff ff ff ff Chose 'Close' to terminate the application." Don't worry too much. This has been going on for quite some time. -- Jerry Baker
Re: Final bump and roll of 2.0.36
Ben? Is Ben in the house? david > On Wed, May 01, 2002 at 11:40:13PM +0200, Sander Striker wrote: > > Tarballs are available at: > > httpd.apache.org/dev/dist/ > > +1 for beta. > > Passes httpd-test except for OpenSSL tests which seem to be confused > by recent changes in OpenSSL in the Email oid to now be emailAddress. > > Current OpenSSL snapshots have in crypto/objects/objects.txt: > pkcs9 1 : : emailAddress > > OpenSSL 0.9.6b has in crypto/objects/objects.txt: > pkcs9 1 : Email : emailAddress > > I'll assume that this is why none of the client cert tests are > working. *sigh* This doesn't look like anything we can > do, but I'm not 100% sure. -- justin >
Re: Final bump and roll of 2.0.36
On Wed, May 01, 2002 at 11:40:13PM +0200, Sander Striker wrote: > Tarballs are available at: > httpd.apache.org/dev/dist/ +1 for beta. Passes httpd-test except for OpenSSL tests which seem to be confused by recent changes in OpenSSL in the Email oid to now be emailAddress. Current OpenSSL snapshots have in crypto/objects/objects.txt: pkcs9 1 : : emailAddress OpenSSL 0.9.6b has in crypto/objects/objects.txt: pkcs9 1 : Email : emailAddress I'll assume that this is why none of the client cert tests are working. *sigh* This doesn't look like anything we can do, but I'm not 100% sure. -- justin
Final bump and roll of 2.0.36
Hi, I've done the final bump. Files marked with a [T] have made it to the roll. Files marked with [-] haven't. I have included the logs of the changes for your convenience. Lines marked RM: are lines with my commentary. Tarballs are available at: httpd.apache.org/dev/dist/ I haven't had the time to create zipfiles yet, sorry. Please test and vote accordingly ;) Sander = httpd-2.0 = [T] Apache.dsw (1.79) wrowe Log: Always build this experimental module (which has no library dependencies). Build failure reported by Jerry Baker to dev@httpd - [T] BuildBin.dsp (1.4) wrowe Log: Should correctly build mod_ext_filter, mod_deflate dependant upon zlib, and change the license-add code for openssl+zlib based on the newest changes to a global LICENSE for all bundled components. - [T] CHANGES (1.751) RM: Updated prior to retagging. - [T] Makefile.win (1.98) wrowe Log: Should correctly build mod_ext_filter, mod_deflate dependant upon zlib, and change the license-add code for openssl+zlib based on the newest changes to a global LICENSE for all bundled components. - [T] NWGNUmakefile (1.5) [T] build/NWGNUenvironment.inc (1.2) bnicholes Log: Fixing up the distribution and install section of the NetWare make files Submitted by: Guenter Knauf - [T] docs/manual/server-wide.html.en (1.8) [T] docs/manual/server-wide.html.ja.jis (1.5) [T] docs/manual/mod/mod_cache.xml (1.2) [T] docs/manual/platform/win_compiling.html (1.11) RM: documentation changes always have to go in IMO. - [T] include/ap_mmn.h (1.43) wrowe Log: Demote to a minor bump for .36 - those affected by API changes should be a very small subset of modules. Here are the afflicted types & fns; apr_explode_time -> apr_time_exp_tz apr_explode_localtime -> apr_time_exp_lt apr_get_groupname -> apr_group_name_get deprecated apr_lock_t, apr_os_lock_t and fns, but the warnings have been there a while so no sympathy. added dav_hooks_search_t and DASL Search functions. added apr_cmdtype_e *type arg to mod_cgi opt fn ap_cgi_build_command. added proxy_fixups hook and ap_proxy_ssl_disable, and optional fn ssl_engine_disable. RM: Personally don't have strong feelings about this. At the lack of feedback I assume everyone lazily agrees. Thus the bump. - [T] modules/NWGNUmakefile (1.2) [T] modules/experimental/NWGNUdeflate (1.1) [T] modules/experimental/NWGNUdsk_cach (1.1) [T] modules/experimental/NWGNUexample (1.1) [T] modules/experimental/NWGNUmakefile (1.2) [T] modules/experimental/NWGNUmem_cach (1.1) [T] modules/experimental/NWGNUmod_cach (1.1) bnicholes Log: NetWare make files for building experimental modules mod_deflate, mod_example and support utilities ab, htdbm and logresolve Submitted by: Guenter Knauf [[EMAIL PROTECTED]] bnicholes Log: NetWare make files for building experimental module mod_cache and its associated support modules. Submitted by: Jean-Jacques Clar [[EMAIL PROTECTED]] - [T] modules/experimental/mod_mem_cache.c (1.50) stoddard Log: Name space protect mod_mem_cache config directives stoddard Log: Forget to update the error messages stoddard Log: remove_entity should only work on complete cache_objects stoddard Log: Enable mod_mem_cache to be configured to cache open file handle using new directive option: CacheEnable fd / will enable caching fds. If for some reason the fd cannot be cached, the directive will effectively morph into CacheEnable mem / - [T] modules/proxy/NWGNUproxy bnicholes Log: Added some missing export to the proxy module Submitted by: Guenter Knauf - [T] modules/ssl/README (1.33) [T] modules/ssl/mod_ssl.c (1.64) [T] modules/ssl/ssl_engine_log.c (1.18) [T] modules/ssl/ssl_scache_shmcb.c (1.12) jwoolley Log: note a desirable goal jwoolley Log: Revert optimization from circa 2.0.34 that caused very long vhost id's to be unusable with mod_ssl. PR: 8572 jwoolley Log: - Sync with modssl 2.8.8-1.3.24 - Also a minor change to add more useful error logging for shmcb startup failures jwoolley Log: SHMCB should not have be
Re: Roll of 2.0.36, WAS: RE: cvs commit: httpd-2.0/server/mpm/worker worker.c
Sander Striker wrote: > I was going to roll 2.0.36, but I want to wait for this last > worker change. Unfortunately I don't have the time to pursue > the issue now, so if someone does, please feel free to take > care of this annoying beast. BTW: Is there any problem with the CVS version of mod_cache? Accroding to the latest "nightly build log" of Chuck: > Making in httpd-2.0-nightly > In file included from mod_cache.c:61: > mod_cache.h:213: syntax error before `apr_atomic_t' > In file included from cache_storage.c:61: > mod_cache.h:213: syntax error before `apr_atomic_t' > In file included from cache_util.c:61: > mod_cache.h:213: syntax error before `apr_atomic_t' -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel
Re: Roll of 2.0.36, WAS: RE: cvs commit: httpd-2.0/server/mpm/worker worker.c
"Sander Striker" <[EMAIL PROTECTED]> writes: > Hi, > > I was going to roll 2.0.36, but I want to wait for this last > worker change. Unfortunately I don't have the time to pursue > the issue now, so if someone does, please feel free to take > care of this annoying beast. I'll start working on it now. It shouldn't be hard to add a join for graceless termination. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Roll of 2.0.36, WAS: RE: cvs commit: httpd-2.0/server/mpm/worker worker.c
Hi, I was going to roll 2.0.36, but I want to wait for this last worker change. Unfortunately I don't have the time to pursue the issue now, so if someone does, please feel free to take care of this annoying beast. Sander > From: Sander Striker [mailto:[EMAIL PROTECTED]] > Sent: 01 May 2002 15:11 >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick >> Sent: 01 May 2002 14:53 [...] >> (My apologies for not keeping up with the discussions over the past >> days.) >> >> I don't see (yet) which segfault this would fix. Maybe I was hoping >> for a fix to the wrong problem... >> >> If this was to be combined with a change to do a thread-join on the >> workers even for graceless termination, then I can see how the >> segfault caused by cleaning up a pool that the worker threads depend >> on would be avoided. (But of course a thread-join on a worker could >> hang for a while, depending on what a 3rd-party module is doing.) >> >> This change alone doesn't do much for the race between the main thread >> cleaning up pchild and the worker threads getting dispatched and >> realizing that they can exit and finally finishing their use of data >> in subpools of pchild and doing the pthread_exit(). > > Grmpf. Ofcourse, you are correct. We need the thread_join as a patch > job. After 2.0.36 I am afraid we have to implement apr_thread_cancel... > > Sander >
Re: Release 2.0.36
Greg Ames <[EMAIL PROTECTED]> writes: > The other is a sendfile assert that we've seen intermittently for a long time. > Jeff thinks the FreeBSD kernel is giving us a return value of 0 with no bytes > sent. I think we might be passing a length or an offset that's too big, perhaps > when the site is updated after we stat() the file. I plan to write traps to > test both theories. Here's what I think in a little more detail: [I suspect that] Both FreeBSD and Linux sendfile() will return 0 in some conditions where it sends no bytes. The conditions? Bogus offset/length combination. I just verified that on Linux I get return code 0 from sendfile() when asking it to send 8192 bytes starting at offset 9 in a file that is much smaller than that. The file offset was updated to 9. (It seems that sendfile picks up some semantics from sparse file support in seek-type operations.) Why would we give sendfile a bogus offset/length combination? a couple of possible reasons: a) like you said, the file size could change during the request (a definite problem) b) we bungle the processing somehow and come up with a bogus file bucket -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Release 2.0.36
Sander Striker wrote: > What is the current status on 2.0.36-dev? > Are we still core dumping on daedalus? How > close are we to finding/fixing the problem > we are seeing there? > > Greg (Ames), can you holler when you've > seen daedalus run for 3 days without dumping > core? ;) (sorry for the delay...just catching up on e-mail after an outage last week) daedalus has had only 2 core dumps in about 10 days. One was a mmap cleanup issue which Cliff has a promising looking fix for in 2.0.36. The other is a sendfile assert that we've seen intermittently for a long time. Jeff thinks the FreeBSD kernel is giving us a return value of 0 with no bytes sent. I think we might be passing a length or an offset that's too big, perhaps when the site is updated after we stat() the file. I plan to write traps to test both theories. So I don't know of any reason why 2.0.36 won't be stable. Greg
daedalus is running httpd-2.0.36
..since Thursday, 25-Apr-2002 17:22:00 PDT. Nothing unusual to report. Let's hope it stays that way. Greg
Re: 2.0.36 tagged
"Sander Striker" <[EMAIL PROTECTED]> writes: > - atomics compile issue > >This bites us on some versions of Linux. >If we cannot resolve this within a reasonable >timeframe I suggest we fall back to the default >implementation on troublesome platforms for this >release*. Should we consider adding --disable-atomic to APR for the time being to allow people to work around the inability to compile that stuff on some software combinations? (I haven't really followed the problems closely; I just know that a number of people have encountered such problems on Solaris and Linux. Maybe the problems are mostly due to bad build tool setup and we'd be better off trying to detect common problems and issuing a message that would help them fix it.) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
2.0.36 tagged
Hi, I just tagged HEAD as 2.0.36. One exception: I tagged support/ab.c rev 1.97 instead of 1.98. Simply because I think that change deserves some discussion. Greg, could you upgrade daedalus to 2_0_36? It would be nice to see how it holds under load. Showstoppers we have to take care of (tag will be bumped accordingly): - worker restart/shutdown issue pchild goes away while threads are still accessing memory allocated out of it (or its child pools). Aaron was working on a fix that closes all connected sockets on shutdown. - atomics compile issue This bites us on some versions of Linux. If we cannot resolve this within a reasonable timeframe I suggest we fall back to the default implementation on troublesome platforms for this release*. Sander *) assuming this tag will make it to release ;)
Re: Volunteering to be RM, WAS: RE: Release 2.0.36
Sander Striker wrote: > > If your commit solved the prob, the worker restart issue is > the remaining holdup for 2.0.36. I'll tag by the end of the day. > Crossing fingers... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
RE: Volunteering to be RM, WAS: RE: Release 2.0.36
> From: Jim Jagielski [mailto:[EMAIL PROTECTED]] > Sent: 23 April 2002 19:57 > Justin Erenkrantz wrote: > > > > The reason I suggested a hold to Sander on account of the atomics > > is that we have a bunch of PRs relating to building atomics on > > Solaris that haven't been (yet) resolved. > > > > Hold on a tic... I think I see it... On the systems that fail, > I bet they are using GNUas. If so, then ASCPP is 'gcc -E' and thus > the modification of apr_atomic_sparc.s to apr_atomic_sparc.S fails. > If not using GNUas, apr_atomic_sparc.S simply *is* apr_atomic_sparc.s. > So, the problem is what is it in apr_atomic_sparc.s that makes GNUas > barf. If your commit solved the prob, the worker restart issue is the remaining holdup for 2.0.36. I'll tag by the end of the day. Sander
Re: Release 2.0.36
On Thu, Apr 18, 2002 at 07:33:54AM -0500, William A. Rowe, Jr. wrote: >... > If I can get that semantics change done on optional fns/hooks so we can > avoid all mmn version bumps for optional fn/hooks, I think that would also > cut down on the bumps for foreign modules. Will look to make some > progress and post an example patch by Friday morning. Well, you always want to do a minor bump when you introduce new APIs. A minor bump should not invalidate any old code, but it provides a way for modules to recognize when new APIs are available (especially nice with the optional hooks, but also fine for compile-time). Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Volunteering to be RM, WAS: RE: Release 2.0.36
Justin Erenkrantz wrote: > > The reason I suggested a hold to Sander on account of the atomics > is that we have a bunch of PRs relating to building atomics on > Solaris that haven't been (yet) resolved. > Hold on a tic... I think I see it... On the systems that fail, I bet they are using GNUas. If so, then ASCPP is 'gcc -E' and thus the modification of apr_atomic_sparc.s to apr_atomic_sparc.S fails. If not using GNUas, apr_atomic_sparc.S simply *is* apr_atomic_sparc.s. So, the problem is what is it in apr_atomic_sparc.s that makes GNUas barf. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: Volunteering to be RM, WAS: RE: Release 2.0.36
You know, I don't see this but I wonder if the reason why is because on those systems where it fails, /usr/ccs/bin isn't in their path... Justin Erenkrantz wrote: > > The reason I suggested a hold to Sander on account of the atomics > is that we have a bunch of PRs relating to building atomics on > Solaris that haven't been (yet) resolved. > -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: Volunteering to be RM, WAS: RE: Release 2.0.36
On Tue, Apr 23, 2002 at 02:00:25PM +0200, Sander Striker wrote: > Hi, > > I volunteer to be RM for 2.0.36 (that is, if noone > has a problem with that ;). > > I'm aware of the issues we still have in HEAD, which > is why we need a tag and run that on daedalus. > > However, I'll hold of on the tag since there are > probably going to be some file moves in the atomics > section. When that is done, we can tag. The tag > can be bumped for the worker fix (if it's not > already in by then). The reason I suggested a hold to Sander on account of the atomics is that we have a bunch of PRs relating to building atomics on Solaris that haven't been (yet) resolved. I believe we could rethink how we are building the atomics to make it a bit less troublesome. I'd rather see us use CPU-based defines rather than OS-based defines for those platforms where the OS is of no help (Linux, Solaris, and old FreeBSD). Personally, I don't care to spend any more time on the atomics code. If someone wants to see this included, I heartily suggest that it should get fixed soon. -- justin
Re: Volunteering to be RM, WAS: RE: Release 2.0.36
+1 > Hi, > > I volunteer to be RM for 2.0.36 (that is, if noone > has a problem with that ;). > > I'm aware of the issues we still have in HEAD, which > is why we need a tag and run that on daedalus. > > However, I'll hold of on the tag since there are > probably going to be some file moves in the atomics > section. When that is done, we can tag. The tag > can be bumped for the worker fix (if it's not > already in by then). > > Thoughts? > > Sander >
Volunteering to be RM, WAS: RE: Release 2.0.36
Hi, I volunteer to be RM for 2.0.36 (that is, if noone has a problem with that ;). I'm aware of the issues we still have in HEAD, which is why we need a tag and run that on daedalus. However, I'll hold of on the tag since there are probably going to be some file moves in the atomics section. When that is done, we can tag. The tag can be bumped for the worker fix (if it's not already in by then). Thoughts? Sander
RE: Release 2.0.36
On Mon, 22 Apr 2002, Sander Striker wrote: > - allocate the sockets out of a special pool so we can clean up the > sockets (using apr_pool_clear(psock)), sleep for 1 sec (should be enough > for all threads to notice the sockets are gone). After that clean > pchild as usual. >From my uninformed perspective, this sounds like a good compromise... --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
RE: Release 2.0.36
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick > Sent: 22 April 2002 16:33 > "Sander Striker" <[EMAIL PROTECTED]> writes: > > > > From: Cliff Woolley [mailto:[EMAIL PROTECTED]] > > > Sent: 18 April 2002 16:44 > > > > >> What is the current status on 2.0.36-dev? > > > Saw the fixes, so this is gone. > > > > > 2) The worker shutdown segfault ... Jeff, does the patch you committed > > >fix this for sure, or did it perhaps just hide the problem? There > > >didn't seem to be a consensus about this on-list. > > > > Jeff? > > This problem still exists. Note that I backed out a previous change I > had made which eliminated the segfaults but didn't attack the real > issue that pchild needs to live as long as our worker threads or bad > stuff will surely happen. Yes. Now the questions are: - Do we want to hold up a release for this? If so, for how long? - Is a graceless shutdown/restart at all possible with worker? [given the current APR thread API] Options I see for solving the problem are: - don't do graceless shutdown/restart, only do graceful. (not acceptable) - implement apr_thread_cancel and call this on all threads prior to cleaning pchild. - allocate the sockets out of a special pool so we can clean up the sockets (using apr_pool_clear(psock)), sleep for 1 sec (should be enough for all threads to notice the sockets are gone). After that clean pchild as usual. Sander
Re: Release 2.0.36
"Sander Striker" <[EMAIL PROTECTED]> writes: > > From: Cliff Woolley [mailto:[EMAIL PROTECTED]] > > Sent: 18 April 2002 16:44 > > >> What is the current status on 2.0.36-dev? > Saw the fixes, so this is gone. > > > 2) The worker shutdown segfault ... Jeff, does the patch you committed > >fix this for sure, or did it perhaps just hide the problem? There > >didn't seem to be a consensus about this on-list. > > Jeff? This problem still exists. Note that I backed out a previous change I had made which eliminated the segfaults but didn't attack the real issue that pchild needs to live as long as our worker threads or bad stuff will surely happen. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
RE: Release 2.0.36
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]] > Sent: 18 April 2002 16:44 >> What is the current status on 2.0.36-dev? > > Big things that I know of besides what's in bugzilla: > > 1) The MMAP bucket cleanup problem, which has been responsible for >some (rare-ish) segv's on daedalus [I think I figured out >how to fix this last night] Saw the fixes, so this is gone. > 2) The worker shutdown segfault ... Jeff, does the patch you committed >fix this for sure, or did it perhaps just hide the problem? There >didn't seem to be a consensus about this on-list. Jeff? > 3) Did Greg's 416 problems get fixed? Greg, I think you had a patch, >but did it get committed? Is there still a known condition (related >to this or not) that will cause the byterange filter to segv? Looks like this was fixed in httpd-2.0/modules/http/http_protocol.c rev 1.408. > 4) Is #3 different from the C-L / byterange filter misordering problem? >If not, is this one fixed? Greg? > 5) What about the libtool --install issue and Sander's partial >patch for it? This is taken care of. I would very much get another release out the door by the end of the week/start of next week. We've had many bugfixes and I don't think we should sit on them for much longer. Sander
Re: Release 2.0.36
On 18 Apr 2002, Jeff Trawick wrote: > > 1) The MMAP bucket cleanup problem, which has been responsible for > >some (rare-ish) segv's on daedalus [I think I figured out > >how to fix this last night] > > great! UHH It's even MORE complicated than I could have imagined. It's quite difficult (it might even be impossible) to ensure that you never touch m->mmap after it's cleaned up. You can register your own cleanup, but what if the apr_mmap_t is dup'ed and ownership is transferred? Then you're screwed. May I just say that cleanups are a bitch. :) Anyway, it looks like we might have no choice but to go back to NOT calling apr_mmap_delete() from mmap_bucket_destroy(). But that means that due to file_read morphing itself we could potentially have a large amount of data mmaped at a time before any of it goes away. Is that killer? Because if I could just remove that one line this would all go away. =-] --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: Release 2.0.36
Cliff Woolley <[EMAIL PROTECTED]> writes: > 5) What about the libtool --install issue and Sander's partial > patch for it? I'll try to get this done by tomorrow afternoon. Besides the coding, it needs to be tested out on some platforms which Sander doesn't have access to. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Release 2.0.36
Cliff Woolley <[EMAIL PROTECTED]> writes: > On Thu, 18 Apr 2002, Sander Striker wrote: > > > What is the current status on 2.0.36-dev? > > Big things that I know of besides what's in bugzilla: > > 1) The MMAP bucket cleanup problem, which has been responsible for >some (rare-ish) segv's on daedalus [I think I figured out >how to fix this last night] great! > 2) The worker shutdown segfault ... Jeff, does the patch you committed >fix this for sure, or did it perhaps just hide the problem? There >didn't seem to be a consensus about this on-list. It definitely doesn't deal with the fact that cleaning up pchild before all threads terminate during graceless termination can potentially cause all sorts of problems. I certainly don't see any segfaults in this area anymore (which is valuable to me since my regression tests can test other code). I think the code I put in yesterday should be backed out, but something else needs to change Real Soon Now to avoid the segfault. I'll be -1 on another release otherwise (not that such an opinion would make any difference). I'll back it out reasonably soon (need some lunch first) and hope for the best. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Release 2.0.36
On Thu, 18 Apr 2002, Cliff Woolley wrote: > > What is the current status on 2.0.36-dev? > > Big things that I know of besides what's in bugzilla: > > 1) The MMAP bucket cleanup problem, which has been responsible for >some (rare-ish) segv's on daedalus [I think I figured out >how to fix this last night] > > 2) The worker shutdown segfault ... Jeff, does the patch you committed >fix this for sure, or did it perhaps just hide the problem? There >didn't seem to be a consensus about this on-list. > > 3) Did Greg's 416 problems get fixed? Greg, I think you had a patch, >but did it get committed? Is there still a known condition (related >to this or not) that will cause the byterange filter to segv? > > 4) Is #3 different from the C-L / byterange filter misordering problem? >If not, is this one fixed? 5) What about the libtool --install issue and Sander's partial patch for it? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: Release 2.0.36
On Thu, 18 Apr 2002, Sander Striker wrote: > What is the current status on 2.0.36-dev? Big things that I know of besides what's in bugzilla: 1) The MMAP bucket cleanup problem, which has been responsible for some (rare-ish) segv's on daedalus [I think I figured out how to fix this last night] 2) The worker shutdown segfault ... Jeff, does the patch you committed fix this for sure, or did it perhaps just hide the problem? There didn't seem to be a consensus about this on-list. 3) Did Greg's 416 problems get fixed? Greg, I think you had a patch, but did it get committed? Is there still a known condition (related to this or not) that will cause the byterange filter to segv? 4) Is #3 different from the C-L / byterange filter misordering problem? If not, is this one fixed? --Cliff
Re: Release 2.0.36
At 04:33 AM 4/18/2002, Sander Striker wrote: >There have been several bug fixes since 2.0.35, >the community should benefit from that IMO. No doubt :) >What is the current status on 2.0.36-dev? I just let a nightly binary build fly on ~wrowe/ that I've posted in response to certain bugfixes nobody on this list ever reproduced (win32 socket problems and other cgi/scriptinterpreter fooness.) Hope to have some feedback quickly! >Greg (Ames), can you holler when you've >seen daedalus run for 3 days without dumping >core? ;) I was under the impression we are still running a near-.35 with specific bugfixes. After those patches prove themselves, it probably will be time to bump to head. [But I could just be confused :-] >I'm bringing this up because I don't want us >to end up with the same release rate we had >for the betas. Better to release often IMO. Wholeheartedly agreed here. Every two to four weeks would seem about ideal, one to three weeks of bugfixes and a week of stabilization should help folks accept the new codebase as solid and building on that. If I can get that semantics change done on optional fns/hooks so we can avoid all mmn version bumps for optional fn/hooks, I think that would also cut down on the bumps for foreign modules. Will look to make some progress and post an example patch by Friday morning.
Re: Release 2.0.36
On Thu, Apr 18, 2002 at 11:33:09AM +0200, Sander Striker wrote: > Do we have other known issues that should hold > up 2.0.36? Well, by my count, we have 74 open PRs in Bugzilla. A number of us have been triaging them (you know who you are), but more developers assisting in closing these suckers would do us well. That said, there are a number of gotchas and major faults fixed in between 2.0.35->HEAD that it may be worth considering doing a release. I don't think we'll ever fix all of the PRs, but we should attempt to make sure we've addressed PRs where multiple people have reported the same problem. -- justin
Release 2.0.36
Hi, There have been several bug fixes since 2.0.35, the community should benefit from that IMO. What is the current status on 2.0.36-dev? Are we still core dumping on daedalus? How close are we to finding/fixing the problem we are seeing there? Greg (Ames), can you holler when you've seen daedalus run for 3 days without dumping core? ;) Do we have other known issues that should hold up 2.0.36? I'm bringing this up because I don't want us to end up with the same release rate we had for the betas. Better to release often IMO. Sander
Re: CVS doesn't compile (2.0.36-dev)
On Fri, 12 Apr 2002 22:25:09 +0200 Magnus Määttä <[EMAIL PROTECTED]> wrote: > On 12 Apr 2002 16:09:36 -0400 > Jeff Trawick <[EMAIL PROTECTED]> wrote: > > > Cliff Woolley <[EMAIL PROTECTED]> writes: > > > > > On 12 Apr 2002, Jeff Trawick wrote: > > > > > > > > Using latest CVS version, just a couple of minutes old.. > > > > > > > > > > /bin/sh /root/Apache/httpd-2.0/srclib/apr/libtool --silent --mode=compile >gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 >-D_BSD_SOURCE -D_SVID_SOURCE -I../../include -I../../include/arch/unix >-I../../include/arch/unix -c dir.c && touch dir.lo > > > > > In file included from ../../include/apr_portable.h:73, > > > > > from dir.c:57: > > > > > ../../include/apr_thread_proc.h:655:26: "@" is not valid in #if expressions > > > > > > > > What are the few lines around 655 in your copy of the file? My copy > > > > doesn't have "@" there. > > > > > > > > > What are the contents of apr.h [specifically, the few lines around the > > > definition of APR_HAVE_SIGWAIT]? This is one of those problems where a > > > variable didn't get substituted correctly for some reason. > > > > that must be it > > > > > > > > You re-ran configure, right? > > > > since I changed configure.in, you'd need to > > > > make extraclean > > ./buildconf > > ./configure > > make > > > > right? > > It worked now.. > > I'll try that.. > Going to get drunk now.. bbl > > > -- > > Jeff Trawick | [EMAIL PROTECTED] > > Born in Roswell... married an alien... > > >
Re: CVS doesn't compile (2.0.36-dev)
Try removing your config.cache, rerunning buildconf and config.nice. -aaron On Fri, Apr 12, 2002 at 09:38:15PM +0200, Magnus Määttä wrote: > Hi! > > I don't know if this is the place to send it.. But here it goes: > > Using latest CVS version, just a couple of minutes old.. > > /bin/sh /root/Apache/httpd-2.0/srclib/apr/libtool --silent --mode=compile gcc -g -O2 >-pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE >-D_SVID_SOURCE -I../../include -I../../include/arch/unix -I../../include/arch/unix >-c dir.c && touch dir.lo > In file included from ../../include/apr_portable.h:73, > from dir.c:57: > ../../include/apr_thread_proc.h:655:26: "@" is not valid in #if expressions > make[4]: *** [dir.lo] Error 1 > make[4]: Leaving directory `/root/Apache/apr/file_io/unix' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/root/Apache/apr/file_io/unix' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/root/Apache/apr' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/Apache/httpd-2.0/srclib' > make: *** [all-recursive] Error 1
Re: CVS doesn't compile (2.0.36-dev)
On 12 Apr 2002 16:09:36 -0400 Jeff Trawick <[EMAIL PROTECTED]> wrote: > Cliff Woolley <[EMAIL PROTECTED]> writes: > > > On 12 Apr 2002, Jeff Trawick wrote: > > > > > > Using latest CVS version, just a couple of minutes old.. > > > > > > > > /bin/sh /root/Apache/httpd-2.0/srclib/apr/libtool --silent --mode=compile gcc >-g -O2 -pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 >-D_BSD_SOURCE -D_SVID_SOURCE -I../../include -I../../include/arch/unix >-I../../include/arch/unix -c dir.c && touch dir.lo > > > > In file included from ../../include/apr_portable.h:73, > > > > from dir.c:57: > > > > ../../include/apr_thread_proc.h:655:26: "@" is not valid in #if expressions > > > > > > What are the few lines around 655 in your copy of the file? My copy > > > doesn't have "@" there. > > > > > > What are the contents of apr.h [specifically, the few lines around the > > definition of APR_HAVE_SIGWAIT]? This is one of those problems where a > > variable didn't get substituted correctly for some reason. > > that must be it > > > > > You re-ran configure, right? > > since I changed configure.in, you'd need to > > make extraclean > ./buildconf > ./configure > make > > right? > I'll try that.. Going to get drunk now.. bbl > -- > Jeff Trawick | [EMAIL PROTECTED] > Born in Roswell... married an alien... >
Re: CVS doesn't compile (2.0.36-dev)
On Fri, 12 Apr 2002 16:07:25 -0400 (EDT) Cliff Woolley <[EMAIL PROTECTED]> wrote: > On 12 Apr 2002, Jeff Trawick wrote: > > > > Using latest CVS version, just a couple of minutes old.. > > > > > > /bin/sh /root/Apache/httpd-2.0/srclib/apr/libtool --silent --mode=compile gcc -g >-O2 -pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 >-D_BSD_SOURCE -D_SVID_SOURCE -I../../include -I../../include/arch/unix >-I../../include/arch/unix -c dir.c && touch dir.lo > > > In file included from ../../include/apr_portable.h:73, > > > from dir.c:57: > > > ../../include/apr_thread_proc.h:655:26: "@" is not valid in #if expressions > > > > What are the few lines around 655 in your copy of the file? My copy > > doesn't have "@" there. > > > What are the contents of apr.h [specifically, the few lines around the > definition of APR_HAVE_SIGWAIT]? This is one of those problems where a > variable didn't get substituted correctly for some reason. > #define APR_HAVE_SETRLIMIT 1 #define APR_HAVE_SIGACTION 1 #define APR_HAVE_SIGSUSPEND @have_sigsuspend@ #define APR_HAVE_SIGWAIT1 #define APR_HAVE_STRCASECMP 1 #define APR_HAVE_STRDUP 1 #define APR_HAVE_STRICMP0 > You re-ran configure, right? Everytime i recompiled (lost counting around 10), and ran make clean too.. > --Cliff > > -- >Cliff Woolley >[EMAIL PROTECTED] >Charlottesville, VA > > >
Re: CVS doesn't compile (2.0.36-dev)
On 12 Apr 2002, Jeff Trawick wrote: > since I changed configure.in, you'd need to > make extraclean > ./buildconf > ./configure > make > right? Yep. The make extraclean is optional but I highly recommend it... I use it all the time and it works wonders. :) --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: CVS doesn't compile (2.0.36-dev)
Cliff Woolley <[EMAIL PROTECTED]> writes: > On 12 Apr 2002, Jeff Trawick wrote: > > > > Using latest CVS version, just a couple of minutes old.. > > > > > > /bin/sh /root/Apache/httpd-2.0/srclib/apr/libtool --silent --mode=compile gcc -g >-O2 -pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 >-D_BSD_SOURCE -D_SVID_SOURCE -I../../include -I../../include/arch/unix >-I../../include/arch/unix -c dir.c && touch dir.lo > > > In file included from ../../include/apr_portable.h:73, > > > from dir.c:57: > > > ../../include/apr_thread_proc.h:655:26: "@" is not valid in #if expressions > > > > What are the few lines around 655 in your copy of the file? My copy > > doesn't have "@" there. > > > What are the contents of apr.h [specifically, the few lines around the > definition of APR_HAVE_SIGWAIT]? This is one of those problems where a > variable didn't get substituted correctly for some reason. that must be it > > You re-ran configure, right? since I changed configure.in, you'd need to make extraclean ./buildconf ./configure make right? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: CVS doesn't compile (2.0.36-dev)
On Fri, 12 Apr 2002, Cliff Woolley wrote: > What are the contents of apr.h [specifically, the few lines around the > definition of APR_HAVE_SIGWAIT]? This is one of those problems where a > variable didn't get substituted correctly for some reason. PS: It's almost certainly APR_HAVE_SIGSUSPEND that didn't get substituted... -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: CVS doesn't compile (2.0.36-dev)
On 12 Apr 2002 16:01:05 -0400 Jeff Trawick <[EMAIL PROTECTED]> wrote: > Magnus Määttä <[EMAIL PROTECTED]> writes: > > > Using latest CVS version, just a couple of minutes old.. > > > > /bin/sh /root/Apache/httpd-2.0/srclib/apr/libtool --silent --mode=compile gcc -g >-O2 -pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 >-D_BSD_SOURCE -D_SVID_SOURCE -I../../include -I../../include/arch/unix >-I../../include/arch/unix -c dir.c && touch dir.lo > > In file included from ../../include/apr_portable.h:73, > > from dir.c:57: > > ../../include/apr_thread_proc.h:655:26: "@" is not valid in #if expressions > > What are the few lines around 655 in your copy of the file? My copy > doesn't have "@" there. Neither does my.. That's the strange part.. > > -- > Jeff Trawick | [EMAIL PROTECTED] > Born in Roswell... married an alien... >
Re: CVS doesn't compile (2.0.36-dev)
On 12 Apr 2002, Jeff Trawick wrote: > > Using latest CVS version, just a couple of minutes old.. > > > > /bin/sh /root/Apache/httpd-2.0/srclib/apr/libtool --silent --mode=compile gcc -g >-O2 -pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 >-D_BSD_SOURCE -D_SVID_SOURCE -I../../include -I../../include/arch/unix >-I../../include/arch/unix -c dir.c && touch dir.lo > > In file included from ../../include/apr_portable.h:73, > > from dir.c:57: > > ../../include/apr_thread_proc.h:655:26: "@" is not valid in #if expressions > > What are the few lines around 655 in your copy of the file? My copy > doesn't have "@" there. What are the contents of apr.h [specifically, the few lines around the definition of APR_HAVE_SIGWAIT]? This is one of those problems where a variable didn't get substituted correctly for some reason. You re-ran configure, right? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: CVS doesn't compile (2.0.36-dev)
Magnus Määttä <[EMAIL PROTECTED]> writes: > Using latest CVS version, just a couple of minutes old.. > > /bin/sh /root/Apache/httpd-2.0/srclib/apr/libtool --silent --mode=compile gcc -g -O2 >-pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE >-D_SVID_SOURCE -I../../include -I../../include/arch/unix -I../../include/arch/unix >-c dir.c && touch dir.lo > In file included from ../../include/apr_portable.h:73, > from dir.c:57: > ../../include/apr_thread_proc.h:655:26: "@" is not valid in #if expressions What are the few lines around 655 in your copy of the file? My copy doesn't have "@" there. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
CVS doesn't compile (2.0.36-dev)
Hi! I don't know if this is the place to send it.. But here it goes: Using latest CVS version, just a couple of minutes old.. /bin/sh /root/Apache/httpd-2.0/srclib/apr/libtool --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -I../../include -I../../include/arch/unix -I../../include/arch/unix -c dir.c && touch dir.lo In file included from ../../include/apr_portable.h:73, from dir.c:57: ../../include/apr_thread_proc.h:655:26: "@" is not valid in #if expressions make[4]: *** [dir.lo] Error 1 make[4]: Leaving directory `/root/Apache/apr/file_io/unix' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/Apache/apr/file_io/unix' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/Apache/apr' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/Apache/httpd-2.0/srclib' make: *** [all-recursive] Error 1 Regards Magnus Määttä
