|
/
Zope
/
Apsis
/
Pound Mailing List
/
Archive
/
2010
/
2010-03
/
Pound segfaults on first request
[
Pound mailing list emails considered spam with ... ]
[
Problem with pound SSL / "Anne Moore" ... ]
Pound segfaults on first request
"(private) HKS" <hks.private(at)gmail.com> |
2010-03-10 23:20:52 |
[ SNIP ]
|
I'm moving my Pound servers from OpenBSD to FreeBSD 8.0 AMD64.
I've compiled Pound 2.5 from source --with-maxbuf=16384 and included
PCRE. Each instance of Pound is throwing this error at its first
request:
pound: MONITOR: worker exited on signal 11, restarting
Subsequent requests are serviced normally. I'm using the same
configurations that I was using on the OpenBSD boxes (albeit with
relevant paths corrected). I've pasted my config below. Anybody seen
this before?
-HKS
User "pound"
Group "pound"
Control "/var/run/pound-ctl.socket"
LogFacility daemon
LogLevel 5
Alive 30
Client 30
TimeOut 900
Grace 30
# HTTP goes to HTTPS redirect
ListenHTTP
Address 10.2.1.72
Port 80
RewriteLocation 2
Service
Backend
Address 10.2.1.11
Port 8080
End
Backend
Address 10.2.1.21
Port 8080
End
Backend
Address 10.2.1.22
Port 8080
End
End
End
ListenHTTPS
Address 10.2.1.72
Port 443
Cert "/usr/local/etc/pound/private/cert.pem"
Client 30
RewriteLocation 2
# Mercurial requests get big timeouts
Service
HeadRequire "[Aa][Cc][Cc][Ee][Pp][Tt]:
.*application\/mercurial.*"
HeadRequire "[Uu][Ss][Ee][Rr]-[Aa][Gg][Ee][Nn][Tt]:
.*mercurial.*"
Backend
Address 10.2.1.24
Port 80
# 12 hours
Timeout 43200
End
Backend
Address 10.2.1.30
Port 80
# 12 hours
Timeout 43200
End
End
Service
Backend
Address 10.2.1.24
Port 80
End
Backend
Address 10.2.1.30
Port 80
End
End
End
# Uh-Oh page in case everything else is hosed
Service
Backend
Address 127.0.0.1
Port 8181
End
End
|
|
|
Re: Pound segfaults on first request
"(private) HKS" <hks.private(at)gmail.com> |
2010-03-29 17:55:05 |
[ SNIP ]
|
On Wed, Mar 10, 2010 at 6:20 PM, (private) HKS <hks.private(at)gmail.com>
wrote:
> I'm moving my Pound servers from OpenBSD to FreeBSD 8.0 AMD64.
>
> I've compiled Pound 2.5 from source --with-maxbuf=16384 and included
> PCRE. Each instance of Pound is throwing this error at its first
> request:
>
> pound: MONITOR: worker exited on signal 11, restarting
>
> Subsequent requests are serviced normally. I'm using the same
> configurations that I was using on the OpenBSD boxes (albeit with
> relevant paths corrected). I've pasted my config below. Anybody seen
> this before?
>
>
> -HKS
>
>
> User "pound"
> Group "pound"
> Control "/var/run/pound-ctl.socket"
> LogFacility daemon
> LogLevel 5
> Alive 30
> Client 30
> TimeOut 900
> Grace 30
>
> # HTTP goes to HTTPS redirect
> ListenHTTP
> Address 10.2.1.72
> Port 80
> RewriteLocation 2
> Service
> Backend
> Address 10.2.1.11
> Port 8080
> End
> Backend
> Address 10.2.1.21
> Port 8080
> End
> Backend
> Address 10.2.1.22
> Port 8080
> End
> End
> End
>
> ListenHTTPS
> Address 10.2.1.72
> Port 443
> Cert "/usr/local/etc/pound/private/cert.pem"
> Client 30
> RewriteLocation 2
>
> # Mercurial requests get big timeouts
> Service
> HeadRequire "[Aa][Cc][Cc][Ee][Pp][Tt]:
> .*application\/mercurial.*"
> HeadRequire "[Uu][Ss][Ee][Rr]-[Aa][Gg][Ee][Nn][Tt]:
> .*mercurial.*"
> Backend
> Address 10.2.1.24
> Port 80
> # 12 hours
> Timeout 43200
> End
> Backend
> Address 10.2.1.30
> Port 80
> # 12 hours
> Timeout 43200
> End
> End
>
> Service
> Backend
> Address 10.2.1.24
> Port 80
> End
> Backend
> Address 10.2.1.30
> Port 80
> End
> End
> End
>
> # Uh-Oh page in case everything else is hosed
> Service
> Backend
> Address 127.0.0.1
> Port 8181
> End
> End
>
This seems to be related to configuring with --with-maxbuf=16384 on a
64-bit box (I don't have any 64-bit non-FreeBSD boxes, so I can't test
that). If I leave that out or use --with-maxbuf=8192, there is no
initial segfault.
Any idea what's going on here?
-HKS
|
|
|
Re: [Pound Mailing List] Re: Pound segfaults on first request
Robert Segall <roseg(at)apsis.ch> |
2010-03-30 16:54:35 |
[ SNIP ]
|
On Mon, 2010-03-29 at 11:55 -0400, (private) HKS wrote:
> This seems to be related to configuring with --with-maxbuf384 on a
> 64-bit box (I don't have any 64-bit non-FreeBSD boxes, so I can't test
> that). If I leave that out or use --with-maxbufÂ92, there is no
> initial segfault.
>
> Any idea what's going on here?
It might be a problem with the stack size, which is important on some
*BSD flavours. Try changing (version 2.5, pound.c line 359)
#ifdef NEED_STACK
/* set new stack size - necessary for OpenBSD/FreeBSD and Linux NPTL */
if(pthread_attr_setstacksize(&attr, 1 << 18)) {
logmsg(LOG_ERR, "can't set stack size - aborted");
exit(1);
}
#endif
to a higher value and see if it helps. Also make sure NEED_STACK is
defined.
--
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-32-512 30 19
|
|
|
Re: [Pound Mailing List] Re: Pound segfaults on first request
"(private) HKS" <hks.private(at)gmail.com> |
2010-03-30 17:38:12 |
[ SNIP ]
|
On Tue, Mar 30, 2010 at 10:54 AM, Robert Segall <roseg(at)apsis.ch> wrote:
> On Mon, 2010-03-29 at 11:55 -0400, (private) HKS wrote:
>> This seems to be related to configuring with --with-maxbuf 384 on a
>> 64-bit box (I don't have any 64-bit non-FreeBSD boxes, so I can't test
>> that). If I leave that out or use --with-maxbuf 92, there is no
>> initial segfault.
>>
>> Any idea what's going on here?
>
> It might be a problem with the stack size, which is important on some
> *BSD flavours. Try changing (version 2.5, pound.c line 359)
>
> #ifdef  NEED_STACK
> Â /* set new stack size - necessary for OpenBSD/FreeBSD and Linux NPTL */
> Â if(pthread_attr_setstacksize(&attr, 1 << 18)) {
> Â Â logmsg(LOG_ERR, "can't set stack size - aborted");
> Â Â exit(1);
> Â }
> #endif
>
> to a higher value and see if it helps. Also make sure NEED_STACK is
> defined.
> --
> Robert Segall
> Apsis GmbH
> Postfach, Uetikon am See, CH-8707
> Tel: +41-32-512 30 19
>
>
> --
> To unsubscribe send an email with subject unsubscribe to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
Good shot: boosting the stack size to 512k (1 << 19) fixed it. I know
this probably slips into POSIX programming details, but can you help
me understand a bit more of why this was a problem?
-HKS
|
|
|
|