Bug 9534 - rewritemap using external map program gets out of sync
Summary: rewritemap using external map program gets out of sync
Status: CLOSED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_rewrite (show other bugs)
Version: 2.0.40
Hardware: PC Linux
: P3 normal with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: PatchAvailable
: 12175 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-05-31 03:40 UTC by Bruno Wolff III
Modified: 2004-11-16 19:05 UTC (History)
1 user (show)



Attachments
Working Fix against 2.0.39, but still needs some work (uses Non-Apache-Constant EAGAIN) (1.14 KB, patch)
2002-06-24 15:07 UTC, Sven Koch
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bruno Wolff III 2002-05-31 03:40:34 UTC
I am using an external rewritemap program (in perl with STDOUT
getting flush by each print statement) with a prefork mpm and I
am seeing the returned values be returning to the wrong requests.
Often the first one or two lookups return no value (from rewritelog)
and after that the returned values often seem to be offset by this
amount with respect to request. Logs from the program indicate that
it is returning the correct value based on the input it is receiving.
I have seen this occur in several 2.0.37 snapshots, the latest being
httpd-2.0_20020530221254.tar.gz .
The following rewrite directives are being used:
Rewritelock /home/httpd/html/robot/lock
Rewritemap blocked prg:/home/httpd/html/robot/check.pl
A current copy of the program can be found at:
http://wolff.to/robot/check.pl
I have played with the lockfile (ownership, access rights and
existence) and haven't seen any differences in behavior.
Comment 1 Sven Koch 2002-06-24 15:07:51 UTC
Created attachment 2167 [details]
Working Fix against 2.0.39, but still needs some work (uses Non-Apache-Constant EAGAIN)
Comment 2 Bruno Wolff III 2002-06-24 17:11:24 UTC
I tried this using the current CVS after receiving the update message
and I am still seeing the problem. I am including an extract from
my rewrite log. I changed the script to return the IP address it was
asked to lookup which should match that of the request. The log makes
it clear that it doesn't. I also included part of my httpd.conf
file relating to the external map. I am running a 2.2 linux kernel.
If you need other information, I should be able to probably help. I really would
like to see this issue fixed. Thanjs for working on this issue.
RewriteLock /home/httpd/html/robot/lock
Rewritemap blocked prg:/home/httpd/html/robot/check.pl
127.0.0.1 - - [24/Jun/2002:12:02:03 --0500] [localhost/sid#81a6cc0][rid#8241120/initial] (5) map lookup OK: map=blocked key=127.0.0.1 -> val=
127.0.0.1 - - [24/Jun/2002:12:02:05 --0500] [localhost/sid#81a6cc0][rid#8241120/initial] (5) map lookup OK: map=blocked key=127.0.0.1 -> val=OK-127.0.0.1
64.24.12.167 - - [24/Jun/2002:12:02:11 --0500] [wolff.to/sid#81a6cc0][rid#8247138/initial] (5) map lookup OK: map=blocked key=64.24.12.167 -> val=OK-127.0.0.1
64.24.12.167 - - [24/Jun/2002:12:02:13 --0500] [wolff.to/sid#81a6cc0][rid#8241120/initial] (5) map lookup OK: map=blocked key=64.24.12.167 -> val=OK-64.24.12.167
64.24.12.167 - - [24/Jun/2002:12:02:14 --0500] [wolff.to/sid#81a6cc0][rid#8241120/initial] (5) map lookup OK: map=blocked key=64.24.12.167 -> val=OK-64.24.12.167
127.0.0.1 - - [24/Jun/2002:12:02:18 --0500] [localhost/sid#81a6cc0][rid#8241120/initial] (5) map lookup OK: map=blocked key=127.0.0.1 -> val=OK-64.24.12.167
Comment 3 Cliff Woolley 2002-06-24 17:13:45 UTC
This issue is not yet fixed in CVS.  The patch attached to this PR has not yet 
been committed.  I've reviewed it, though, and it seems quite on-target.  I'll 
commit a variant of it (fixing it to use APR_EAGAIN) sometime tonight. 
 
--Cliff 
Comment 4 Bruno Wolff III 2002-06-27 14:18:39 UTC
Sorry this took a while. I managed to miss that you had included
the patch in the bugzilla entry so that I could use it before it
was committed to CVS. I just tried out the patch applied to the
current CVS (about two hours old) and it seemed to fix my problem.
Thanks.
Comment 5 Sven Koch 2002-08-20 15:44:52 UTC
Just adding:
it is not fixed in apache 2.0.40, the same ugly patch from 2.0.39 is still needed.
Comment 6 Cliff Woolley 2002-08-20 17:34:50 UTC
Okay, upon further investigation, I believe the correct fix is actually this: 
 
line 3463: 
 
-        ((rc = apr_procattr_io_set(procattr, APR_FULL_BLOCK, 
-                                  APR_FULL_NONBLOCK, 
-                                  APR_FULL_NONBLOCK)) != APR_SUCCESS) || 
+        ((rc = apr_procattr_io_set(procattr, APR_FULL_BLOCK, APR_FULL_BLOCK, 
+                                   APR_NO_PIPE)) != APR_SUCCESS) || 
 
 
It's because reads are set to nonblocking mode that we're getting hosed here.  
You shouldn't have to check for APR_EAGAIN from apr_file_read()... it's only 
getting returned because we told it to (by setting nonblocking mode).  Oops! 
 
Please let me know if this fixes it and I'll commit the change. 
 
--Cliff 
Comment 7 Bruno Wolff III 2002-08-21 17:09:45 UTC
I tested the suggestion to change the read to blocking and it seemed
to work correctly. (I had also removed the previous fix for this test.)
Comment 8 Cliff Woolley 2002-08-21 17:49:15 UTC
Fixed for 2.0.41. 
 
Thanks for your feedback! 
Comment 9 Joshua Slive 2002-08-29 20:41:54 UTC
*** Bug 12175 has been marked as a duplicate of this bug. ***