Re: [PATCH] check_forensic re tweak
- Original Message - > With mod_unique_id installed there's the possibility > of having a - in the forensic id, so here's a minor > patch to ensure check_forensic does the right thing. > > Index: support/check_forensic > === > --- support/check_forensic(revision 1094142) > +++ support/check_forensic(working copy) > @@ -43,8 +43,8 @@ > trap "rm -f -- \"$all\" \"$in\" \"$out\";" 0 1 2 3 13 15 > > cut -f 1 -d '|' $F > $all > -grep + < $all | cut -c2- | sort > $in > -grep -- - < $all | cut -c2- | sort > $out > +grep ^+ < $all | cut -c2- | sort > $in > +grep -- ^- < $all | cut -c2- | sort > $out > > # use -i instead of -I for GNU xargs > join -v 1 $in $out | xargs -I xx egrep "^\\+xx" $F Thanks joe - applied in r1096775 i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/
Re: svn commit: r1096577 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ldap.xml modules/ldap/util_ldap.c modules/ldap/util_ldap_cache.c modules/ldap/util_ldap_cache_mgr.c
On Tue, 26 Apr 2011, Ruediger Pluem wrote:
On 04/25/2011 10:00 PM, s...@apache.org wrote:
Author: sf
Date: Mon Apr 25 20:00:43 2011
New Revision: 1096577
URL: http://svn.apache.org/viewvc?rev=1096577&view=rev
Log:
mod_ldap: Make LDAPSharedCacheSize 0 create a non-shared-memory cache per
process as opposed to disabling caching completely. This allows to use
the non-shared-memory cache as a workaround for the shared memory cache
not being available during graceful restarts
PR: 48958
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/docs/manual/mod/mod_ldap.xml
httpd/httpd/trunk/modules/ldap/util_ldap.c
httpd/httpd/trunk/modules/ldap/util_ldap_cache.c
httpd/httpd/trunk/modules/ldap/util_ldap_cache_mgr.c
Modified: httpd/httpd/trunk/modules/ldap/util_ldap_cache_mgr.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ldap/util_ldap_cache_mgr.c?rev=1096577&r1=1096576&r2=1096577&view=diff
==
--- httpd/httpd/trunk/modules/ldap/util_ldap_cache_mgr.c (original)
+++ httpd/httpd/trunk/modules/ldap/util_ldap_cache_mgr.c Mon Apr 25 20:00:43
2011
@@ -363,6 +366,14 @@ util_ald_cache_t *util_ald_create_cache(
cache->nodes = (util_cache_node_t **)util_ald_alloc(cache, cache->size *
sizeof(util_cache_node_t *));
if (!cache->nodes) {
util_ald_free(cache, cache);
+#if APR_HAS_SHARED_MEMORY
+if (!st->cache_rmm)
+free(cache);
+else
+apr_rmm_free(st->cache_rmm, block);
+#else
+free(cache);
Do we ever alloc cache #if !APR_HAS_SHARED_MEMORY?
Yes, it's simply allocated with calloc. But my commit was wrong anyway,
because the util_ald_free(cache, cache) in the line above already frees
cache. Thanks for the review.
Cheers,
Stefan
Re: mod_fcgid can kill all the services on the server via kill -15 -1
Ryan,
I like this approach. Do you want us to prepare a patch against latest
version?
Also, we never committed to apache project. Would it be enough if we post a
patch here. Or what would be the process?
On Sun, Apr 17, 2011 at 9:58 PM, pqf wrote:
> 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: svn commit: r1057048 - in /httpd/httpd/trunk: CHANGES modules/generators/mod_status.c
On Sun, Jan 9, 2011 at 6:00 PM, wrote:
> Author: sf
> Date: Sun Jan 9 23:00:33 2011
> New Revision: 1057048
>
> URL: http://svn.apache.org/viewvc?rev=1057048&view=rev
> Log:
> mod_status: Don't show slots which are disabled by MaxClients as open.
They now get displayed as ' ' instead of '.'.
No complaints here about not displaying unused slots as open, but the
result can look a bit odd.
-cut here---
1 requests currently being processed, 49 idle workers
_
__W__
Scoreboard Key:
---cut here--
On Windows, with huge default ThreadLimit relative to ThreadsPerChild,
you're left with lots of unexpected whitespace.
What about just surpressing the ' ' when printing out the worker map?
After a graceful restart which shrinks MaxClients or ThreadsPerChild
you might have the map gradually get smaller for a short time as
workers in those "beyond" scoreboard entries exit, but generally it
would look better.
Comments? (Do folks want the space used to reflect ThreadLimit * ServerLimit?)
> Modified: httpd/httpd/trunk/modules/generators/mod_status.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/generators/mod_status.c?rev=1057048&r1=1057047&r2=1057048&view=diff
> ==
> --- httpd/httpd/trunk/modules/generators/mod_status.c (original)
> +++ httpd/httpd/trunk/modules/generators/mod_status.c Sun Jan 9 23:00:33 2011
> @@ -483,7 +492,8 @@ static int status_handler(request_rec *r
> ap_rputs("\"L\" Logging, \n", r);
> ap_rputs("\"G\" Gracefully finishing, \n",
> r);
> ap_rputs("\"I\" Idle cleanup of worker, \n", r);
> - ap_rputs("\".\" Open slot with no current
> process\n", r);
> + ap_rputs("\".\" Open slot with no current
> process,\n", r);
> + ap_rputs("\" \" Slot disabled by MaxClients
> setting\n", r);
(and/or by ThreadsPerChild)
Re: svn commit: r1057048 - in /httpd/httpd/trunk: CHANGES modules/generators/mod_status.c
On 26.04.2011 21:57, Jeff Trawick wrote:
On Sun, Jan 9, 2011 at 6:00 PM, wrote:
Author: sf
Date: Sun Jan 9 23:00:33 2011
New Revision: 1057048
URL: http://svn.apache.org/viewvc?rev=1057048&view=rev
Log:
mod_status: Don't show slots which are disabled by MaxClients as open.
They now get displayed as ' ' instead of '.'.
No complaints here about not displaying unused slots as open, but the
result can look a bit odd.
-cut here---
1 requests currently being processed, 49 idle workers
_
__W__
Scoreboard Key:
---cut here--
On Windows, with huge default ThreadLimit relative to ThreadsPerChild,
you're left with lots of unexpected whitespace.
What about just surpressing the ' ' when printing out the worker map?
After a graceful restart which shrinks MaxClients or ThreadsPerChild
you might have the map gradually get smaller for a short time as
workers in those "beyond" scoreboard entries exit, but generally it
would look better.
Comments? (Do folks want the space used to reflect ThreadLimit * ServerLimit?)
Modified: httpd/httpd/trunk/modules/generators/mod_status.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/generators/mod_status.c?rev=1057048&r1=1057047&r2=1057048&view=diff
==
--- httpd/httpd/trunk/modules/generators/mod_status.c (original)
+++ httpd/httpd/trunk/modules/generators/mod_status.c Sun Jan 9 23:00:33 2011
@@ -483,7 +492,8 @@ static int status_handler(request_rec *r
ap_rputs("\"L\" Logging, \n", r);
ap_rputs("\"G\" Gracefully finishing, \n",
r);
ap_rputs("\"I\" Idle cleanup of worker, \n", r);
-ap_rputs("\".\" Open slot with no current
process\n", r);
+ap_rputs("\".\" Open slot with no current process,\n", r);
+ap_rputs("\" \" Slot disabled by MaxClients
setting\n", r);
(and/or by ThreadsPerChild)
I'd say the additional slots are more of an implementation detail
(pre-allocated to allow increasing the actual available processes and
threads by graceful restart) and do not provide relevant information for
mod_status. So I am +1 for dropping, but can live with white space too.
Regards,
Rainer
Re: Problem with DNS lookup caching in reverse proxy
- Original Message - > Hello everybody, > > I have tried to solve my issue by contacting the users@ mailing list > but meanwhile I think this is the more appropriate list to address > it. > I have issues with the mod_proxy resolving a full qualified > servername via DNS and caching it in its connection pool so a change > in the resolver doesn't get noticed by mod_proxy. After trying all > the different possibilities that came to mind I'm back at where it > all started. > I still cannot find a solution to the problem that mod_proxy caches > the IP address resolved by DNS and thus doesn't acknowledge all > changes to it. With the help of Igor Galić on the users@ mailing > list and by means of Bug Report 50551 I am able to get about 95% of > the cases solved. But there still are cases where the resolved > address won't be changed. > But first let me describe the configuration more deeply: > > What we have is a configuration where the Apache Reverse Proxy (RPX) > is used to allow transparent switch of the backend JEE server. We > solve this by configuring an alias to the service on the backend. > The alias is then entered in whatever DNS resolver we use to point > to the one system which is currently meant to receive the request. > This allows us to make application changes on one system while the > other is still working, then transparently switching to the updates > server to do maintenance on the other. > > Now the problem with this is that Apache, or more exactly the > mod_proxy, has a connection pool mechanism which apparently binds to > a once resolved IP address "forever". See the type struct > proxy_conn_pool in file mod_proxy.h or just my description in Bug > Report 50551. > > It appears to me, and I believe I was able to show this by extensive > testing, that the member variable apr_sockaddr_t *addr /* Preparsed > remote address info */ > in this struct is responsible for this behavior and that this > preparsed remote address is invalidated only if the last pooled > connection in this connection pool is timed out. > > In my opinion the best solution to this problem would be to add an > additional perameter to mod_proxy to force a renewal of the DNS > resolve procedure for this address after a set timeout like it is > possible in mod_weblogic. Unfortunately this is way beyond my Instead of re-resolving after a set timeout, it would make sense to re-resolve after a timeout occured, marking the worker in error. The only question is: Is that the struct shared across the pool? > capabilities at the moment to implement it myself. But I wonder why > there seems to be no need for such an option so nobody implemented > it yet. Perhaps there is another I'm still not aware of? > > Regards > Slawo > > > > -Ursprüngliche Nachricht- > Von: Slawomir R. Janotta [mailto:s.jano...@aviope.de] > Gesendet: Freitag, 3. Dezember 2010 16:54 > An: us...@httpd.apache.org > Betreff: Re: [users@httpd] Problem with DNS lookup caching in reverse > proxy > > > > > Would it be a viable option for you to not use the DNS method, and > > instead do something like: > > > > > > BalanceMember https://backend1.mydomain.com:8080/ > > BalanceMember https://backend1.mydomain.com:8080/ status=+H > > > > > > ProxyPass / balancer://notsohotcluster > > ProxyPassReverse / balancer://notsohotcluster > > > > This will (probably) simply mitigate the DNS problem. > > > > > > i > > > > -- > > Igor Galić > > > > Tel: +43 (0) 664 886 22 883 > > Mail: i.ga...@brainsware.org > > URL: http://brainsware.org/ > > > > > Thank you very much, Igor. > Indeed, your suggestion solves most of the cases where I encounter > the > switch-over of the backend hosts. > However, this does *not* help in all cases, as this works only if the > backend is no more reachable and thus an error condition occurs. > Sometimes > I just want to switch from one backend to the other without shutting > any > of them. A working TTL in the connection pool or in the DNS cache > would be > ideal for this. > Perhaps I have to open a new Bug report in Bugzilla. > Regards > Slawo. > > > Sicherheitshinweis: > Dieses E-Mail von PostFinance ist signiert. Weitere Informationen > finden Sie unter: > https://www.postfinance.ch/e-signature. > Geben Sie Ihre Sicherheitselemente niemals Dritten bekannt. -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/
