You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Bruno Wolff III <br...@wolff.to> on 2002/05/22 17:34:33 UTC

2.0.37-dev external map lookups out of sync

I had been using a program to do CDB lookups under apache 1.3.x.
I am using the following in the httpd.conf file:
Rewritelock /home/httpd/html/robot/lock
Rewritemap blocked prg:/home/httpd/html/robot/check.pl

Under 2.0.37-dev (a snapshot from yesterday), the correct string is
not returned. I had the lookup program log its output and it looked
OK. Looking the at access logs indicated that the wrong requests were
getting blocked. So it looks like the returned value isn't always
being returned to the correct request. I am running with an MPM of
prefork.

If you want to look at the perl program it is available at:
http://wolff.to/robot/check.pl

The data on the lockfile in the documentation is pretty sparse. It doesn't
indicate what access is needed to the lock file. I have tried a number
of different protections (including 666) and that doesn't seem to make
a difference.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: 2.0.37-dev external map lookups out of sync

Posted by Bruno Wolff III <br...@wolff.to>.
On Fri, May 24, 2002 at 10:59:41 -0500,
  Bruno Wolff III <br...@wolff.to> wrote:
> On Wed, May 22, 2002 at 10:34:33 -0500,
>   Bruno Wolff III <br...@wolff.to> wrote:
> > I had been using a program to do CDB lookups under apache 1.3.x.
> > I am using the following in the httpd.conf file:
> > Rewritelock /home/httpd/html/robot/lock
> > Rewritemap blocked prg:/home/httpd/html/robot/check.pl

I got a mode recent snapshot (httpd-2.0_20020526101254.tar.gz), but I
am still having problems. There may be a mixture of things going on.
When I restart the service I usually have one or two lookups fail and
then I see some off by two (or one) behavior.

I am using the prefork MPM.

In the rewrite log extract below 64.24.12.185 should be returning 'BLOCKED'
and 66.237.60.5 should be returning 'OK'. I have checked the program doing
the lookups by having it log its responses and it properly returns the
response for the value it was given.

66.237.60.5 - - [26/May/2002:08:50:17 --0500] [wolff.to/sid#81a0aa0][rid#8233ca8/initial] (5) map lookup OK: map=blocked key=66.237.60.5 -> val=
66.237.60.5 - - [26/May/2002:08:50:17 --0500] [wolff.to/sid#81a0aa0][rid#823acd0/initial/redir#1] (5) map lookup OK: map=blocked key=66.237.60.5 -> val=
64.24.12.185 - - [26/May/2002:08:50:28 --0500] [wolff.to/sid#81a0aa0][rid#8233ca8/initial] (5) map lookup OK: map=blocked key=64.24.12.185 -> val=OK
64.24.12.185 - - [26/May/2002:08:50:30 --0500] [wolff.to/sid#81a0aa0][rid#8233ca8/initial] (5) map lookup OK: map=blocked key=64.24.12.185 -> val=OK
66.237.60.5 - - [26/May/2002:08:50:30 --0500] [wolff.to/sid#81a0aa0][rid#8233ca8/initial] (5) map lookup OK: map=blocked key=66.237.60.5 -> val=BLOCKED
64.24.12.185 - - [26/May/2002:08:50:32 --0500] [wolff.to/sid#81a0aa0][rid#8233ca8/initial] (5) map lookup OK: map=blocked key=64.24.12.185 -> val=BLOCKED
66.237.60.5 - - [26/May/2002:08:50:36 --0500] [wolff.to/sid#81a0aa0][rid#8239cc0/initial] (5) map lookup OK: map=blocked key=66.237.60.5 -> val=OK
66.237.60.5 - - [26/May/2002:08:50:36 --0500] [wolff.to/sid#81a0aa0][rid#8240ce8/initial/redir#1] (5) map lookup OK: map=blocked key=66.237.60.5 -> val=BLOCKED
64.24.12.185 - - [26/May/2002:08:50:36 --0500] [wolff.to/sid#81a0aa0][rid#8239cc0/initial] (5) map lookup OK: map=blocked key=64.24.12.185 -> val=OK
64.24.12.185 - - [26/May/2002:08:50:38 --0500] [wolff.to/sid#81a0aa0][rid#823bcc8/initial] (5) map lookup OK: map=blocked key=64.24.12.185 -> val=OK
64.24.12.185 - - [26/May/2002:08:50:39 --0500] [wolff.to/sid#81a0aa0][rid#8239cc0/initial] (5) map lookup OK: map=blocked key=64.24.12.185 -> val=BLOCKED
64.24.12.185 - - [26/May/2002:08:50:44 --0500] [wolff.to/sid#81a0aa0][rid#823bcc8/initial] (5) map lookup OK: map=blocked key=64.24.12.185 -> val=BLOCKED
66.237.60.5 - - [26/May/2002:08:50:56 --0500] [wolff.to/sid#81a0aa0][rid#8239cc0/initial] (5) map lookup OK: map=blocked key=66.237.60.5 -> val=BLOCKED

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: 2.0.37-dev external map lookups out of sync

Posted by Bruno Wolff III <br...@wolff.to>.
On Wed, May 22, 2002 at 10:34:33 -0500,
  Bruno Wolff III <br...@wolff.to> wrote:
> I had been using a program to do CDB lookups under apache 1.3.x.
> I am using the following in the httpd.conf file:
> Rewritelock /home/httpd/html/robot/lock
> Rewritemap blocked prg:/home/httpd/html/robot/check.pl
> 
> Under 2.0.37-dev (a snapshot from yesterday), the correct string is
> not returned. I had the lookup program log its output and it looked
> OK. Looking the at access logs indicated that the wrong requests were
> getting blocked. So it looks like the returned value isn't always
> being returned to the correct request. I am running with an MPM of
> prefork.
> 
> If you want to look at the perl program it is available at:
> http://wolff.to/robot/check.pl
> 
> The data on the lockfile in the documentation is pretty sparse. It doesn't
> indicate what access is needed to the lock file. I have tried a number
> of different protections (including 666) and that doesn't seem to make
> a difference.

I tried finding out more about this. I have found that a lookup (sometimes
two) fails (an empty value is returned accoridng to the rewrite log) after
restarting the server.

As far as I can tell the global mutex isn't working and it looks like if I
have two requests come in at the same time they can get the wrong response.
I have set $|=1 in my perl program so that the output buffer is flushed
after every print. I have a redhat 6.1 based system running a 2.2.16
kernel.

I have looked for errors indicating the lock file didn't exist and didn't
see any even when it didn't.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org