Re: Re: Anyone interested in a patch to mod_fcgid(with pay)
Yes, split process control from mod_fcgid, merge proxy_fcgi(with load balance) and mod_fcgid(with authXX support) is a good idea, admins can use httpd as process manager, or 3rd party process managers as they like. But don't just make a patch to make mod_fcgid support TCP/IP, it's ugly... Hi, guys A company need a TCP/IP patch of mod_fcgid or alternative, and will pay for it, anyone interested? I really like to take it but I don't have too much time... Anyone interested please reply to me and I will forward the email address of them. ... Neti only listens on TCP/IP socket, it assumes both an authorizer role and a responder role in the Fast CGI request. Here's the 3 candidate Apache modules to interface Neti: ... 2. Mod_proxy_fcgi: this module supports TCP socket, it can connect to Neti, but it doesn't support authorizer role. So in the first FCGI request, it forwards the request to Neti as a responder instead of an authorizer, Neti cannot simply let it through without properly authorizing it first, thus the request fails; 3. Mod_fcgid: this module supports authorizer role while doesn't support TCP connection. We cannot confirm its authorizer role since it doesn't even connect to Neti due to lack of TCP; So our choice is between either adding authorizer role to mod_proxy_fcgi or adding TCP/IP to mod_fcgid. We’re really willing to pay to have this project done, I mean either adding proxy to mod_fcgid or adding authorizer to mod_proxy_fcgi. Are you willing to work on this with reward or do you know anyone else who’s interested in doing so with pay, for example, author of mod_proxy_fcgi? (I cannot find his name) No cycles myself at this instant, but it seems overtime to break apart the mod_fcgid process-control so that it can then stack on top of a single mod_proxy_fcgi communications pipe, dispatched through different fcgi-stream methods (including child process stdio), including the various authn/authz roles. It would take more time to refactor it in this way, but would get rid of any discrepancies between proxy_fcgi and fcgid and serve as a good excuse to draw the remaining mod_fcgid development back into trunk/, now that fcgid is generally sufficient for 2.2 users.
Anyone interested in a patch to mod_fcgid(with pay)
Hi, guys A company need a TCP/IP patch of mod_fcgid or alternative, and will pay for it, anyone interested? I really like to take it but I don't have too much time... Anyone interested please reply to me and I will forward the email address of them. Our company is hosting a website with a lot of users. Each user needs login to access our server. We have an in-house FCGI program responsible for authenticate user's credentials. The FCGI program is called “Neti”;. Right now Neti works fine with Zeus server, however we want to switch to Apache server. Neti only listens on TCP/IP socket, it assumes both an authorizer role and a responder role in the Fast CGI request. Here's the 3 candidate Apache modules to interface Neti: 1. Mod_fastcgi: this module has NOT been updated since 2007. It will break randomly, (not only with Neti, but with some other FCGIs), so we're not planning to pursue it; 2. Mod_proxy_fcgi: this module supports TCP socket, it can connect to Neti, but it doesn't support authorizer role. So in the first FCGI request, it forwards the request to Neti as a responder instead of an authorizer, Neti cannot simply let it through without properly authorizing it first, thus the request fails; 3. Mod_fcgid: this module supports authorizer role while doesn't support TCP connection. We cannot confirm its authorizer role since it doesn't even connect to Neti due to lack of TCP; So our choice is between either adding authorizer role to mod_proxy_fcgi or adding TCP/IP to mod_fcgid. We’re really willing to pay to have this project done, I mean either adding proxy to mod_fcgid or adding authorizer to mod_proxy_fcgi. Are you willing to work on this with reward or do you know anyone else who’s interested in doing so with pay, for example, author of mod_proxy_fcgi? (I cannot find his name) Ryan
Re: Re: Re: mod_fcgid concurrency bottleneck, issue#53693
Hi, all
I took some times to setup a stress test for mod_fcgid, to see is there any
other concurrency bottleneck left, it seems fine to me.
I did a stress test with callgrind on mod_fcgid, this is the big picture:
http://people.apache.org/~pqf/mod_fcgid_performance/performance.png and this is
the output of callgrind:
http://people.apache.org/~pqf/mod_fcgid_performance/callgrind.out
As we can see, most cpu time are used in ap_create_environment() +
init_environment(). ap_create_environment() copy environment vars to a char[][]
buffer, and init_environment() copy char[][] to a char[] buffer for FCGI
protocol. I have to keep using ap_create_environment() to be compatible with
other cgi modules(cgid, cgi...), I will not shortcut these two calls for less
cpu utils.
And I make a strace trace to the system calls, to make sure there is no obvious
IO throughput bottleneck, and no luck either
4622 13:17:16.737888 ... futex resumed ) = 0
4622 13:17:16.737920 futex(0x95ce65c, FUTEX_WAKE, 1 unfinished ...
4622 13:17:16.738038 ... futex resumed ) = 0
4622 13:17:16.740735 gettimeofday({1346217436, 740787}, NULL) = 0
4622 13:17:16.740835 getsockname(12, {sa_family=AF_INET6,
sin6_port=htons(8080), inet_pton(AF_INET6, :::127.0.0.1, si
n6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
4622 13:17:16.741008 fcntl64(12, F_GETFL) = 0x2 (flags O_RDWR)
4622 13:17:16.741056 fcntl64(12, F_SETFL, O_RDWR|O_NONBLOCK) = 0
4622 13:17:16.741824 gettimeofday({1346217436, 741849}, NULL) = 0
4622 13:17:16.741890 gettimeofday({1346217436, 741911}, NULL) = 0
4622 13:17:16.741969 read(12, GET /fcgi-bin/foo.pl HTTP/1.0\r\nH..., 8000) =
97
4622 13:17:16.742049 gettimeofday({1346217436, 742070}, NULL) = 0
4622 13:17:16.742108 gettimeofday({1346217436, 742129}, NULL) = 0
4622 13:17:16.742165 gettimeofday({1346217436, 742185}, NULL) = 0
4622 13:17:16.74 gettimeofday({1346217436, 742242}, NULL) = 0
4622 13:17:16.742278 gettimeofday({1346217436, 742299}, NULL) = 0
4622 13:17:16.742345 gettimeofday({1346217436, 742367}, NULL) = 0
4622 13:17:16.742404 gettimeofday({1346217436, 742424}, NULL) = 0
4622 13:17:16.742467 stat64(/usr/local/apache2/htdocs/fcgi-bin/foo.pl,
{st_mode=S_IFREG|0755, st_size=229, ...}) = 0
4622 13:17:16.742697 semop(4292662, 0x17234c, 1) = 0
4622 13:17:16.742750 semop(4292662, 0x172358, 1) = 0
4622 13:17:16.742804 socket(PF_FILE, SOCK_STREAM, 0) = 13
4622 13:17:16.742864 connect(13, {sa_family=AF_FILE,
path=/usr/local/apache2/logs/fcgidsock/4617.11}, 110) = 0
4622 13:17:16.743028 fcntl64(13, F_GETFL) = 0x2 (flags O_RDWR)
4622 13:17:16.743074 fcntl64(13, F_SETFL, O_RDWR|O_NONBLOCK) = 0
4622 13:17:16.743118 gettimeofday({1346217436, 743138}, NULL) = 0
4622 13:17:16.743174 writev(13, [{\1\1\0\1\0\10\0\0, 8},
{\0\1\0\0\0\0\0\0, 8}, {\1\4\0\1\3U\0\0, 8}, {\t\30UNIQUE_ID
UD2l3MCoqlsAABILpXoAA..., 853}, {\1\4\0\1\0\0\0\0, 8}, {\1\5\0\1\0\0\0\0,
8}], 6) = 893
4622 13:17:16.743337 read(13, 0xa6f4c5b8, 8192) = -1 EAGAIN (Resource
temporarily unavailable)
4622 13:17:16.743386 poll([{fd=13, events=POLLIN, revents=POLLIN}], 1, 4)
= 1
4622 13:17:16.743789 read(13, \1\6\0\1\3\266\2\0Content-Type: text/plain...,
8192) = 984
4622 13:17:16.743879 gettimeofday( unfinished ...
4622 13:17:16.743968 ... gettimeofday resumed {1346217436, 743943}, NULL) = 0
4622 13:17:16.744037 close(13) = 0
4622 13:17:16.744101 semop(4292662, 0x17234c, 1) = 0
4622 13:17:16.744149 semop(4292662, 0x172358, 1) = 0
4622 13:17:16.744209 gettimeofday({1346217436, 744231}, NULL) = 0
4622 13:17:16.744266 gettimeofday({1346217436, 744287}, NULL) = 0
4622 13:17:16.744343 writev(12, [{HTTP/1.1 200 OK\r\nDate: Wed, 29 A...,
154}, {CONTEXT_DOCUMENT_ROOT=\/usr/loca..., 92
4}], 2 unfinished ...
4622 13:17:16.745033 ... writev resumed ) = 1078
4622 13:17:16.745076 gettimeofday({1346217436, 745098}, NULL) = 0
4622 13:17:16.745148 times({tms_utime=1416, tms_stime=1464, tms_cutime=0,
tms_cstime=0}) = 499844951
4622 13:17:16.745255 gettimeofday( unfinished ...
4622 13:17:16.745800 ... gettimeofday resumed {1346217436, 745791}, NULL) = 0
4622 13:17:16.746013 shutdown(12, 1 /* send */ unfinished ...
4622 13:17:16.746554 ... shutdown resumed ) = 0
4622 13:17:16.746625 gettimeofday( unfinished ...
4622 13:17:16.746684 ... gettimeofday resumed {1346217436, 746658}, NULL) = 0
4622 13:17:16.746765 epoll_ctl(11, EPOLL_CTL_ADD, 12, {EPOLLIN,
{u32=158210764, u64=158210764}} unfinished ...
4622 13:17:16.746833 ... epoll_ctl resumed ) = 0
4622 13:17:16.747587 gettimeofday( unfinished ...
4622 13:17:16.747904 ... gettimeofday resumed {1346217436, 747649}, NULL) = 0
4622 13:17:16.748672 futex(0x95ce690, FUTEX_WAIT, 176390, NULL unfinished ...
2012-09-05
pqf
发件人：pqf
发送时间：2012-08-28 09:34
主题：回复: Re: Re: Re: mod_fcgid concurrency bottleneck, issue#53693
收件人：devdev@httpd.apache.org
抄送：
So what can mod_fcgid do in this overloaded?
1. mod_fcgid get a request
2. mod_fcgid can't apply a free slot
Re: Pull request: server/util_md5.c:58 - replace magic number with constant arithmetic
Some C compilers don't support this: result[2*APR_MD5_DIGESTSIZE+1] ? Hello, dev@. I request a little change to HTTPD code. On line 58 of server/util_md5.c, please replace char *r, result[33]; /* (MD5_DIGESTSIZE * 2) + 1 */ with char *r, result[2*APR_MD5_DIGESTSIZE+1]; There's only constant arithmetic here, so I don't see a reason to pre-calculate the size here, and other code files use 2*APR_MD5_DIGESTSIZE+1 often. Thanks, SiPlus
回复: Re: Re: Re: mod_fcgid concurrency bottleneck, issue#53693
So what can mod_fcgid do in this overloaded?
1. mod_fcgid get a request
2. mod_fcgid can't apply a free slot of FCGI handler
3. mod_fcgid send a spawn request to PM
4. PM deny the request(for too much process already)
5. Now
for( i=1; i64; i++)
{
a) mod_fcgid delay a while, and then send another spawn request to PM and
try apply free slot again.
b) mod_fcgid send another spawn request at once, even the last request is
denied.
c) ??
(now is a, b maybe not a good idea, any new idea?)
}
I think the bottleneck is too much request, too less FCGI handler. httpd(or
mod_fcgid) either drop client connections or delay a while, there is no other
way out?
Another question. Is it necessary to call procmgr_init_spawn_cmd() from inside
the for loop ?
I took a brief look, it seems not necessary. I will move it out of loop and
test.
2012-08-28
pqf
发件人：Lazy
发送时间：2012-08-27 21:47
主题：Re: Re: Re: mod_fcgid concurrency bottleneck, issue#53693
收件人：devdev@httpd.apache.org
抄送：
2012/8/16 pqf p...@mailtech.cn:
How about this:
1. procmgr_post_spawn_cmd() now return a status code from PM, so process
handler now know the spawn request is denyed or not.
2. if a new process is created, no sleep is needed.
3. if no process is created, sleep a while
sorry for the late reply,
in the old code there ware no sleep() between procmgr_post_spawn_cmd()
and apply_free_procnode()
sleep() was invoked only if there ware no free procnode.
This happened only if we ware denied spawning new process or in some
cases if some other thread managed to use that procnode before us.
Your change adresses cases if some other thread stole our newly
spawned fcgi process, old code was waiting 1s before trying to spawn
another/recheck, new code doesn't, I guess this is the orginal issue
in stress tests when total number of simultaneous connections doesn't
exceed max fcgi processes. But when spawning is denied recovery time
is still long 1s.
I was refering to cases when spawn is denied.
If a vhost is overloaded or someone added sleep(60) in the code,
mod_fcgid blocks on all request to that vhost
for over a minute and it is possible to occupy 1000 threads using
under 20 new connections to slow vhost
per second. This can be mitingated by adding avaiability which will
impact time spend on waiting for free process. Overloaded vhost will
start to drop connections faster preventing the web-server reaching
MaxClients
limit.
Another question. Is it necessary to call procmgr_init_spawn_cmd()
from inside the for loop ?
2012-08-16
pqf
发件人：Lazy
发送时间：2012-08-16 16:47
主题：Re: Re: mod_fcgid concurrency bottleneck, issue#53693
收件人：devdev@httpd.apache.org
抄送：
2012/8/16 pqf p...@mailtech.cn:
Hi, Michal
My solution do add availability to each class, which is the
procmgr_post_spawn_cmd() call in each loop do.
The sleep() call is intrudused for a stress test without warm up time, in
this case, mod_fcgid will create more processes than a slow start one(each
process handler can't apply a free slot on the very begining, so send a
request to process manager to create one, it's easy to reach the max # of
process limit while httpd startup, but the idle process will be killed
later), the sleep() call is a little like a server side warm up delay.
But since someone said remove this sleep(), the server work fine without
bottleneck(Maybe he didn't notise the warm up issue?), so I thought remove
the sleep() is a good idea. But reduce the time of sleep() is fine to me
too.
I was referring to the case where all processes are busy, without
sleep(), handle_request() wil quickly send spawn requsts, whith will
be denyed by process menager, with sleep() handle_request() will
always wait quite a long time,
occupying slots
--
Michal Grzedzicki
Re: Re: mod_fcgid concurrency bottleneck, issue#53693
procmgr_post_spawn_cmd(maybe it should be renamed to procmgr_send_spawn_cmd) will keep blocking while PM is creating a new process, after procmgr_post_spawn_cmd() return, there should be a process ready there waiting for accept. 2012-08-16 pqf 发件人：William A. Rowe Jr. 发送时间：2012-08-16 15:23 主题：Re: mod_fcgid concurrency bottleneck, issue#53693 收件人：devdev@httpd.apache.org 抄送：pqfp...@mailtech.cn On 8/15/2012 8:23 PM, pqf wrote: But since someone said remove this sleep(), the server work fine without bottleneck(Maybe he didn't notise the warm up issue?), so I thought remove the sleep() is a good idea. But reduce the time of sleep() is fine to me too. Any other idea? Can we introduce a blocking call on 'pipe ready' based on the child spawn being ready to accept data? The equivalent of a ping-test?
回复: Re: Re: mod_fcgid concurrency bottleneck, issue#53693
How about this: 1. procmgr_post_spawn_cmd() now return a status code from PM, so process handler now know the spawn request is denyed or not. 2. if a new process is created, no sleep is needed. 3. if no process is created, sleep a while 2012-08-16 pqf 发件人：Lazy 发送时间：2012-08-16 16:47 主题：Re: Re: mod_fcgid concurrency bottleneck, issue#53693 收件人：devdev@httpd.apache.org 抄送： 2012/8/16 pqf p...@mailtech.cn: Hi, Michal My solution do add availability to each class, which is the procmgr_post_spawn_cmd() call in each loop do. The sleep() call is intrudused for a stress test without warm up time, in this case, mod_fcgid will create more processes than a slow start one(each process handler can't apply a free slot on the very begining, so send a request to process manager to create one, it's easy to reach the max # of process limit while httpd startup, but the idle process will be killed later), the sleep() call is a little like a server side warm up delay. But since someone said remove this sleep(), the server work fine without bottleneck(Maybe he didn't notise the warm up issue?), so I thought remove the sleep() is a good idea. But reduce the time of sleep() is fine to me too. I was referring to the case where all processes are busy, without sleep(), handle_request() wil quickly send spawn requsts, whith will be denyed by process menager, with sleep() handle_request() will always wait quite a long time, occupying slots -- Michal Grzedzicki
Re: mod_fcgid concurrency bottleneck, issue#53693
Hi, all
I prefer the following solution, can anyone review it?
procmgr_post_spawn_cmd() will be blocked until process manager create a new
fcgid process, the worst case is someone else take the new created process
before I do, and I have to post another spawn command to PM again. The extreme
case is loop FCGID_APPLY_TRY_COUNT but get no process slot.
Index: fcgid_bridge.c
===
--- fcgid_bridge.c (revision 1373226)
+++ fcgid_bridge.c (working copy)
@@ -30,7 +30,7 @@
#include fcgid_spawn_ctl.h
#include fcgid_protocol.h
#include fcgid_bucket.h
-#define FCGID_APPLY_TRY_COUNT 2
+#define FCGID_APPLY_TRY_COUNT 4
#define FCGID_REQUEST_COUNT 32
#define FCGID_BRIGADE_CLEAN_STEP 32
@@ -447,19 +447,13 @@
if (bucket_ctx-procnode)
break;
-/* Avoid sleeping the very first time through if there are no
- busy processes; the problem is just that we haven't spawned
- anything yet, so waiting is pointless */
-if (i 0 || j 0 || count_busy_processes(r, fcgi_request)) {
-apr_sleep(apr_time_from_sec(1));
-
-bucket_ctx-procnode = apply_free_procnode(r, fcgi_request);
-if (bucket_ctx-procnode)
-break;
-}
-
/* Send a spawn request if I can't get a process slot */
procmgr_post_spawn_cmd(fcgi_request, r);
+
+/* Try again */
+bucket_ctx-procnode = apply_free_procnode(r, fcgi_request);
+if (bucket_ctx-procnode)
+break;
}
/* Connect to the fastcgi server */
2012-08-15
pqf
发件人：Mike M
发送时间：2012-08-15 04:29
主题：mod_fcgid concurrency bottleneck, issue#53693
收件人：devdev@httpd.apache.org
抄送：
Ahoy!
With mod_fcgid I've observed a performance bottleneck in which concurrent
requests to a virtualhost where the number of concurrent requests exceed
the number of available fcgid-spawned processes result in a significant
delay in responding to requests.
Details of this situation, how to reproduce, various scenarios tried, etc
are detailed in the issue submission [1].
In file modules/fcgid/fcgid_bridge.c, there is this section of code:
if (i 0 || j 0 || count_busy_processes(r, fcgi_request)) {
apr_sleep(apr_time_from_sec(1));
If I change the sleep time from 1 second to 0 seconds (or, comment out
this section of code entirely), the bottleneck goes away. It seems like
the more appropriate action here would be to turn the sleep time into a
configurable value, with the current 1s value as the default.
I presume this code is meant to be a way to help defer spawn requests so
that a server is not over-whelmed with spin-up related I/O.
My questions are:
- Is this intended to be a throttling mechanism and if so, is there a more
efficient way to handle this throttling?
- If I outright reduce that sleep delay to 0 (or comment out this code),
what potential or expected problems am I introducing to mod_fcgid?
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=53693
---
Mike M
You can't learn in school what the world is going to do next year.
Re: Re: mod_fcgid concurrency bottleneck, issue#53693
Hi, Michal
My solution do add availability to each class, which is the
procmgr_post_spawn_cmd() call in each loop do.
The sleep() call is intrudused for a stress test without warm up time, in this
case, mod_fcgid will create more processes than a slow start one(each process
handler can't apply a free slot on the very begining, so send a request to
process manager to create one, it's easy to reach the max # of process limit
while httpd startup, but the idle process will be killed later), the sleep()
call is a little like a server side warm up delay.
But since someone said remove this sleep(), the server work fine without
bottleneck(Maybe he didn't notise the warm up issue?), so I thought remove the
sleep() is a good idea. But reduce the time of sleep() is fine to me too.
Any other idea?
Regards,
Ryan Pan
2012-08-16
pqf
发件人：Lazy
发送时间：2012-08-15 21:48
主题：Re: mod_fcgid concurrency bottleneck, issue#53693
收件人：devdev@httpd.apache.org
抄送：
2012/8/15 pqf p...@mailtech.cn:
Hi, all
I prefer the following solution, can anyone review it?
procmgr_post_spawn_cmd() will be blocked until process manager create a new
fcgid process, the worst case is someone else take the new created process
before I do, and I have to post another spawn command to PM again. The
extreme case is loop FCGID_APPLY_TRY_COUNT but get no process slot.
Index: fcgid_bridge.c
===
--- fcgid_bridge.c (revision 1373226)
+++ fcgid_bridge.c (working copy)
@@ -30,7 +30,7 @@
#include fcgid_spawn_ctl.h
#include fcgid_protocol.h
#include fcgid_bucket.h
-#define FCGID_APPLY_TRY_COUNT 2
+#define FCGID_APPLY_TRY_COUNT 4
#define FCGID_REQUEST_COUNT 32
#define FCGID_BRIGADE_CLEAN_STEP 32
@@ -447,19 +447,13 @@
if (bucket_ctx-procnode)
break;
-/* Avoid sleeping the very first time through if there are no
- busy processes; the problem is just that we haven't spawned
- anything yet, so waiting is pointless */
-if (i 0 || j 0 || count_busy_processes(r, fcgi_request)) {
-apr_sleep(apr_time_from_sec(1));
-
-bucket_ctx-procnode = apply_free_procnode(r,
fcgi_request);
-if (bucket_ctx-procnode)
-break;
-}
-
/* Send a spawn request if I can't get a process slot */
procmgr_post_spawn_cmd(fcgi_request, r);
+
+/* Try again */
+bucket_ctx-procnode = apply_free_procnode(r, fcgi_request);
+if (bucket_ctx-procnode)
+break;
}
/* Connect to the fastcgi server */
if You get rid of sleep apache will not wait for free process if all
of them are busy, this will lead to 503 errors
currently mod_fcgid waits FCGID_APPLY_TRY_COUNT * FCGID_REQUEST_COUNT
* 1 second and this is usually 64 seconds, this means if You have an
overloaded vhost with low FcgidMaxProcessesPerClass it can bring whole
server down, each thread waits 64 seconds so it doesn't take long
before all threads are occupied.
In my setup we lowerd the wait time and FCGID_REQUEST_COUNT to lower
the impact of overloaded class but I think
the best solution will be to add availability to each class. Total
wait time will be related to it (by changing sleep time, and
FCGID_APPLY_TRY_COUNT). If request is unsuccessful availability will
be halved so next time the wait time will be shorter. This way
congested class will get 0% availability, and new connections will
instantly get 503 it there are no free slots. A successful wait will
increase availability.
Regards,
Michal Grzedzicki
回复: mod_fcgid concurrency bottleneck, issue#53693
Hi， Mike
It's really a problem...I will take a look and find a solution for it
2012-08-15
pqf
发件人：Mike M
发送时间：2012-08-15 04:29
主题：mod_fcgid concurrency bottleneck, issue#53693
收件人：devdev@httpd.apache.org
抄送：
Ahoy!
With mod_fcgid I've observed a performance bottleneck in which concurrent
requests to a virtualhost where the number of concurrent requests exceed
the number of available fcgid-spawned processes result in a significant
delay in responding to requests.
Details of this situation, how to reproduce, various scenarios tried, etc
are detailed in the issue submission [1].
In file modules/fcgid/fcgid_bridge.c, there is this section of code:
if (i 0 || j 0 || count_busy_processes(r, fcgi_request)) {
apr_sleep(apr_time_from_sec(1));
If I change the sleep time from 1 second to 0 seconds (or, comment out
this section of code entirely), the bottleneck goes away. It seems like
the more appropriate action here would be to turn the sleep time into a
configurable value, with the current 1s value as the default.
I presume this code is meant to be a way to help defer spawn requests so
that a server is not over-whelmed with spin-up related I/O.
My questions are:
- Is this intended to be a throttling mechanism and if so, is there a more
efficient way to handle this throttling?
- If I outright reduce that sleep delay to 0 (or comment out this code),
what potential or expected problems am I introducing to mod_fcgid?
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=53693
---
Mike M
You can't learn in school what the world is going to do next year.
Re: Re: mod_fcgid can kill all the services on the server via kill -15 -1
Hi, guys
Here is the new patch, anyone review it? I will commmit it if no one respond :)
Index: fcgid_proc_unix.c
===
--- fcgid_proc_unix.c (revision 1099314)
+++ fcgid_proc_unix.c (working copy)
@@ -402,6 +402,7 @@
procnode-proc_id = tmpproc;
if (rv != APR_SUCCESS) {
+memset(procnode-proc_id, 0, sizeof(procnode-proc_id));
ap_log_error(APLOG_MARK, APLOG_ERR, rv, procinfo-main_server,
mod_fcgid: can't run %s, wargv[0]);
}
@@ -414,6 +415,11 @@
/* su as root before sending signal, for suEXEC */
apr_status_t rv;
+if (procnode-proc_id.pid == 0) {
+/* procnode-proc_id.pid be 0 while fcgid_create_privileged_process()
fail */
+return APR_SUCCESS;
+}
+
if (ap_unixd_config.suexec_enabled seteuid(0) != 0) {
/* can't gain privileges to send signal (should not occur); do NOT
@@ -461,6 +467,7 @@
/* Destroy pool */
apr_pool_destroy(procnode-proc_pool);
procnode-proc_pool = NULL;
+memset(procnode-proc_id, 0, sizeof(procnode-proc_id));
return APR_CHILD_DONE;
}
2011-05-04
Ryan
发件人: pqfp...@mailtech.cn
发送时间: 2011-04-18 09:58
主 题: Re: mod_fcgid can kill all the services on the server via kill -15 -1
收件人: devdev@httpd.apache.org
Hi, all
Another question, does proc_wait_process() should update procnode-proc_id to 0
too? or else mod_fcgid may send a signal to another irrelevant process while
apache is shutting down? I don't follow up mod_fcgid for a while, I just took a
glance, maybe it's updated somewhere else?
By the way, procnode-proc_id is set to 0 while apache startup, so why not
update procnode-proc_id to 0 while fcgid_create_privileged_process() is fail?
And then check magic number 0 rather than both -1 and 0, in both
proc_kill_gracefully() and proc_kill_force().
Cheers.
Ryan
Hello,
There is a very interesting, and quite a rare bug in mod_fcgid. It is easy to
reproduce if you can cause fork to fail (which can be done with CloudLinux --
if anyone wants to replicate it).
Here is how it works:
mod_fcgid tries to spawn a new process (proc_spawn_process in
fcgid_proc_unix.c), but fork returns -1.
More exactly fcgid_create_privileged_process function call returns error, and
fills in tmpproc.pid with -1 tmpproc is assiged to procnode-proc_id).
Now, if at the same time service httpd restart is executed, function
kill_all_subprocess in fcgid_pm_main.c will execute, and it will try to go
through all procnodes, sending SIGTERM via proc_kill_gracefully, (and then
SIGKILL via proc_kill_force) to procnode-proc_id.pid
Yet, one procnode will be pointing to procnode-proc_id.pid, causing kill -15
-1 (kill all).
The end results all services on the server failing, including SSH, apache,
syslogd, etc..
I guess the problem is really rare for most people. Also it is quite hard to
diagnose, as it is completely not clear where the signal came from, and it took
us some time to correlate them with apache restarts.. Yet due to our OS being
used by shared hosts (where httpd restart is common thing), and our ability to
limit memory available to processes on per virtual host bases (which causes
fork to fail once that virtual host reaches memory limit), we see the issue
quite often.
The solution is quite simple (not sure if it is the best / right solution), in
file: fcgid_proc_unix.c, in methods proc_kill_gracefully, line:
rv = apr_proc_kill((procnode-proc_id), SIGTERM);
should be changed to:
if (procnode-proc_id.pid != -1) {
rv = apr_proc_kill((procnode-proc_id), SIGTERM);
} else {
rv = APR_SUCCESS;
}
Similarly in proc_kill_force
rv = apr_proc_kill((procnode-proc_id), SIGKILL);
should be changed to:
if (procnode-proc_id.pid != -1) {
rv = apr_proc_kill((procnode-proc_id), SIGKILL);
} else {
rv = APR_SUCCESS;
}
Regards,
Igor Seletskiy
CEO @ Cloud Linux Inc
Re: mod_fcgid can kill all the services on the server via kill -15 -1
Hi, all
Another question, does proc_wait_process() should update procnode-proc_id to 0
too? or else mod_fcgid may send a signal to another irrelevant process while
apache is shutting down? I don't follow up mod_fcgid for a while, I just took a
glance, maybe it's updated somewhere else?
By the way, procnode-proc_id is set to 0 while apache startup, so why not
update procnode-proc_id to 0 while fcgid_create_privileged_process() is fail?
And then check magic number 0 rather than both -1 and 0, in both
proc_kill_gracefully() and proc_kill_force().
Cheers.
Ryan
Hello,
There is a very interesting, and quite a rare bug in mod_fcgid. It is easy to
reproduce if you can cause fork to fail (which can be done with CloudLinux --
if anyone wants to replicate it).
Here is how it works:
mod_fcgid tries to spawn a new process (proc_spawn_process in
fcgid_proc_unix.c), but fork returns -1.
More exactly fcgid_create_privileged_process function call returns error, and
fills in tmpproc.pid with -1 tmpproc is assiged to procnode-proc_id).
Now, if at the same time service httpd restart is executed, function
kill_all_subprocess in fcgid_pm_main.c will execute, and it will try to go
through all procnodes, sending SIGTERM via proc_kill_gracefully, (and then
SIGKILL via proc_kill_force) to procnode-proc_id.pid
Yet, one procnode will be pointing to procnode-proc_id.pid, causing kill -15
-1 (kill all).
The end results all services on the server failing, including SSH, apache,
syslogd, etc..
I guess the problem is really rare for most people. Also it is quite hard to
diagnose, as it is completely not clear where the signal came from, and it took
us some time to correlate them with apache restarts.. Yet due to our OS being
used by shared hosts (where httpd restart is common thing), and our ability to
limit memory available to processes on per virtual host bases (which causes
fork to fail once that virtual host reaches memory limit), we see the issue
quite often.
The solution is quite simple (not sure if it is the best / right solution), in
file: fcgid_proc_unix.c, in methods proc_kill_gracefully, line:
rv = apr_proc_kill((procnode-proc_id), SIGTERM);
should be changed to:
if (procnode-proc_id.pid != -1) {
rv = apr_proc_kill((procnode-proc_id), SIGTERM);
} else {
rv = APR_SUCCESS;
}
Similarly in proc_kill_force
rv = apr_proc_kill((procnode-proc_id), SIGKILL);
should be changed to:
if (procnode-proc_id.pid != -1) {
rv = apr_proc_kill((procnode-proc_id), SIGKILL);
} else {
rv = APR_SUCCESS;
}
Regards,
Igor Seletskiy
CEO @ Cloud Linux Inc
Re: [mod_fcgid PATCH] catch errors from setuid()/seteuid()
Hi, Jeff Your concerns are right, +1 for your patch :) Thanks -- From: Jeff Trawick traw...@gmail.com Sent: Thursday, January 21, 2010 9:23 PM To: dev@httpd.apache.org Subject: Re: [mod_fcgid PATCH] catch errors from setuid()/seteuid() On Wed, Jan 20, 2010 at 8:19 PM, pqf p...@mailtech.cn wrote: I man seteuid in my Linux box, there are two types of errors: ERRORS The seteuid() function shall fail if: EINVAL The value of the uid argument is invalid and is not supported by the implementation. EPERM The process does not have appropriate privileges and uid does not match the real group ID or the saved set-group- ID. If directly pass 0 in setuid(), EINVAL may not happend If this process is seteuid from root, EPERM may not happend so, I think the check is just a textbook logic check? yes, until somebody changes code or some other bug results in this being called in a different environment just call _exit(1) if it fail? two concerns with that minimal change: 1. seteuid() works once then fails n times now (at least on Solaris), so some extra logic is needed 2. even if these calls never fail, the presence of the exit() without a log message may cause somebody to lose a lot of time investigating a mysterious disappearance of the new process --/-- I'll punt on this until after 2.3.5 since I'd like to spend the time to watch it work on another platform or two. (suexec is not something I use more than once every ~3 years, so it is worth setting up in multiple environments.)
Re: [mod_fcgid PATCH] catch errors from setuid()/seteuid()
I man seteuid in my Linux box, there are two types of errors: ERRORS The seteuid() function shall fail if: EINVAL The value of the uid argument is invalid and is not supported by the implementation. EPERM The process does not have appropriate privileges and uid does not match the real group ID or the saved set-group- ID. If directly pass 0 in setuid(), EINVAL may not happend If this process is seteuid from root, EPERM may not happend so, I think the check is just a textbook logic check? just call _exit(1) if it fail? -- From: Jeff Trawick traw...@gmail.com Sent: Thursday, January 21, 2010 5:38 AM To: dev@httpd.apache.org Subject: [mod_fcgid PATCH] catch errors from setuid()/seteuid() During the last hackathon, Paul was kind enough to run the clang/llvm static analysis on mod_fcgid (http://zeus.kimaker.com/~chip/fcgid-scan/). That pointed out these setuid()/seteuid() calls that aren't checked prior to running a child. The error checking itself is simple enough, but there's an ugly aspect of the implementation that results in trying to switch effective/real uids multiple times that I worked around. (See the FIXME text in the patch. I'm not aware of a simple solution, especially one simple enough to get into 2.3.5) The seteuid() call would otherwise fail on subsequent invocations for the same child. IIRC Joe thought that the seteuid() wasn't needed at all, but the setuid() fails without it on Solaris. Concerns? Is there some reason that testing on Linux and Solaris wouldn't be sufficient?
Re: svn commit: r888840 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_bridge.c fcgid_pm_main.c
Hi, I google a bit, it seems not much user encountered a busy timeout issue, and the old protocol should work in most cases, so I think it's no need to note in CHANGES? Next time I will separate commit logic changes and style changes :) Thanks -- From: Jeff Trawick traw...@gmail.com Sent: Tuesday, December 15, 2009 10:49 PM To: dev@httpd.apache.org Subject: Re: svn commit: r40 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_bridge.c fcgid_pm_main.c On Wed, Dec 9, 2009 at 10:36 AM, p...@apache.org wrote: Author: pqf Date: Wed Dec 9 15:36:46 2009 New Revision: 40 URL: http://svn.apache.org/viewvc?rev=40view=rev Log: Bug fix, Bug 47873 - unreliable coordination between daemon and request thread for BusyTimeout processing cool If you think users may have encountered a problem symptom from the original protocol, we can note it in CHANGES. I'm really not sure. Perhaps it would require the user to change some scan interval to a very large value. (When configured, scan intervals are typically set to a smaller value.) BTW, it is quite a challenge to review logic changes which contain unrelated style changes, so we don't do that. Use a separate commit with only style changes.
Re: [mod_fcgid] Feedback / Suggestions
-- From: Jeff Trawick traw...@gmail.com Sent: Tuesday, November 24, 2009 11:24 PM To: dev@httpd.apache.org Subject: Re: [mod_fcgid] Feedback / Suggestions On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank ef-li...@email.de wrote: Hi dev, I'd like to suggest to following changes / offer feedback for mod_fcgid: my 2cents below (1) mod_fcgid should be capable of specifying an external FCGI server. (2) In conjunction with (1), mod_fcgid should be able to select the backend server based on request data. I'd much rather see effort put into mod_proxy_fcgi to support this use case. I wish somebody, perhaps myself, had time to work on it. It doesn't seem that hard a task. In the interim, is mod_fastcgi really that bad? (3) mod_fcgid currently buffers the complete input from the client (occasionaly in a temp-file if the request is large) before it passes it through to a FCGI backend. Could this be made configurable in a way like File|Memory|Pipeline? (file - as is | memory - buffer in memory always | pipeline - directly pass the read data to the backend) This will definitely be resolved ;) Pipeline is a little complex. FastCGI process would write during reading. so mod_fcgid should check both read and write on the socket, and read/write while the socket is readable/writeable. But is do-able :) Any one interesting? Or otherwise, can someone explain the details to me why it is as it is? Especially in terms of not pipeling data directly (maybe after a little buffering to build proper FCGI packets)? The comment in fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this keep the server in processing too long? Processing takes its time either way, I'd assume. Looking forward to enlightment. :) I can only guess that the problem at hand when this was implemented was that some backend application processes were so expensive that that they couldn't be tied up until all data had been read from slow clients. Yes, Jeff is right :) (4) Would it make sense to use the FCGI feature to multiplex several requests over a single connection? Does any backend support this feature anyway? no idea here In this case, one httpd thread(process) will have to bind to one FastCGI process. I don't think connect() to a local pipe/unix domain socket is the bottle-neck, so let it be? When thinking of an external FCGI backend with a socket connection and very high Requests/s, this could keep open connections and used/available ports much lower. connect() may be bottle-neck if using external FCGI backend. But now mod_fcgid don't support external FCGI backend yet.
Re: svn commit: r835406 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_pm_main.c fcgid_proc_unix.c fcgid_proc_win.c fcgid_proctbl.h mod_fcgid.c
Hi, Jeff Thank you for the code style reference, I will follow this style next time :) Actually there are many space for extra info(like vhost), and we can just put this in the share memeory and output it through /server_status, but another issue is system security, I think we should not provide too much internal info to client(file full path, user id etc). So I now just output the info that nobody can get through ps -ef. But if it's no harm, please feel free to add more info to the share memory. Thanks -- From: Jeff Trawick traw...@gmail.com Sent: Friday, November 13, 2009 5:08 AM To: dev@httpd.apache.org Subject: Re: svn commit: r835406 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_pm_main.c fcgid_proc_unix.c fcgid_proc_win.c fcgid_proctbl.h mod_fcgid.c On Thu, Nov 12, 2009 at 10:05 AM, p...@apache.org wrote: Author: pqf Date: Thu Nov 12 15:05:08 2009 New Revision: 835406 URL: http://svn.apache.org/viewvc?rev=835406view=rev Log: Add fcgid extension to mod_status Hi Ryan, This looks extremely useful. Hopefully I can look at it more over the next few days. At first glance I think the process heading needs more information, such as the vhost or other attributes that distinguish the table from other tables for the same executable file, since otherwise it may be unexpected to see multiple tables for the same program, each with its own set of processes. For anyone that wants a quick look at the information, I've uploaded a sample page to http://people.apache.org/~trawick/mod_fcgid_status.html Thanks! BTW, I made some code formatting changes in r835540 to bring the new mod_status code closer to httpd project style (guidelines are at http://httpd.apache.org/dev/styleguide.html, examples for issues not covered there are throughout httpd).
Re: Re: mod_fcgid: add mod_status support?
Jeff Trawick wrote: 2009/11/9 pqf p...@mailtech.cn: Hi, all I am new to this community, I am think to add mod_status support to mod_fcgid, which provide more internal information to administrators. Is it a good idea? I am working on it now, but if someone think it's not a good idea, please let me know. Sure. I'd like to see a view of processes and perhaps scores from mod_status. I'd like to see this become an extensible mechansim. It was on the topic list last week until SSL issues got the better of us. I'll post thoughts in the coming week, Aaron, DougM and I have all done some pondering on this subject that would make things cleaner for all. But in terms of 2.0/2.2 legacy fcgid support for scoreboard, Sander's comments are right on. I just finished a version which scan share memory and print out FastCGI process status. just like mod_ssl does. But will the mechansim be changed to an extensible one in the future? external modules like mod_ssl should use another mechansim to do this? Look forward for further discussion in the next week :)
Re: mod_fcgid: different instances of the same program
Hi, Yes, mod_fcgid search process node base on file's inode and deviceid(plus share_group_id, virtual host name). The goal is to create as less process as possible. Some administrators like the idea that all virtual hosts share one PHP process pool. (But some other don't, they can turn that off anyway. This is what share_group_id for in the first place, administrator can make who share who's process pool) But the document should provide more detail about it, I missed that part in my old documents. I am sure some native English speekers will modify the documents soon. Thanks From: Danny Sadinoff Sent: Tuesday, November 10, 2009 6:16 AM To: dev@httpd.apache.org Subject: mod_fcgid: different instances of the same program Here are two details of mod_fcgid process management that I've just learned after a long debug session and squinting at the mod_fcgid code. 1) symlinks you. It seems that mod_fcgid identifies fcgid programs by inode and device, not by filename. So two fcgid programs invoked by the webserver along different paths will be counted as the same if the two paths are hardlinks or softlinks to each other. 2) Virtual hosts The above item holds true even across virtual hosts. So while it's possible to adjust the FcgidInitialEnv items on a per-vhost basis, this is a recipe for disaster if two vhosts point at the same fcgi executable, because the resulting processes with potentially different Environments will be inserted into the same pool. Once that occurs, we may expect that a server spawned with config defined in vhost A will be parcelled out to vhost B. The Apache httpd 2.3 docs do not address the symlink issue at all, and the virtual host issue only indirectly. http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html I'd appreciate it if someone could confirm or deny the above. If I'm right, can we add it to the docs? None of it seems obvious to me. Apologies in advance if this is the sort of thing that belongs on the dev list. I'm happy to throw together a doc patch. Thanks in advance P.S. having a lot of trouble getting this message posted to the list. Not sure what's up with that. -- Danny Sadinoff da...@sadinoff.com
mod_fcgid: add mod_status support?
Hi, all I am new to this community, I am think to add mod_status support to mod_fcgid, which provide more internal information to administrators. Is it a good idea? I am working on it now, but if someone think it's not a good idea, please let me know. BTW, I did test spin lock on share memory process table, the result is, hit per second is not as good as current solution with global mutex, so I give up :) Thanks
[mod_fcgid] how about spin lock on share memory
Hi, all I am Ryan Pan, who wrote the first version of mod_fcgid. While I uesd mod_fastcgi(not mod_fcgid), one issue that bother me is: while a fastcgi process(created by mod_fastcgi's process manager process)in a dead loop, no one is respond to kick it out. So from time to time, some fastcgi processes would eat up the system cpu resource. So while I wrote mod_fcgid, I create a block of share memory to store the fastcgi process pipe path and pid, then httpd can search this share memory to get the an idle fastcgi process, and once the communication timout(which usually mean the fastcgi process deadly running), httpd will kick out this corrupt process. However there is a new problem now, every time httpd search this share memory, it will have to get a global mutex, which is a combination of process lock an thread lock, is it(a mutex lock for search a free node in a node list) too heavy? Maybe spin lock on share memory is a good idea in this case? But spin lock is system dependented, and apr library doesn't have this interface. I thought about this idea since I wrote mod_fcgid, but I am not sure whether it is a good idea, so any advice from you guys will be highly appreciated. Thanks
Re: Transfer Patch Rights for mod_fcgid ASF
Hi, From the thread I get here: http://mail-archives.apache.org/mod_mbox/httpd-dev/200611.mbox/%3cdb4ef19e-148b-41a3-a27c-354b0d640...@gbiv.com%3e The procedure is: (1) make this thread a formal vote and, assuming that passes (2) fill out the incubation paperwork at http://incubator.apache.org/ip-clearance/index.html and then (3) import the code under httpd/mod_wombat Should someone start a vote or further discussion is needed? Thanks - Original Message - From: William A. Rowe, Jr. wr...@rowe-clan.net To: dev@httpd.apache.org Sent: Sunday, January 11, 2009 2:15 AM Subject: Re: Transfer Patch Rights for mod_fcgid ASF Chris Darroch wrote: pqf wrote: Now both authors have subscribe this maillist and claimed to transfer all rights to the patch to the Apache Software Foundation, is it OK? Can we move forward now? Excellent question -- it would seem we have resolved the outstanding issues here, so what is the next step? If we're looking to fast-track adoption, do we submit something to the httpd PMC, the Incubator, or some other body? Take a vote? Any guidance appreciated! Go ahead and review the threads under; http://www.google.com/search?q=site%3Ahttp%3A%2F%2Fmail-archives.apache.org%2Fmod_mbox%2Fhttpd-dev+%22ip+clearance%22+mod_wombatie=utf-8oe=utf-8aq=trls=org.mozilla:en-US:officialclient=firefox-a which is a pretty recent example.
Re: Transfer Patch Rights for mod_fcgid ASF
Hi, Thank you Tim Jensen :) These are the Major patchs which I thought I should ask the patch authors: Major patches version 1.10 ( Jul 3rd 2006 ) 1. Use poll() instead of select() in UNIX. It becomes problematic on apache2 with large number of logfiles. Apache2 calls poll() (when OS supports it), and in that case it doesn't need to be recompiled with larger FD_SETSIZE. select() is still limited to FD_SETSIZE.(Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) 2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) Version2.2 (Jul 31st 2007) 3. Support configuration TimeScore Thank Tim Jensen for the patch. (This is a patch from sourceforge.net: https://sourceforge.net/tracker/download.php?group_id=174879atid=870993file_id=218023aid=1670268, author is https://sourceforge.net/users/timjensen66/) Now both authors have subscribe this maillist and claimed to transfer all rights to the patch to the Apache Software Foundation, is it OK? Can we move forward now? - Original Message - From: Tim Jensen t...@rtsports.com To: dev@httpd.apache.org Sent: Friday, January 09, 2009 2:05 AM Subject: Transfer Patch Rights for mod_fcgid ASF Hello, I am new to the list. Love apache. It has served me well for over a decade. Keep up the great work. I had previously contributed a patch to the mod_fcgid module whose ownership is being transfered to ASF. As author of my minor little patch to mod_fcgid I gladly transfer all rights to the patch to the Apache Software Foundation. ASF is free so use, modify, delete, or distrubute the patch and any derivative works as they see fit. Tim Jensen tim at rtsports dot com
Re: Re: mod_fcgid license questions
Hi, guys Good news is I track down another author now. We are talking about the license questions now, so far so good :) Thanks -原始邮件- 发件人: Chris Darroch chr...@pearsoncmg.com 发送时间: 2009年1月1日 星期四 收件人: dev@httpd.apache.org 抄送: 主题: Re: mod_fcgid license questions Hi -- On 31 Dec 2008, at 05:48, Roy T. Fielding wrote: Foes anyone have a sense of whether these would indeed require a CLA and SGA? They look like simple repairs to me. More importantly, if he thinks they are simple repairs and he is happy to see them Apache Licensed, then there is no need for a CLA or software grant. +1. This is in the same ballpark as third-party patches we routinely accept, e.g. from reports in bugzilla. OK, that sounds reasonable. I think we're just waiting to hear from one other person, then. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid license questions
Hi, guys
Thanks Chris first :)
Please take a look at the attachments, I got it from my mail archive. The
errorlog patch is a minor patch. the poll patch change not much lines of code,
but it did come with original idea.If Piotr Gackiewicz think his job is
simple repairs, I think these patchs can be put to minor patch group too.
Thanks
- Original Message -
From: Chris Darroch chr...@pearsoncmg.com
To: dev@httpd.apache.org
Sent: Wednesday, December 31, 2008 1:31 PM
Subject: Re: mod_fcgid license questions
pqf wrote:
version 1.10 ( Jul 3rd 2006 )
1. Use poll() instead of select() in UNIX. It becomes problematic on
apache2 with large number of logfiles. Apache2 calls poll()
(when OS supports it), and in that case it doesn't need to be recompiled
with larger FD_SETSIZE. select() is still limited to FD_SETSIZE.
(Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is
generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
Ryan has been in touch with Piotr Gackiewicz independently and Piotr
asks if we can confirm that a CLA and SGA are necessary, as he considers
his contribution to have been just simple repairs (his term).
From looking over the CVS repository at
http://mod-fcgid.cvs.sourceforge.net/viewvc/mod-fcgid/mod_fcgid/
it would appear to me that these patches amount to the following.
Foes anyone have a sense of whether these would indeed require
a CLA and SGA?
Chris.
=
--- fcgid_bridge.c2006/01/22 14:16:231.25
+++ fcgid_bridge.c2006/05/13 23:45:441.26
@@ -256,8 +256,11 @@
}
bucket_ctx = apr_pcalloc(request_pool, sizeof(*bucket_ctx));
-if (!bucket_ctx)
+if (!bucket_ctx) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: apr_calloc of %d bytes failed in
handle_request function, sizeof(*bucket_ctx));
return HTTP_INTERNAL_SERVER_ERROR;
+}
bucket_ctx-ipc.connect_timeout = g_connect_timeout;
bucket_ctx-ipc.communation_timeout = g_comm_timeout;
bucket_ctx-ipc.request = r;
@@ -315,7 +318,7 @@
/* Now I get a connected ipc handle */
if (!bucket_ctx-procnode) {
-ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, r-server,
mod_fcgid: can't apply process slot for %s, argv0);
return HTTP_SERVICE_UNAVAILABLE;
}
@@ -326,7 +329,7 @@
if ((rv =
proc_write_ipc(main_server, bucket_ctx-ipc,
output_brigade)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv, r-server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
mod_fcgid: write data to fastcgi server error);
bucket_ctx-has_error = 1;
return HTTP_INTERNAL_SERVER_ERROR;
@@ -335,8 +338,11 @@
/* Create brigade */
brigade_stdout =
apr_brigade_create(request_pool, r-connection-bucket_alloc);
-if (!brigade_stdout)
+if (!brigade_stdout) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: apr_brigade_create failed in handle_request
function);
return HTTP_INTERNAL_SERVER_ERROR;
+}
APR_BRIGADE_INSERT_TAIL(brigade_stdout,
ap_bucket_fcgid_header_create(r-connection-
bucket_alloc,
@@ -346,7 +352,11 @@
/* Check the script header first. If got error, return immediately */
if ((cond_status = ap_scan_script_header_err_core
(r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout)) = 400)
+{
+ap_log_error(APLOG_MARK, APLOG_INFO, rv, r-server,
+mod_fcgid: ap_scan_script_header_err_core failed in
handle_request function: %d, cond_status);
return cond_status;
+}
/* Check redirect */
location = apr_table_get(r-headers_out, Location);
@@ -377,6 +387,9 @@
if ((rv =
ap_pass_brigade(r-output_filters,
brigade_stdout)) != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: ap_pass_brigade failed in handle_request
function);
+
return HTTP_INTERNAL_SERVER_ERROR;
}
@@ -437,7 +450,7 @@
AP_MODE_READBYTES,
APR_BLOCK_READ,
HUGE_STRING_LEN)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv,
main_server,
mod_fcgid: can't get data from http client);
apr_brigade_destroy(output_brigade);
--- arch/unix/fcgid_proc_unix.c2006
Re: mod_fcgid license questions
Hi, all
Sorry for the delay, I have track down all patches base on my ChangeLog( I
keep my mail archive), so here is my brief:
the Inside job
version 0.76 ( Jul 6th 2004 )
1. Code fix. Replace the depreciated BRIGADE_FOREACH macro, which compile
against httpd 2.1-Dev.
(Patch by Paul Querna(chip at force-elite.com))
Version2.1 ( Feb 15th 2007 )
3. Bug fix. Authoritative flag reversed
Thank Chris Darroch for the patch
---
Minor patches
...Ignore here, I attach a file to show every modification to every ChangeLog
entry. (If anyone think any change is major, please let me know)
Major patches
version 1.10 ( Jul 3rd 2006 )
1. Use poll() instead of select() in UNIX. It becomes problematic on apache2
with large number of logfiles. Apache2 calls poll() (when OS supports it), and
in that case it doesn't need to be recompiled with larger FD_SETSIZE. select()
is still limited to FD_SETSIZE.(Thank Piotr Gackiewicz gacek at intertele.pl
for the patch.)
2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is
generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
Version2.2 (Jul 31st 2007)
3. Support configuration TimeScore
Thank Tim Jensen for the patch.
(This is a patch from sourceforge.net:
https://sourceforge.net/tracker/download.php?group_id=174879atid=870993file_id=218023aid=1670268,
author is https://sourceforge.net/users/timjensen66/)
So, that mean there are other two people are involved.
Thanks
- Original Message -
From: Chris Darroch chr...@pearsoncmg.com
To: dev@httpd.apache.org
Sent: Thursday, December 18, 2008 1:20 PM
Subject: Re: mod_fcgid license questions
William A. Rowe, Jr. wrote:
How many are we talking about (in the significant category)? The
easiest way probably depends on how many people, how easy they are
to contact, etc.
Ryan, do you have a rough sense of this?
From my own review of the ChangeLog, it looks like there are
roughly about 10-12 major contributions by others (two of whom are
httpd committers). There are lots of additional people listed,
but these seem to divide up between minor patch contributions,
thanks for bug reports or for testing a bug fix, or thanks for
suggesting a possible new feature.
Clearly, though, we'll need Ryan to look through and identify
the major contributors.
I'd prefer that we simply sponsor this effort under the httpd PMC here
at our project.
We have to file an IP code clearance through the Incubator, but that's
relatively simple (and a good part is finished already now that the
appropriate paperwork is filed with the secretary).
Does anyone feel that the addition of mod_fcgid should be driven through
the incubator? Speaking first hand, it didn't resolve the shortcomings
of lack of community behind mod_aspdotnet, and didn't really give mod_ftp
the visibility it needed (and attracted once it graduated). So for most
existing modules, I don't think it solves many of the problems we might
or might not face here at httpd.
I really don't know all the options here, but from what you describe,
it sounds like a faster track to get the IP code clearance done would
be ideal, if possible. So, a +1 from me if this is feasible.
Thanks,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
--
version 1.04 ( Dec 2nd 2004 )
1. Bug fix. ap_scan_script_header_err_core can return non OK without errors.
e.g. CGI outputs Last-Modified header and browser request with
If-Mofieided-Since header, ap_scan_script_header_err_core() may returns 302(Not
Modified)
(Thank Tatsuki Sugiura, sugi at nemui.org for the bug fix patch)
--- fcgid_bridge.c.orig 2004-11-11 09:40:17.0 +0900
+++ fcgid_bridge.c 2004-11-11 09:41:30.0 +0900
@@ -217,7 +217,7 @@
server_rec *main_server = r-server;
fcgid_command fcgi_request;
fcgid_bucket_ctx *bucket_ctx;
- int i, stopping;
+ int i, stopping, cond_status;
apr_status_t rv;
apr_bucket_brigade *brigade_stdout;
char sbuf[MAX_STRING_LEN];
@@ -330,11 +330,10 @@
bucket_ctx));
/*APR_BRIGADE_INSERT_TAIL(brigade_stdout,
apr_bucket_flush_create(r-connection-bucket_alloc)); */
- /* Check the script header first */
- if (ap_scan_script_header_err_core
- (r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout) != OK) {
- return HTTP_INTERNAL_SERVER_ERROR;
- }
+ /* Check the script header first. If got error, return immediately */
+ if ((cond_status = ap_scan_script_header_err_core
+ (r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout)) = 400)
+ return cond_status;
/* Check redirect */
location =
Re: mod_fcgid license questions
Hi, all I have signed the two documents( http://www.apache.org/licenses/software-grant.txt and http://www.apache.org/licenses/iclas), and emailed the scan version to secretary at apache.org. So what I should do next is? Should I contact all major contributors and ask for the agreement to this: http://www.apache.org/licenses/software-grant.txt. Or I just identify all the major contributors and wait for next step? Anything I can do please let me know :) Thanks - Original Message - From: William A. Rowe, Jr. wr...@rowe-clan.net To: dev@httpd.apache.org; Ryan pan p...@mailtech.cn Sent: Saturday, December 13, 2008 11:18 AM Subject: Re: mod_fcgid license questions pqf wrote: Hi, guys Nice to meet you :) I hope I can help to clarify the questions. Likewise :) When you wrote mod_fcgid, was there any code which you borrowed from mod_fastcgi? No. I didn't borrow any code from mod_fastcgi. That's good - we are looking at the headers you use and the fcgi package liberal licensing (as opposed to the mod_fastcgi package). Your current intention is for mod_fcgid to be available under the GPL version 2.0, correct? Could you confirm that you wanted the GPL to apply to all the mod_fcgid code? Yes, I confirm I wanted the GPL version 2.0 apply to everything. So to clarify, you don't seem strongly married to any particular license. Is the AL 2.0 acceptable and would you be willing to license it such, or offer a software grant under the terms of the AL 2.0? See http://www.apache.org/licenses/software-grant.txt we would also want to capture a CLA so that you can contribute your own ideas to the new code http://www.apache.org/licenses/#clas Finally, if there are other contributors to the efforts, aside from the obvious simple bug fixes and maintenance, we would need their buy-in as well, and count on you to identify such people that have shaped fcgid. Looking forward to this solution! Bill
Re: mod_fcgid license questions
Hi, guys Nice to meet you :) I hope I can help to clarify the questions. When you wrote mod_fcgid, was there any code which you borrowed from mod_fastcgi? No. I didn't borrow any code from mod_fastcgi. Your current intention is for mod_fcgid to be available under the GPL version 2.0, correct? Could you confirm that you wanted the GPL to apply to all the mod_fcgid code? Yes, I confirm I wanted the GPL version 2.0 apply to everything. Finally, Ryan, would you mind re-stating for the record your interest in the idea of mod_fcgid becoming an Apache project? Actually I didn't care too much about which license I should choose. The reason I chose GPL is that all other license descriptions are in English and are tricky. I didn't want to spend much time on studying those terms so I just followed most of people to choose GPL. I intended to put it as open source so people can share. I don't really care which license it is under. (Thanks Miss Xiaomei for this native translation) I was single when I developed this project, but now I have to spend more time with my family, and I am now actually interesting on LinuxTV things(So I can spend time on something both I and my wife need :). But I would like to see someone else take over my mod_fcgid project and continune to make it better. I get a lot from the others(that why I like open source and share), and I would like to share to the other if I have a chance. It's my pleasure if ASF willing to take it over. Anything I can help please let me know :) Thanks - Original Message - From: Chris Darroch chr...@pearsoncmg.com To: dev@httpd.apache.org Sent: Friday, December 12, 2008 6:15 AM Subject: mod_fcgid license questions Hi -- I believe Pan Qingfeng (潘庆峰), the developer of mod_fcgid, has joined this list for the time being while the possibility of mod_fcgid becoming project in the Apache incubator is discussed. I'll use his English name of Ryan Pan from here on. I asked Ryan to join so that he could answer the couple of questions regarding the origin of the mod_fcgid code and his licensing intentions which have come up so far, and also to thank him publicly for being willing to consider contributing mod_fcgid to the ASF. Ryan, the main question which has come up in the last couple of days seems to be this one: When you wrote mod_fcgid, was there any code which you borrowed from mod_fastcgi? The other questions I had related to the existing license for mod_fcgid: Your current intention is for mod_fcgid to be available under the GPL version 2.0, correct? Could you confirm that you wanted the GPL to apply to all the mod_fcgid code? (I ask because the LICENSE file in mod_fcgid contains the GPL 2.0, however, the .c and .h files don't also include the usual GPL text.) Finally, Ryan, would you mind re-stating for the record your interest in the idea of mod_fcgid becoming an Apache project? I'd like to personally extend my thanks to Ryan for developing mod_fcgid in the first place, for his interest in the idea of contributing it to the ASF, and for being willing to work through the licensing issues that will involve. Many thanks! (I'd also like to thank my colleague Sharon or Xiaomei Ma (笑梅), an excellent developer in her own right, for her help translating some of the communications Ryan and I have already had.) Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
