Re: perchild
On Thu, 2006-31-08 at 16:21 +0200, Enrico Weigelt wrote: * Guy Hulbert [EMAIL PROTECTED] wrote: snip It is not clear to me yet whether I should work on metux or perchild. Unless I missed some major redesign in perchild, you should drop it. It has some design flaws which make it insecure. metuxmpm was forked off to fix them. ok ... can you reply to me off-list with an outline if/when i start working on this, I will post a URL to the list on which I will post progress reports until I have something that can be uploaded to mpm/experimental cu -- --gh
Re: perchild
* Guy Hulbert [EMAIL PROTECTED] wrote: Ok. I have the patch against 2.0.48 ... I will see what I can do with it. Yeah, it's quite old. But perhaps you can get it into current 2.2. Please give us feedback. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: perchild
On Thu, 2006-31-08 at 13:37 +0200, Enrico Weigelt wrote: * Guy Hulbert [EMAIL PROTECTED] wrote: Ok. I have the patch against 2.0.48 ... I will see what I can do with it. Yeah, it's quite old. But perhaps you can get it into current 2.2. Please give us feedback. It is not clear to me yet whether I should work on metux or perchild. I'll give you some feedback once I am able to decide (weeks rather than days). cu -- --gh
Re: perchild
* Guy Hulbert [EMAIL PROTECTED] wrote: snip It is not clear to me yet whether I should work on metux or perchild. Unless I missed some major redesign in perchild, you should drop it. It has some design flaws which make it insecure. metuxmpm was forked off to fix them. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: perchild
* Guy Hulbert [EMAIL PROTECTED] wrote: Hi, I'm looking at perchild with the aim of getting it working. maybe you're looking for: http://www.metux.de/mpm The project has been stalled for quite a while :( But maybe it's time for revival ? In STATUS I see: Get perchild to work on platforms other than Linux. This will require a portable mechanism to pass data and file/socket descriptors between vhost child groups. Perchild *never* worked. The idea isn't bad - we took much of it into metuxmpm, but there were major design problems. For example: each childs can accept clients. That's very bad, because it allows some user to intercept another's requests with some probability. The whole idea of passing *sockets* (instead of requests) between processes only works on very few systems, ie. Linux, BSD and perhaps some others. So the whole portability issue is useless - those MPMs only work some Unix'es, and there evrythere the same. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: perchild
On Wed, Aug 30, 2006 at 12:59:02PM +0200, Enrico Weigelt wrote: The whole idea of passing *sockets* (instead of requests) between processes only works on very few systems, ie. Linux, BSD and perhaps some others. So the whole portability issue is useless - those MPMs only work some Unix'es, and there evrythere the same. None of our MPMs offers that kind of portability. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: perchild
On Wed, 2006-30-08 at 23:02 +0200, Enrico Weigelt wrote: * Guy Hulbert [EMAIL PROTECTED] wrote: On Wed, 2006-30-08 at 12:59 +0200, Enrico Weigelt wrote: * Guy Hulbert [EMAIL PROTECTED] wrote: Hi, I'm looking at perchild with the aim of getting it working. maybe you're looking for: http://www.metux.de/mpm I found that. The links don't work. ah, bug in the php script (was too old for my server - still relied on register_globals ;-o) snip Ok. I have the patch against 2.0.48 ... I will see what I can do with it. --gh
Re: perchild
On Sun, 2006-09-07 at 19:30 -0700, Paul Querna wrote: Guy Hulbert wrote: I'm looking at perchild with the aim of getting it working. snip Yes. It could be broken on linux and all other platforms. If someone else is working on it then I will focus on testing it. No one is working on perchild ATM. I had gathered that from looking at the subversion logs. I will see what I can do then. I have been using prefork from debian (customers with PHP). So it will take me a while to get up to speed. -Paul -- --gh
Re: perchild
Guy Hulbert wrote: I'm looking at perchild with the aim of getting it working. In STATUS I see: Get perchild to work on platforms other than Linux. This will require a portable mechanism to pass data and file/socket descriptors between vhost child groups. But I am lead to believe (from the users list) that it needs work on Linux as well. Yes. It could be broken on linux and all other platforms. If someone else is working on it then I will focus on testing it. No one is working on perchild ATM. -Paul
Re: PerChild Error
Pablo Yaggi wrote: It doesn't dump anything, i have this CoreDumpDirectory /tmp/ and it dumps nothing there. ok, that looks good so far... What I saw is that a new process for the site (user pablo) is being started about 2 seconds all the time and each process logs what I mention before, so I think the process is not even starting in the right way. The main process is starting, because I can stablish a connection with a browser, but the request is never attended. Please let me know how I can log something else or dump the core. I can't open the process with gdb because the process is dieing permantly, is it any usefull for you a dump from the main process? wich kind ?. Yes I 'm using linux, version 2.4.21 from mandrake 9.1 There is a fix in the open source version of 2.0.46 http://www.apache.org/dist/httpd/httpd-2.0.46.tar.gz ...which allows coredumps on Linux when you start httpd as root and code CoreDumpDirectory in httpd.conf. If you start httpd as non-root, it should just work (i.e., you don't need the fix), assuming CoreDumpDirectory points to somewhere like /tmp where the non-root user can create files. Pablo Yaggi wrote: I forgot this in my last post, output from httpd -V Server version: Apache-AdvancedExtranetServer/2.0.46 I don't know what is in this vendor's version of Apache. You might want to talk to them, or try the open source version. Greg
Re: PerChild Error
[EMAIL PROTECTED] wrote: There is a fix in the open source version of 2.0.46 http://www.apache.org/dist/httpd/httpd-2.0.46.tar.gz ...which allows coredumps on Linux when you start httpd as root and code CoreDumpDirectory in httpd.conf. If you start httpd as non-root, it should just work (i.e., you don't need the fix), assuming CoreDumpDirectory points to somewhere like /tmp where the non-root user can create files. ps. This fix is mainly to os/unix/unixd.c::unixd_setup_child() . That function is not called by the perchild mpm, so it won't help your situation. I'm assuming perchild does its own setuid calls, since the user ids are a unique feature of perchild. You could look for this and code prctl(PR_SET_DUMPABLE,1) after the setuid. Here's what I did in the mainstream code: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/os/unix/unixd.c.diff?r1=1.56r2=1.57diff_format=h Good luck! Greg not about to become the PerChild maintainer Ames
Re: PerChild Error
No, it was running as less privileged user , and the version Extranet is just somthing mandrake puted there, I'm recompiling mandrakes rpms, maybe there's some patch there that stops the dumps, i'll try to rebuild the source. But now I'm trying muxmpm cause somebody told me that perchild it was not working at all, did you manage to make it work ? if it is so, are you cgi working at right userid ? do you have php running ? what happens with ssl request on namebased virtual hosts ? who attends ? Thank's Pablo On Monday 23 June 2003 11:36 am, [EMAIL PROTECTED] wrote: Pablo Yaggi wrote: It doesn't dump anything, i have this CoreDumpDirectory /tmp/ and it dumps nothing there. ok, that looks good so far... What I saw is that a new process for the site (user pablo) is being started about 2 seconds all the time and each process logs what I mention before, so I think the process is not even starting in the right way. The main process is starting, because I can stablish a connection with a browser, but the request is never attended. Please let me know how I can log something else or dump the core. I can't open the process with gdb because the process is dieing permantly, is it any usefull for you a dump from the main process? wich kind ?. Yes I 'm using linux, version 2.4.21 from mandrake 9.1 There is a fix in the open source version of 2.0.46 http://www.apache.org/dist/httpd/httpd-2.0.46.tar.gz ...which allows coredumps on Linux when you start httpd as root and code CoreDumpDirectory in httpd.conf. If you start httpd as non-root, it should just work (i.e., you don't need the fix), assuming CoreDumpDirectory points to somewhere like /tmp where the non-root user can create files. Pablo Yaggi wrote: I forgot this in my last post, output from httpd -V Server version: Apache-AdvancedExtranetServer/2.0.46 I don't know what is in this vendor's version of Apache. You might want to talk to them, or try the open source version. Greg
Re: PerChild Error
Pablo Yaggi wrote: No, it was running as less privileged user , and the version Extranet is just somthing mandrake puted there, I'm recompiling mandrakes rpms, maybe there's some patch there that stops the dumps, i'll try to rebuild the source. you might want to have a look at my other post where I talked about prctl(). PerChild might need something like that in order to dump on Linux, if it does its own setuid(). But now I'm trying muxmpm cause somebody told me that perchild it was not working at all, I've heard that too. did you manage to make it work ? haven't tried it, and I don't plan on it in the near future. Greg
Re: PerChild Error
I forgot this in my last post, output from httpd -V Server version: Apache-AdvancedExtranetServer/2.0.46 Server built: Jun 20 2003 04:31:08 Server's Module Magic Number: 20020903:3 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/experimental/perchild -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/etc/httpd/2.0 -D SUEXEC_BIN=/usr/sbin/apache2-suexec -D DEFAULT_PIDLOG=/var/run/httpd.pid -D DEFAULT_LOCKFILE=/var/run/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd2.conf Pablo
Re: PerChild Error
Pablo Yaggi wrote: besides is prefork using threads ? prefork does not use threads. i installed a server with perchild and this is a strip from my error log: [Fri Jun 20 18:29:52 2003] [notice] child pid 14291 exit signal Segmentation fault (11) do you have a coredump? We the backtrace from it if so. otherwise, we can't do squat with these messages. If this is Linux, you should see more text at the end of this message saying that there is a possible coredump. Make sure you have CoreDumpDir /directory/writeable/by/Apache/User in your httpd.conf or it's hard to get coredumps. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock failed. Attempting to shutdown process gracefully. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock failed. Attempting to shutdown process gracefully. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock failed. Attempting to shutdown process gracefully. what kind of locking is your apr using? (hint: bin/httpd -V) Greg
Re: PerChild Error
It doesn't dump anything, i have this CoreDumpDirectory /tmp/ and it dumps nothing there. What I saw is that a new process for the site (user pablo) is being started about 2 seconds all the time and each process logs what I mention before, so I think the process is not even starting in the right way. The main process is starting, because I can stablish a connection with a browser, but the request is never attended. Please let me know how I can log something else or dump the core. I can't open the process with gdb because the process is dieing permantly, is it any usefull for you a dump from the main process? wich kind ?. Yes I 'm using linux, version 2.4.21 from mandrake 9.1 Regards, Pablo [Fri Jun 20 18:29:52 2003] [notice] child pid 14291 exit signal is in the log all the On Friday 20 June 2003 06:35 pm, [EMAIL PROTECTED] wrote: Pablo Yaggi wrote: besides is prefork using threads ? prefork does not use threads. i installed a server with perchild and this is a strip from my error log: [Fri Jun 20 18:29:52 2003] [notice] child pid 14291 exit signal Segmentation fault (11) do you have a coredump? We the backtrace from it if so. otherwise, we can't do squat with these messages. If this is Linux, you should see more text at the end of this message saying that there is a possible coredump. Make sure you have CoreDumpDir /directory/writeable/by/Apache/User in your httpd.conf or it's hard to get coredumps. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock failed. Attempting to shutdown process gracefully. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock failed. Attempting to shutdown process gracefully. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully. [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock failed. Attempting to shutdown process gracefully. what kind of locking is your apr using? (hint: bin/httpd -V) Greg
Re: perchild is broken
On Fri, Dec 13, 2002 at 06:21:09PM +0100, Dirk Nehring wrote: snip I try to use Apache's perchild MPM. Unfortunately, it seems to be broken under Linux. I'm using RedHat 8.0 (glibc-2.2.5, gcc 3.2), took the latest CVS sources for httpd-2.0, apr and apr-util (today's CVS checkout), and compiled with the perchild MPM. The following happened after starting: yes, it _is_ broken. i've started working on an new MPM (multiplexer), derived from perchild, which also provides the possibility for assigning UIDs to vhosts, but is (should be) a bit more secure. but the muxmpm isnt really stable yet, there's still the problem that worker threads are dying out after a while ... perhaps you wanna help ? ~-n -- Bestes Mittel gegen Mailviren: Outlook löschen. - Enrico Weigelt== metux ITS Webhosting ab 5 EUR/Monat. UUCP, rawIP und vieles mehr. phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 smsgate: [EMAIL PROTECTED] - Diese Mail wurde mit UUCP versandt. http://www.metux.de/uucp/
Re: perchild mpm
On Thu, Oct 17, 2002, Jonas Eriksson [EMAIL PROTECTED] wrote: Any progress in getting perchild to work ? I've started some debugging. In my case, passing the request off to a different process is causing corruption and the request to fail. That's as far as I have gotten so far :) What problems are you having? JE
Re: perchild under Solaris 8
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Yeah, I don't think Solaris uses the same structure/functions for passing fd's between processes. I had originally planned to use a Solaris box for the second port, but I don't have access to one yet. I keep looking on e-bay for a good x86 box though. Ryan, send me your SSH key... We have _plenty_ of Solaris boxes (including a big fat Apache machine handling the bug tracking database!!! :) :) :) NO EXCUSES! :) :) :) Pier
Re: perchild under Solaris 8
Tsuyoshi SASAMOTO wrote: If '-D_XPG4_2 -D__EXTENSIONS__' are added to CPPFLAGS during the configure process, perchild will compile relatively cleanly under Solaris 8 and result in a binary that actually serves content!! Please see the standards(5) man page. -D_XPG4_2 is an internal macro, so it shouldn't be defined directly. -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ should be used instead (or -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -D__EXTENSIONS__). # -D_XPG4_2 etc. may be defined internally in sys/feature_tests.h. That's what you get for looking at header files and code and not manuals. -- === 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: perchild under Solaris 8
At 2:31 PM +0900 9/11/02, Tsuyoshi SASAMOTO wrote: If '-D_XPG4_2 -D__EXTENSIONS__' are added to CPPFLAGS during the configure process, perchild will compile relatively cleanly under Solaris 8 and result in a binary that actually serves content!! Please see the standards(5) man page. -D_XPG4_2 is an internal macro, so it shouldn't be defined directly. -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ should be used instead (or -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -D__EXTENSIONS__). Looks like we should be using the later, for Unix 95. Doesn't appear that we need Unix 98 -- === 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: perchild under Solaris 8
Looks like we should be using the later, for Unix 95. Doesn't appear that we need Unix 98 But... there's no reason to avoid using -D_XOPEN_SOURCE=500. I've built perchild httpd with -D_XOPEN_SOURCE=500 -D__EXTENSIONS__, and it works well. Tsuyoshi SASAMOTO [EMAIL PROTECTED]
Re: perchild under Solaris 8
On Tue, Sep 10, 2002 at 01:07:30PM -0400, Jim Jagielski wrote: If '-D_XPG4_2 -D__EXTENSIONS__' are added to CPPFLAGS during the configure process, perchild will compile relatively cleanly under Solaris 8 and result in a binary that actually serves content!! Haven't yet playing with using the actual uid/gid aspects of perchild yet. I'm looking to see what affects, if any, adding these by default to APR and httpd will be... If anyone has some better experience with these, please let me know :) If that combo works, great, but I have a feeling it will break some other things. I have a combo somewhere around here that I am using on another module that allows solaris to expose the same file descriptor passing semantics, let me see if I can find it. -aaron
Re: perchild under Solaris 8
At 11:07 AM -0700 9/10/02, Aaron Bannert wrote:
On Tue, Sep 10, 2002 at 01:07:30PM -0400, Jim Jagielski wrote:
If '-D_XPG4_2 -D__EXTENSIONS__' are added to CPPFLAGS during the configure
process, perchild will compile relatively cleanly under Solaris 8 and
result in a binary that actually serves content!! Haven't yet
playing with using the actual uid/gid aspects of perchild yet.
I'm looking to see what affects, if any, adding these by default to
APR and httpd will be... If anyone has some better experience with
these, please let me know :)
If that combo works, great, but I have a feeling it will break some
other things. I have a combo somewhere around here that I am using on
another module that allows solaris to expose the same file descriptor
passing semantics, let me see if I can find it.
I'm also concerned about breakage... Thing is, we're using msghdr for
the recvmsg() calls.
/*
* Message header for recvmsg and sendmsg calls.
*/
struct msghdr {
void*msg_name; /* optional address */
socklen_t msg_namelen;/* size of address */
struct iovec*msg_iov; /* scatter/gather array */
int msg_iovlen; /* # elements in msg_iov */
#if defined(_XPG4_2) || defined(_KERNEL)
void*msg_control; /* ancillary data */
socklen_t msg_controllen; /* ancillary data buffer len */
int msg_flags; /* flags on received message */
#else
caddr_t msg_accrights; /* access rights sent/received */
int msg_accrightslen;
#endif /* defined(_XPG4_2) || defined(_KERNEL) */
};
The __EXTENSIONS__ is required for proctype_t (in various headers)
to be correctly defined :/
--
===
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: perchild under Solaris 8
On Tue, 10 Sep 2002, Jim Jagielski wrote: At 11:07 AM -0700 9/10/02, Aaron Bannert wrote: On Tue, Sep 10, 2002 at 01:07:30PM -0400, Jim Jagielski wrote: If '-D_XPG4_2 -D__EXTENSIONS__' are added to CPPFLAGS during the configure process, perchild will compile relatively cleanly under Solaris 8 and result in a binary that actually serves content!! Haven't yet playing with using the actual uid/gid aspects of perchild yet. I'm looking to see what affects, if any, adding these by default to APR and httpd will be... If anyone has some better experience with these, please let me know :) If that combo works, great, but I have a feeling it will break some other things. I have a combo somewhere around here that I am using on another module that allows solaris to expose the same file descriptor passing semantics, let me see if I can find it. I'm also concerned about breakage... Thing is, we're using msghdr for the recvmsg() calls. Yeah, I don't think Solaris uses the same structure/functions for passing fd's between processes. I had originally planned to use a Solaris box for the second port, but I don't have access to one yet. I keep looking on e-bay for a good x86 box though. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: perchild under Solaris 8
[EMAIL PROTECTED] wrote: I'm also concerned about breakage... Thing is, we're using msghdr for the recvmsg() calls. Yeah, I don't think Solaris uses the same structure/functions for passing fd's between processes. Well, it looks like it *can* :) That doesn't mean that it should... ;) -- === 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: perchild under Solaris 8
If '-D_XPG4_2 -D__EXTENSIONS__' are added to CPPFLAGS during the configure process, perchild will compile relatively cleanly under Solaris 8 and result in a binary that actually serves content!! Please see the standards(5) man page. -D_XPG4_2 is an internal macro, so it shouldn't be defined directly. -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ should be used instead (or -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -D__EXTENSIONS__). # -D_XPG4_2 etc. may be defined internally in sys/feature_tests.h. Yeah, I don't think Solaris uses the same structure/functions for passing fd's between processes. recvmsg(3XNET), which is actually mapped to __xnet_recvmsg(), has the UNIX95 semantics, and recvmsg(3SOCKET) has the traditional SunOS4.x semantics. Both can be used for FD passing. Tsuyoshi SASAMOTO [EMAIL PROTECTED]
Re: perchild on Darwin, hmmm
On Fri, 30 Aug 2002, Jim Jagielski wrote: Wish there were at least 5 hours more per day... ;) Dood, I'm counting on 8. ;)
Re: perchild on Darwin, hmmm
That is awesome! The code is REALLY crufty still, but it would be great to get more eys on it. Fair warning, it is REALLY fragile still. Happy hacking. :-) Ryan On Fri, 30 Aug 2002, Jim Jagielski wrote: Except for the poll.h header line, perchild compiled quite nicely on Darwin (Jaguar - 10.2). Also confirmed that it serves pages. Have *NOT* yet checked to see if the perchild specific goodies actually work yet. Next on the list :) Wish there were at least 5 hours more per day... ;) -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Perchild on Solaris (was: Perchild works again.... kind of)
On Tue, Aug 20, 2002 at 11:07:37AM +0900, Tsuyoshi SASAMOTO wrote: On Solaris, this macro definition is required to build successfully: -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ By the way, with the perchild MPM, httpd performance is T2 (alternate) thread lib T1 (default) thread lib. http://groups.google.com/groups?[EMAIL PROTECTED] By contrast, with the worker MPM, T2 thread lib T1 thread lib (But the difference is smaller than the perchild MPM). With the perchild MPM and the T2 thread lib, mutex contention may cause performance penalty, I guess... Having just first seen your original post a few seconds ago, I wanted to point out a couple problems with the test you performed. The first problem is you had the client and the server on the same machine, which means that they were fighting each other for timeslices, which is bad. The second problem is AB isn't the greatest tool for measuring performance and concurrency. It is useful for a quick test, and for single-threaded performance, but terrible at testing the various threaded MPMs. -aaron
Re: Perchild on Solaris (was: Perchild works again.... kind of)
Tsuyoshi SASAMOTO wrote: On Solaris, this macro definition is required to build successfully: -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ By the way, with the perchild MPM, httpd performance is T2 (alternate) thread lib T1 (default) thread lib. when I was speaking to the sun people they said that in order to get better performance with the Solaris9(t2) threading we need to bind the processes to individual CPU's. http://groups.google.com/groups?[EMAIL PROTECTED] By contrast, with the worker MPM, T2 thread lib T1 thread lib (But the difference is smaller than the perchild MPM). some comments.. the stats seems high.. make sure you have the: Options FollowSymLinks AllowOverrides none specified also try 'AcceptMutex pthread' this worked better for my tests. there may be some other things, but I would need to see your config file. With the perchild MPM and the T2 thread lib, mutex contention may cause performance penalty, I guess... Tsuyoshi SASAMOTO [EMAIL PROTECTED]
Re: Perchild on Solaris
Having just first seen your original post a few seconds ago, I wanted to point out a couple problems with the test you performed. The first problem is you had the client and the server on the same machine, which means that they were fighting each other for timeslices, which is bad. The second problem is AB isn't the greatest tool for measuring performance and concurrency. It is useful for a quick test, and for single-threaded performance, but terrible at testing the various threaded MPMs. Thanks... I agree your suggestion, but currently, I don't have good 2 machines (one for server, other for client) that are suitable for load test. So, absolute values of those result are not so meaningful, and I want those result to be treated as a relative comparison between T1 and T2 thread lib. Tsuyoshi SASAMOTO [EMAIL PROTECTED]
Re: Perchild on Solaris
some comments.. the stats seems high.. make sure you have the: Options FollowSymLinks AllowOverrides none specified also try 'AcceptMutex pthread' this worked better for my tests. there may be some other things, but I would need to see your config file. Thanks... The previous config was: Options All MultiViews AllowOverride All I was interested in the relative comparison between T1 and T2 threads, so httpd.conf itself was not tuned well... Under config you suggested above and so on, the result is as below. Tsuyoshi SASAMOTO [EMAIL PROTECTED] -- Result of ab -c128 -n8192 127.0.0.1:3080/ [T1 thread lib]--- This is ApacheBench, Version 2.0.37-dev $Revision: 1.105 $ apache-2.0 : : Server Software:Apache/2.0.39 Server Hostname:127.0.0.1 Server Port:3080 Document Path: / Document Length:1630 bytes Concurrency Level: 128 Time taken for tests: 14.586689 seconds Complete requests: 8192 Failed requests:0 Write errors: 0 Total transferred: 15810560 bytes HTML transferred: 13352960 bytes Requests per second:561.61 [#/sec] (mean) Time per request: 227.917 [ms] (mean) Time per request: 1.781 [ms] (mean, across all concurrent requests) Transfer rate: 1058.50 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 1.3 0 84 Processing:29 224 24.9222 442 Waiting:3 112 65.8112 360 Total: 29 224 25.0222 444 Percentage of the requests served within a certain time (ms) 50%222 66%223 75%223 80%223 90%225 95%240 98%306 99%310 100%444 (longest request) [T2 thread lib]--- This is ApacheBench, Version 2.0.37-dev $Revision: 1.105 $ apache-2.0 : : Server Software:Apache/2.0.39 Server Hostname:127.0.0.1 Server Port:3080 Document Path: / Document Length:1630 bytes Concurrency Level: 128 Time taken for tests: 15.981754 seconds Complete requests: 8192 Failed requests:0 Write errors: 0 Total transferred: 15810560 bytes HTML transferred: 13352960 bytes Requests per second:512.58 [#/sec] (mean) Time per request: 249.715 [ms] (mean) Time per request: 1.951 [ms] (mean, across all concurrent requests) Transfer rate: 966.10 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.7 0 58 Processing:56 245 29.3266 398 Waiting:3 123 71.0123 307 Total: 56 246 29.3266 398 Percentage of the requests served within a certain time (ms) 50%266 66%267 75%268 80%268 90%270 95%271 98%284 99%285 100%398 (longest request) -- Result of truss -c -p (pid of the working httpd process) \ ab -c128 -n768 127.0.0.1:3080/ /dev/null; \ pkill -u $user -x truss [T1 thread lib]--- syscall seconds calls errors read .201540 5 write.12 768 close.201534 brk .31 774 times.05 768 sysi86 .02 40 fcntl.341536 sendfilev64 .28 768 poll .151540 sigaction.00 14 mmap .02 58 mprotect .07 184 lwp_sema_wait.02 283 lwp_sema_post.04 283 gettimeofday .704889 lwp_create .02 80 lwp_continue .01 40 lwp_self .04 141 lwp_mutex_wakeup .06 205 lwp_mutex_lock .15 971 lwp_cond_wait.05 157 lwp_cond_signal .04 157 lwp_schedctl .00 40 signotifywait.00 43 lwp_sigredirect .00 43 stat64 .251536 fstat64 .271536 open64 .301536768 accept .32 768 shutdown .17 767 getsockname .17 768 getsockopt .201536 setsockopt .11 768 lwp_mutex_unlock .12 768 --- -- sys totals: 4.80 26839773 usr time:.58 elapsed:8.54 [T2 thread lib]--- syscall seconds calls errors read .451542
Re: Perchild works again.... kind of
[EMAIL PROTECTED] wrote: Below is the commit message that I just msent for the perchild MPM. This MPM works again, but it still doesn't work well. Currently, I have used it to pass requests between processes, but it just isn't clean at all. I have had random failures, and I don't recommend putting this MPM into production at all. Hopefully in the next day or two I will have time to document how this MPM works, and I will have time to go through and continue to scrub this code and make it cleaner. It is unlikely that I will do much more work on the code itself for the next few weeks, because I only have access to a Linux box currently. Unfortunately, this is a threaded MPM, by definition, and debugging threads on Linux is the most painful thing you can do. I will be setting up an x86 Solaris machine soon though, and I will be able to use that box to debug this MPM. In the meantime, if anybody has a Solaris box that I can get access to, I would be more than happy to continue to fix bugs in this MPM. sourceforge.net has 2-3 solaris boxes you can you to build/test on in their compilefarm if that helps Hopefully, more commits tomorrow. Ryan rbb 2002/08/17 23:05:48 Modified:server/mpm/experimental/perchild perchild.c Log: This commit gets Perchild working again. There are holes in this code big enough to drive a truck through, and it is NOT production quality, but I have successfully passed file descriptors between processes and served requests over the passed descriptors. This code needs documenting, and vetting still. Also, in order to make things work, I had to insert the socket and the data read by the original process into the bottom of the filter stack so that the new process could use that information. Unfortunately, that isn't possible to do cleanly, so I search for the CORE_IN filter, and I insert a brigade that I have created into it's ctx pointer. This is a hack, and it means that Perchild _only_ works if you use the core filters. Until I find a better way to get that information to the bottom of the filter stack, that is just how it is going to be.
Re: perchild on FreeBSD 5?
Gabriel Ambuehl wrote: Hi Rasmus Lerdorf, you wrote. time spent in mutex-protected code is 99% of the total request processing time, then the server will scale poorly. The key success factor is to not use libraries that require locking for lengthy operations. RL If, for example, we have to mutex an entire database library and every So it is expected to break up, for example, PHP in libraries that do support threading explicitely and such that don't or aren't known to do it instead of having a mutex around all of PHP? No, not at all. The library partitioning is irrelevant: it's functions, not libraries, that have to be wrapped in mutexes if they're not thread-safe. Brian
Re: perchild on FreeBSD 5?
On Wed, Aug 14, 2002 at 10:36:53AM -0700, Brian Pane wrote: It's not entire libraries that will have to be mutexed, just calls to non-thread-safe functions within libraries. That will reduce the concurrency of the server, but in general not so severely that it's only serving one request at a time. Actually, it depends on the library. You could have multiple functions in a library that all dork with a common bit of non-thread-local state. You have to either mutex *all* calls to the library with one big lock, or examine the library to make sure that it's safe to do less
Re: perchild on FreeBSD 5?
Rasmus Lerdorf wrote: Hi Rasmus Lerdorf, you wrote. RL libraries as well. We are going to have to fix a bunch of them and mutex RL some others before Apache2 with a threaded MPM will be of any use with PHP RL or mod_perl. Am I correct assuming that when they are mutex'ed that there will be one instance of XX_lib PER perchild process, right? So eventually, each domain will be able to serve one request at a time? If we end up having to mutex, sure, if every request for that domain needs to access the mutxed library, then yes, you would only be able to serve up one request at a time from that domain. That's not accurate in general. The amount of serialization will depend on how much time you spend in mutexed operations in that library, relative to the entire request processing time. If the time spent in mutex-protected code is 1% of the total request processing time on an otherwise idle server, you'll see good concurrency as you add more requests. In contrast, if the time spent in mutex-protected code is 99% of the total request processing time, then the server will scale poorly. The key success factor is to not use libraries that require locking for lengthy operations. Brian
Re: perchild on FreeBSD 5?
Manoj Kasichainula wrote: On Wed, Aug 14, 2002 at 10:36:53AM -0700, Brian Pane wrote: It's not entire libraries that will have to be mutexed, just calls to non-thread-safe functions within libraries. That will reduce the concurrency of the server, but in general not so severely that it's only serving one request at a time. Actually, it depends on the library. You could have multiple functions in a library that all dork with a common bit of non-thread-local state. You have to either mutex *all* calls to the library with one big lock, or examine the library to make sure that it's safe to do less Certainly if the threaded lib is bogus, then it's best to avoid the threaded MPM. trying to emulate threaded libs by mutexing non-thread-safe libs is pretty nasty. So we are interested in only the n-t-s functions (I would call the multiple functions with commit bit n-t-s) -- === 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: perchild on FreeBSD 5?
Greg Ames wrote: Rasmus Lerdorf wrote: My point is that people blindly install the latest stable PHP with the latest stable Apache and they end up something that is not stable at all. They don't understand what an MPM is, much less which MPM to use for what. OK, so this set of users will get the default MPM which is prefork. So non-threadsafe libraries aren't an issue for them, right? You have to be slightly more adventurous to get a threaded MPM. True for now, but: * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing) -0: Lars -- Scott Lamb
Re: perchild on FreeBSD 5?
On Wed, 14 Aug 2002, Scott Lamb wrote: True for now, but: * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker I might remove my vote. Note that even though the current majority of votes is for rather than against, it hasn't happened because we've been generally uneasy with it (and/or just didn't get around to it, but mostly the former IMO). Thread safety of external libraries is probably one of the reasons for that uneasiness. --Cliff
Re: perchild on FreeBSD 5?
Hello, I've more or less accepted that perchild on FreeBSD 4.X isn't going to happen (as sad as it is, I always considered it to be THE feature [1] in 2.0 that would warrant an upgrade for us) but what I'd like to know is if there is any chance to see perchild on FreeBSD 5 which gets wholly new threading and SMP libs? I agree, and I have been preaching the same thing for a while. Almost no point in releasing Apache2 without a working perchild. Unfortunately there are other issues as well. A lot of the 3rd party libs that something like PHP or mod_perl depends on are not necessarily threadsafe. As witnessed by FreeBSD's incredibly buggy threading code there aren't a lot of things using threads heavily on UNIX. With some notable exceptions, of course, but very few try to pull in 30 or 40 3rd-party libraries as well. We are going to have to fix a bunch of them and mutex some others before Apache2 with a threaded MPM will be of any use with PHP or mod_perl. And I am not sure how to go about identifying the libraries that aren't qiute threadsafe. Problems generally only show up under load and only in certain circumstances. Especially for the libraries that claim to be threadsafe but aren't quite for whatever reason. -Rasmus
Re: perchild on FreeBSD 5?
Rasmus Lerdorf [EMAIL PROTECTED] wrote: Hello, I've more or less accepted that perchild on FreeBSD 4.X isn't going to happen (as sad as it is, I always considered it to be THE feature [1] in 2.0 that would warrant an upgrade for us) but what I'd like to know is if there is any chance to see perchild on FreeBSD 5 which gets wholly new threading and SMP libs? I agree, and I have been preaching the same thing for a while. Almost no point in releasing Apache2 without a working perchild. Unfortunately there are other issues as well. A lot of the 3rd party libs that something like PHP or mod_perl depends on are not necessarily threadsafe. As witnessed by FreeBSD's incredibly buggy threading code there aren't a lot of things using threads heavily on UNIX. With some notable exceptions, of course, but very few try to pull in 30 or 40 3rd-party libraries as well. We are going to have to fix a bunch of them and mutex some others before Apache2 with a threaded MPM will be of any use with PHP or mod_perl. And I am not sure how to go about identifying the libraries that aren't qiute threadsafe. Problems generally only show up under load and only in certain circumstances. Especially for the libraries that claim to be threadsafe but aren't quite for whatever reason. Luckily, in Java land things are more or less brighter, and I can say that for what matters to me (I don't use PHP on big production servers, apart from a couple of things which are thread safe - IMP and related), the threaded MPM is giving me nothing but joy every single friggin' day! :) Keep up the gud staf guys! :) Pier (working his ass off on a deadline!)
RE: perchild on FreeBSD 5?
Rasmus Lerdorf [EMAIL PROTECTED] wrote: Hello, I've more or less accepted that perchild on FreeBSD 4.X isn't going to happen (as sad as it is, I always considered it to be THE feature [1] in 2.0 that would warrant an upgrade for us) but what I'd like to know is if there is any chance to see perchild on FreeBSD 5 which gets wholly new threading and SMP libs? I agree, and I have been preaching the same thing for a while. Almost no point in releasing Apache2 without a working perchild. Unfortunately there are other issues as well. A lot of the 3rd party libs that something like PHP or mod_perl depends on are not necessarily threadsafe. As witnessed by FreeBSD's incredibly buggy threading code there aren't a lot of things using threads heavily on UNIX. With some notable exceptions, of course, but very few try to pull in 30 or 40 3rd-party libraries as well. We are going to have to fix a bunch of them and mutex some others before Apache2 with a threaded MPM will be of any use with PHP or mod_perl. And I am not sure how to go about identifying the libraries that aren't qiute threadsafe. Problems generally only show up under load and only in certain circumstances. Especially for the libraries that claim to be threadsafe but aren't quite for whatever reason. Luckily, in Java land things are more or less brighter, and I can say that for what matters to me (I don't use PHP on big production servers, apart from a couple of things which are thread safe - IMP and related), the threaded MPM is giving me nothing but joy every single friggin' day! :) Keep up the gud staf guys! :) Pier (working his ass off on a deadline!) I agree with Pier, the threaded MPM has been a real lifesaver. Supporting 10,000+ concurrent clients with Apache 1.3 (including some complex modules) on AIX and Solaris is practically impossible. Quite doable with Apache 2.0 and the worker MPM. Bill
Re: perchild on FreeBSD 5?
Pier Fumagalli wrote: Rasmus Lerdorf [EMAIL PROTECTED] wrote: Hello, I've more or less accepted that perchild on FreeBSD 4.X isn't going to happen (as sad as it is, I always considered it to be THE feature [1] in 2.0 that would warrant an upgrade for us) but what I'd like to know is if there is any chance to see perchild on FreeBSD 5 which gets wholly new threading and SMP libs? I agree, and I have been preaching the same thing for a while. Almost no point in releasing Apache2 without a working perchild. Unfortunately there are other issues as well. A lot of the 3rd party libs that something like PHP or mod_perl depends on are not necessarily threadsafe. As witnessed by FreeBSD's incredibly buggy threading code there aren't a lot of things using threads heavily on UNIX. With some notable exceptions, of course, but very few try to pull in 30 or 40 3rd-party libraries as well. We are going to have to fix a bunch of them and mutex some others before Apache2 with a threaded MPM will be of any use with PHP or mod_perl. And I am not sure how to go about identifying the libraries that aren't qiute threadsafe. Problems generally only show up under load and only in certain circumstances. Especially for the libraries that claim to be threadsafe but aren't quite for whatever reason. Luckily, in Java land things are more or less brighter, and I can say that for what matters to me (I don't use PHP on big production servers, apart from a couple of things which are thread safe - IMP and related), the threaded MPM is giving me nothing but joy every single friggin' day! :) Keep up the gud staf guys! :) I'd just like to iterate that the WORKER and the threaded MPM do work. and make it worth considering apache 2.0 for production environments, where you are seeing your memory requirements get pushed to the limits, we have seen 1.3's servers happily use 1-4G of memory on our production boxes. under the same loads we see ~500M usage with 2.0 --Ian Pier (working his ass off on a deadline!)
RE: perchild on FreeBSD 5?
I agree with Pier, the threaded MPM has been a real lifesaver. Supporting 10,000+ concurrent clients with Apache 1.3 (including some complex modules) on AIX and Solaris is practically impossible. Quite doable with Apache 2.0 and the worker MPM. I am sure it does, but you also need to recognize that around 40% of all Apache installations have PHP on them. And 30% or so have mod_perl. Many actually have both, so there is some overlap, but I would say that over half of all Apache installs have one or both of PHP or mod_perl. Apache 2 is being pitched as a production-quality web server without any mention of the fact that over half of the current Apache sites probably should not upgrade at this point. -Rasmus
RE: perchild on FreeBSD 5?
I agree with Pier, the threaded MPM has been a real lifesaver. Supporting 10,000+ concurrent clients with Apache 1.3 (including some complex modules) on AIX and Solaris is practically impossible. Quite doable with Apache 2.0 and the worker MPM. I am sure it does, but you also need to recognize that around 40% of all Apache installations have PHP on them. And 30% or so have mod_perl. Many actually have both, so there is some overlap, but I would say that over half of all Apache installs have one or both of PHP or mod_perl. Apache 2 is being pitched as a production-quality web server without any mention of the fact that over half of the current Apache sites probably should not upgrade at this point. This is definitely worth mentioning in the 2.0 Announcements. Have the problems in mod_perl and mod_php been identified, so folks can at least make an educated guess whether their site will tickle the known bugs? Bill
RE: perchild on FreeBSD 5?
I am sure it does, but you also need to recognize that around 40% of all Apache installations have PHP on them. And 30% or so have mod_perl. Many actually have both, so there is some overlap, but I would say that over half of all Apache installs have one or both of PHP or mod_perl. Apache 2 is being pitched as a production-quality web server without any mention of the fact that over half of the current Apache sites probably should not upgrade at this point. This is definitely worth mentioning in the 2.0 Announcements. Have the problems in mod_perl and mod_php been identified, so folks can at least make an educated guess whether their site will tickle the known bugs? Nope, we really have no idea which libraries are threadsafe and which ones aren't. -Rasmus
Re: perchild on FreeBSD 5?
Assuming that FreeBSD 5 solves the threading problems with FreeBSD, then yes, Perchild will work on that platform. The problem right now is that PErchild doesn't work at all. I am hoping to have time to work on PErchild on Thursday or Friday to finish the work on that MPM. Ryan On Tue, 13 Aug 2002, Gabriel Ambuehl wrote: Hello, I've more or less accepted that perchild on FreeBSD 4.X isn't going to happen (as sad as it is, I always considered it to be THE feature [1] in 2.0 that would warrant an upgrade for us) but what I'd like to know is if there is any chance to see perchild on FreeBSD 5 which gets wholly new threading and SMP libs? My company would happily pay someone a few thousand US$ to come up with a working perchild implementation on FreeBSD 5 and from what I've gathered on the FreeBSD mailing lists, there might be other parties that would contribute to the funding, too. We haven't got any reasonable in-house knowhow to contribute with code but we'd surely help beta testing. [1] Name based vhosts with PHP scripts running under the UID of the user. Great for all ISPs out there. Regards, Gabriel -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: perchild no compilee, includes tests failing
On Monday 26 November 2001 09:39 am, Aaron Bannert wrote: I'm seeing problems with data types in system headers on my solaris box when I try to compile perchild: perchild.c:1421: structure has no member named `msg_control' perchild.c:1422: structure has no member named `msg_controllen' perchild.c:1423: structure has no member named `msg_flags' ... These are only defined in the msghdr struct (in /usr/include/sys/socket.h) under two circumstances (see /usr/include/sys/feature_tests.h): - UNIX 95 impl: must define _XOPEN_SOURCE and * _XOPEN_SOURCE_EXTENDED=1 - UNIX 98 impl: must define _XOPEN_SOURCE=500 I'm not seeing either of these symbols defined anywhere in our source or as parameters to the compiler (including implicit parameters passed by libtool). Is this something we should APR-ize away? Long-term it needs to be APR-ized, but the whole MPM needs to be fixed first. This is on my short list for this week. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: perchild no compilee, includes tests failing
On Saturday 24 November 2001 03:06 pm, Rodent of Unusual Size wrote: Ryan Bloom wrote: On Friday 23 November 2001 09:18 am, Ian Holsman wrote: try backing out ryan's change to core.c which was made a couple of days ago. That should fix the mod-include problem. I didn't get Ian's original message (?), but it looks as though 2.0.28 is failing the same includes tests. Verifying now.. All of the includes tests are passing now. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: perchild no compilee, includes tests failing
On Saturday 24 November 2001 03:55 pm, Rodent of Unusual Size wrote: * On 2001-11-24 at 18:49, Rodent of Unusual Size [EMAIL PROTECTED] excited the electrons to say: I didn't get Ian's original message (?), but it looks as though 2.0.28 is failing the same includes tests. Verifying now.. Yep, 2.0.28 is also failing some of the includes tests as they currently exist in httpd-test/perl-framework. However, those are real failures, not protocol errors, so maybe Ryan's change has something to do with it. Couldn't be, because that change went in long after 2.0.28. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: perchild no compilee, includes tests failing
Ryan Bloom wrote: On Saturday 24 November 2001 03:55 pm, Rodent of Unusual Size wrote: * On 2001-11-24 at 18:49, Yep, 2.0.28 is also failing some of the includes tests as they currently exist in httpd-test/perl-framework. However, those are real failures, not protocol errors, so maybe Ryan's change has something to do with it. Couldn't be, because that change went in long after 2.0.28. Um, you misunderstood -- I meant that the core.c change may have been causing the protocol errors, not the 2.0.28 failures. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: perchild no compilee, includes tests failing
* On 2001-11-24 at 18:49, Rodent of Unusual Size [EMAIL PROTECTED] excited the electrons to say: I didn't get Ian's original message (?), but it looks as though 2.0.28 is failing the same includes tests. Verifying now.. Yep, 2.0.28 is also failing some of the includes tests as they currently exist in httpd-test/perl-framework. However, those are real failures, not protocol errors, so maybe Ryan's change has something to do with it. As far as that goes, notice that 2.0.28 fails some of the mod_cgi subtests as well -- but only on the worker MPM; prefork seems okey CGI-wise. Only the work test output is listed below. ###Test: Platform: Linux 2.2.14-5.0 i686 unknown ###Test: Working with CVS revision APACHE_2_0_28 ###Test: Building with ./configure options: ###Test: --enable-auth-anon ###Test: --enable-auth-digest ###Test: --enable-case-filter ###Test: --enable-case-filter-in ###Test: --enable-cgi ###Test: --enable-echo ###Test: --enable-expires ###Test: --enable-headers ###Test: --enable-info ###Test: --enable-maintainer-mode ###Test: --enable-mime-magic ###Test: --enable-optional-hook-export ###Test: --enable-optional-hook-import ###Test: --enable-rewrite ###Test: --enable-speling ###Test: --enable-unique-id ###Test: --enable-usertrack ###Test: --enable-vhost-alias ###Test: --prefix=/tmp/ap2/server ###Test: Locking work area: done. ###Test: Checking out: httpd-2.0 ###Test: Checking out: httpd-test ###Test: Disabling passbrigade test ###Test: Checking out: apr ###Test: Checking out: apr-util ###Test: Preprocessing: buildconf ###Test: Preprocessing: configure ###Test: Preprocessing: make distclean ###Test: MPM-Start: worker ###Test: configure ###Test: make ###Test: make install ###Test: make distclean ###Test: perl Makefile.PL ###Test: t/TEST -stop ###Test: t/TEST -clean ###Test: t/TEST -configure ###Test: Running tests [33msetting ulimit to allow core files ulimit -c unlimited exec t/TEST [0m /tmp/ap2/server/bin/httpd -d /tmp/ap2/httpd-test/perl-framework/t -f /tmp/ap2/httpd-test/perl-framework/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.28 (worker MPM) waiting for server to start: 00:00 waiting for server to start: 00:01 waiting for server to start: ok (waited 1 secs) server localhost:8529 started server localhost:8530 listening (mod_headers) server localhost:8531 listening (mod_echo) server localhost:8532 listening (mod_vhost_alias) apache/404..ok apache/byterangeok apache/getfile..ok apache/limits...FAILED tests 9-10 Failed 2/10 tests, 80.00% okay apache/options..ok apache/post.ok apache/rwrite...ok apr/uri.ok filter/case.ok filter/case_in..ok filter/input_body...ok http11/basicauthok http11/chunked..ok modules/access..ok modules/alias...ok modules/autoindex...ok modules/cgi.FAILED tests 2, 4, 10, 12, 14, 16, 18, 20, 22, 24-27, 29-36 Failed 21/36 tests, 41.67% okay modules/dav.skipped: cannot find module 'dav', cannot find module 'HTTP::DAV' modules/dir.ok modules/env.ok modules/expires.ok modules/headers.ok modules/include.FAILED tests 32-33, 39 Failed 3/39 tests, 92.31% okay modules/infook modules/negotiation.ok modules/rewrite.ok modules/setenvifok modules/status..ok modules/vhost_alias.ok protocol/echo...ok protocol/nntp-like..skipped: cannot find module 'mod_ssl', cannot find module 'Net::SSL', cannot find module 'mod_nntp_like' ssl/all.skipped: cannot find module 'mod_ssl', cannot find module 'LWP::Protocol::https' Failed Test Status Wstat Total Fail Failed List of failed --- apache/limits.t 102 20.00% 9-10 modules/cgi.t36 21 58.33% 2, 4, 10, 12, 14, 16, 18, 20, 22, 24-27, 29-36 modules/include 393 7.69% 32-33, 39 3 tests skipped. [33mserver localhost:8529 shutdown[0m [1;31merror running tests (please examine t/logs/error_log)[0m Failed 3/32 test scripts, 90.62% okay. 26/1893 subtests failed, 98.63% okay. ###Test: MPM-End: worker ###Test: Unlocking work area -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: perchild no compilee, includes tests failing
Ryan Bloom wrote: On Friday 23 November 2001 09:18 am, Ian Holsman wrote: try backing out ryan's change to core.c which was made a couple of days ago. That should fix the mod-include problem. I didn't get Ian's original message (?), but it looks as though 2.0.28 is failing the same includes tests. Verifying now.. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: perchild no compilee, includes tests failing
On Fri, 2001-11-23 at 09:05, Rodent of Unusual Size wrote: I'm working on a script to run through building and testing all of the Unixish MPMs on RH Linux x86, RH Linux Alpha, and T64U. Below are some interim results. Would anyone be interested in an automailing of this stuff? (Probably with invariant successful bits not included..) try backing out ryan's change to core.c which was made a couple of days ago. That should fix the mod-include problem. the perchild MPM still references the client_socket.. this was changed a while ago.. have a look at the other MPM's on how to get to the client_socket (I think you need to go via get_config or something like that) ###Test: Platform: Linux 2.2.14-5.0 i686 unknown ###Test: Working with CVS revision HEAD ###Test: Building with ./configure options: ###Test: --enable-auth-anon ###Test: --enable-auth-digest ###Test: --enable-case-filter ###Test: --enable-case-filter-in ###Test: --enable-cgi ###Test: --enable-echo ###Test: --enable-expires ###Test: --enable-headers ###Test: --enable-info ###Test: --enable-maintainer-mode ###Test: --enable-mime-magic ###Test: --enable-optional-hook-export ###Test: --enable-optional-hook-import ###Test: --enable-rewrite ###Test: --enable-speling ###Test: --enable-unique-id ###Test: --enable-usertrack ###Test: --enable-vhost-alias ###Test: --prefix=/tmp/ap2/server ###Test: Locking work area: done. ###Test: Checking out: httpd-2.0 ###Test: Checking out: httpd-test ###Test: Disabling passbrigade test ###Test: Checking out: apr ###Test: Checking out: apr-util ###Test: Preprocessing: buildconf ###Test: Preprocessing: configure ###Test: Preprocessing: make distclean ###Test: MPM-Start: prefork ###Test: configure ###Test: make ###Test: make install ###Test: make distclean ###Test: perl Makefile.PL ###Test: t/TEST -stop ###Test: t/TEST -clean ###Test: t/TEST -configure ###Test: Running tests [33msetting ulimit to allow core files ulimit -c unlimited exec t/TEST [0m /tmp/ap2/server/bin/httpd -d /tmp/ap2/httpd-test/perl-framework/t -f /tmp/ap2/httpd-test/perl-framework/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.29-dev (prefork MPM) waiting for server to start: 00:00 waiting for server to start: 00:01 waiting for server to start: ok (waited 1 secs) server localhost:8529 started server localhost:8530 listening (mod_headers) server localhost:8531 listening (mod_echo) server localhost:8532 listening (mod_vhost_alias) server localhost:8533 listening (mod_nntp_like) apache/404..ok apache/byterangeok apache/getfile..ok apache/limits...FAILED tests 9-10 Failed 2/10 tests, 80.00% okay apache/options..ok apache/post.ok apache/rwrite...ok apr/uri.ok filter/case.ok filter/case_in..ok filter/input_body...ok http11/basicauthok http11/chunked..ok modules/access..ok modules/alias...ok modules/autoindex...ok modules/cgi.ok modules/dav.skipped: cannot find module 'dav', cannot find module 'HTTP::DAV' modules/dir.ok modules/env.ok modules/expires.ok modules/headers.ok modules/include.response had protocol HTTP/0.9 (headers not sent?) at ../Apache-Test/lib/Apache/TestRequest.pm line 354. dubious Test returned status 9 (wstat 2304, 0x900) DIED. FAILED tests 2-39 Failed 38/39 tests, 2.56% okay modules/infook modules/negotiation.ok modules/rewrite.ok modules/setenvifok modules/status..ok modules/vhost_alias.ok protocol/echo...ok protocol/nntp-like..ok ssl/all.skipped: cannot find module 'mod_ssl', cannot find module 'LWP::Protocol::https' Failed Test Status Wstat Total Fail Failed List of failed --- apache/limits.t 102 20.00% 9-10 modules/include 9 230439 38 97.44% 2-39 2 tests skipped. [33mserver localhost:8529 shutdown[0m [1;31merror running tests (please examine t/logs/error_log)[0m Failed 2/32 test scripts, 93.75% okay. 40/1898 subtests failed, 97.89% okay. ###Test: MPM-End: prefork ###Test: MPM-Start: worker ###Test: configure ###Test: make ###Test: make install ###Test: make distclean ###Test: perl Makefile.PL ###Test: t/TEST -stop ###Test: t/TEST -clean ###Test: t/TEST -configure ###Test: Running tests [33msetting ulimit to allow core files ulimit -c unlimited exec t/TEST [0m /tmp/ap2/server/bin/httpd -d /tmp/ap2/httpd-test/perl-framework/t -f /tmp/ap2/httpd-test/perl-framework/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.29-dev (worker MPM) waiting for server to start: 00:00 waiting for server to start: 00:01 waiting for server to start: 00:02 waiting for server to start: ok (waited 2 secs) server localhost:8529 started server localhost:8530 listening (mod_headers) server localhost:8531
