You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2001/06/28 07:31:26 UTC

httpd-2.0 tagged

Apache 2.0.19 is tagged.  I will have tarballs soon-ish.  Another message
when they are in http://dev.apache.org/dist/

Ryan


_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------


Re: httpd-2.0 tagged

Posted by Bill Stoddard <bi...@wstoddard.com>.
Yea, looks broken on AIX as well.  The child process will not stay up. Left with cgid and
the parent process.

Bill

> On Wed, Jun 27, 2001 at 10:39:47PM -0700, rbb@covalent.net wrote:
> >
> > The tarballs are now available.   :-)
> >
> > Everybody have at them, and enjoy.  I will send e-mail to current-testers
> > immediately.
> >
> > When we are ready to make this a beta, I have the CHANGES file available
> > to put on-line.
>
> -1 (yeah, yeah, non-binding).
>
> Just compiled it with a Mandrake 8.0 box with GCC 3.0.  The threaded MPM
> looks completely hosed.
>
> It will start up all of the children, but they are all dead within a
> few seconds.  (Only two processes remain...)
>
> My gut tells me that the commit right before the T&R for the scoreboard
> is doing something funky.  Sorry I don't have time to examine more
> right now.  May have more time tomorrow morning to look at this if
> others can't reproduce this.  -- justin
>


Re: httpd-2.0 tagged

Posted by Dale Ghent <da...@elemental.org>.
On Wed, 27 Jun 2001, Justin Erenkrantz wrote:

| -1 (yeah, yeah, non-binding).
|
| Just compiled it with a Mandrake 8.0 box with GCC 3.0.  The threaded MPM
| looks completely hosed.
|
| It will start up all of the children, but they are all dead within a
| few seconds.  (Only two processes remain...)

I'm seeing the same on Solaris 8 now.

the children start, stick around for a few seconds, and then all but one
die from receiving SIGTERM. Any HTTP requests made to the server connect,
but hang after "GET /blah ..." is issued.

A quick truss on a child process shows that it seems to be
(gracefully?) killing itself:

/4:     getpid()                                        = 21853 [21848]
/2:     signotifywait()                                 = 15
/4:     kill(21853, SIGTERM)                            = 0
/2:     lwp_mutex_lock(0xFF1555D8)                      = 0
/2:     lwp_mutex_wakeup(0xFF1555D8)                    = 0
/4:     lwp_mutex_lock(0xFF1555D8)                      = 0
/2:     lwp_mutex_lock(0xFF1555D8)                      = 0
/4:     lwp_mutex_wakeup(0xFF1555D8)                    = 0
/4:     lwp_mutex_lock(0xFF1555D8)                      = 0
/2:     lwp_mutex_lock(0xFF1555D8)                      = 0
/4:     lwp_mutex_wakeup(0xFF1555D8)                    = 0
/2:     lwp_cond_signal(0xFF1555C8)                     = 0
/2:     lwp_mutex_wakeup(0xFF1555D8)                    = 0
/3:     lwp_cond_wait(0xFF1555C8, 0xFF1555D8, 0xFF105CA8) = 0
/3:     lwp_mutex_wakeup(0xFF1555D8)                    = 0
/4:     lwp_mutex_lock(0xFF1555D8)                      = 0
/4:     time()                                          = 993709078
/3:     lwp_mutex_lock(0xFF1555D8)                      = 0
/3:         Received signal #15, SIGTERM, in lwp_sigtimedwait() [caught]
/3:           siginfo: SIGTERM pid=21853 uid=60001
/3:     lwp_sigtimedwait(0xFFBEF7F4, 0x00000000, 0xFF14F860, 0xFFBEF824) =
15
/3:     munmap(0xFDC00000, 1056768)                     = 0
/3:     munmap(0xFD70E000, 1056768)                     = 0
/3:     munmap(0xFD60C000, 1056768)                     = 0
/3:     munmap(0xFD50A000, 1056768)                     = 0
/3:     munmap(0xFD408000, 1056768)                     = 0
/3:     munmap(0xFD306000, 1056768)                     = 0
/3:     munmap(0xFD204000, 1056768)                     = 0
/3:     munmap(0xFD102000, 1056768)                     = 0
/3:     munmap(0xFD000000, 1056768)                     = 0
/3:     munmap(0xFCB0E000, 1056768)                     = 0
/3:     munmap(0xFCA0C000, 1056768)                     = 0
/3:     munmap(0xFC90A000, 1056768)                     = 0
/3:     munmap(0xFC808000, 1056768)                     = 0
/3:     llseek(0, 0, SEEK_CUR)                          = 0
/3:     _exit(0)

HTH,
/dale


Re: httpd-2.0 tagged

Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Jun 27, 2001 at 10:39:47PM -0700, rbb@covalent.net wrote:
> 
> The tarballs are now available.   :-)
> 
> Everybody have at them, and enjoy.  I will send e-mail to current-testers
> immediately.
> 
> When we are ready to make this a beta, I have the CHANGES file available
> to put on-line.

-1 (yeah, yeah, non-binding).

Just compiled it with a Mandrake 8.0 box with GCC 3.0.  The threaded MPM 
looks completely hosed.

It will start up all of the children, but they are all dead within a
few seconds.  (Only two processes remain...)

My gut tells me that the commit right before the T&R for the scoreboard 
is doing something funky.  Sorry I don't have time to examine more
right now.  May have more time tomorrow morning to look at this if
others can't reproduce this.  -- justin


Re: httpd-2.0 tagged

Posted by rb...@covalent.net.
The tarballs are now available.   :-)

Everybody have at them, and enjoy.  I will send e-mail to current-testers
immediately.

When we are ready to make this a beta, I have the CHANGES file available
to put on-line.

Ryan

On Wed, 27 Jun 2001 rbb@covalent.net wrote:

>
> Apache 2.0.19 is tagged.  I will have tarballs soon-ish.  Another message
> when they are in http://dev.apache.org/dist/
>
> Ryan
>
>
> _____________________________________________________________________________
> Ryan Bloom                        	rbb@apache.org
> Covalent Technologies			rbb@covalent.net
> -----------------------------------------------------------------------------
>
>


_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------