You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@perl.apache.org by "Christopher H. Laco" <cl...@chrislaco.com> on 2005/10/09 01:51:07 UTC

Apache-TEST RC Failure

In a fit of boredom, I wiped my FreeBSD install on my laptop and
installed Ubuntu. To continue that fit, I decided to install Apache2 and
give the Apache-Test 1.27 RC a testing.

At first shot, the cookies.t tests failed:

> claco@np5660:~/Apache-Test-1.27-dev$ perl t/TEST t/cookies.t -verbose
> [warning] setting ulimit to allow core files
> ulimit -c unlimited; /usr/bin/perl /home/claco/Apache-Test-1.27-dev/t/TEST 't/cookies.t' -verbose
> /usr/sbin/apache2  -d /home/claco/Apache-Test-1.27-dev/t -f /home/claco/Apache-Test-1.27-dev/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS
> using Apache/2.0.53 (worker MPM)
> 
> waiting 60 seconds for server to start: .
> waiting 60 seconds for server to start: ok (waited 0 secs)
> server localhost.localdomain:8529 started
> t/cookies....1..2
> # Running under perl version 5.008004 for linux
> # Current time local: Sat Oct  8 19:24:52 2005
> # Current time GMT:   Sat Oct  8 23:24:52 2005
> # Using Test.pm version 1.24
> # Using Apache/Test.pm version 1.27
> # testing : new cookie
> # expected: new
> # received: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> # <html><head>
> # <title>503 Service Temporarily Unavailable</title>
> # </head><body>
> # <h1>Service Temporarily Unavailable</h1>
> # <p>The server is temporarily unable to service your
> # request due to maintenance downtime or capacity
> # problems. Please try again later.</p>
> # </body></html>
> not ok 1
> # Failed test 1 in t/cookies.t at line 17
> # testing : existing cookie
> # expected: exists
> # received: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> # <html><head>
> # <title>503 Service Temporarily Unavailable</title>
> # </head><body>
> # <h1>Service Temporarily Unavailable</h1>
> # <p>The server is temporarily unable to service your
> # request due to maintenance downtime or capacity
> # problems. Please try again later.</p>
> # </body></html>
> not ok 2
> # Failed test 2 in t/cookies.t at line 18
> FAILED tests 1-2
>         Failed 2/2 tests, 0.00% okay
> Failed Test Stat Wstat Total Fail  Failed  List of Failed
> -------------------------------------------------------------------------------
> t/cookies.t                2    2 100.00%  1-2
> Failed 1/1 test scripts, 0.00% okay. 2/2 subtests failed, 0.00% okay.
> [warning] server localhost.localdomain:8529 shutdown
> [  error] error running tests (please examine t/logs/error_log)


As it turned out, the Ubuntu Apache2 install comes with both mod_cgi AND
mod_cgid installed and mod_cgid enabled. A-T apparently detects cgid and
tries using that in the config. The dies a horrible death because my
user (or nobody when runnung A-T as root) can't fire up and bind a new
cgid process when trying to run the cookies.pl test file. Once I
disabled mod_cgid (leaving mod_cgi) alone, all was well and all tests
passed.

So, was this just an unlucky happenstance on my machine, or should A-T
skip those tests if we have mod_cgid instead of mod_cgi? I guess I
wasn't aware that need_cgi passed with cgid.

P.S. What hell is up with how Ubuntu loads/enables modules in Apache2?
Holy complicated batman.

-=Chris

Re: Apache-TEST RC Failure

Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Geoffrey Young wrote:
>>> - is your setup somehow nonstandard?  my 2.0.54 worker install defaulted
>>>to mod_cgid and I have no problems with any tests?
>>
>>
>>If it is, it's whatever Ubuntu 5.04 installs.
>>I'll tinker more with it tonight and see where cgid leads me.
>>
>>I seem to recall it was a pure error about permissions and not being
>>able to bind to a socket as a regular old user.
>>
>>I'll tinker when I get home.
> 
> 
> see if playing around with this in various ways helps matters at all
> 
>   http://httpd.apache.org/docs/2.0/mod/mod_cgid.html#scriptsock
> 
> we might need to add a check to the writability of t/logs/cgisock or
> somesuch if using mod_cgid.
> 
> --Geoff
> 
> 
> 
Thanks for the link. I'll give that a shot.
I did manage to get apache1/mp1/apache2/mp2 2.0.2-dev running and happy
with A-T 1.26 last night.

I realized I needed to tweak my config to check for IfDefine APACHE or
APACHE2 so my AxKit conf didn't go boom under 2. Oops. :-)

-=Chris


Re: Apache-TEST RC Failure

Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Geoffrey Young wrote:
>> plan tests => 2, need [qw(CGI CGI::Cookie)],
>>-                      need_cgi, need_lwp;
>>+                      need_cgi, need_lwp, need_something_else;
> 
> 
> oops, that's not part of the patch, of course :)
> 
> 
> ------------------------------------------------------------------------
> 
> Index: lib/Apache/TestConfig.pm
> ===================================================================
> --- lib/Apache/TestConfig.pm	(revision 312711)
> +++ lib/Apache/TestConfig.pm	(working copy)
> @@ -2559,6 +2559,10 @@
>      TransferLog @t_logs@/access_log
>  </IfModule>
>  
> +<IfModule mod_cgid.c>
> +    ScriptSock @t_logs@/cgisock
> +</IfModule>
> +
>  ServerAdmin @ServerAdmin@
>  
>  #needed for http/1.1 testing

ha ha.. I was just about to ask what need_something_else did? :-)

-=Chris


Re: Apache-TEST RC Failure

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Patch applied clean, and all tests pass!

ok, cool.  I don't think this needs to go into the release, but the RM can
decide.  so, things will be fixed officially in the next or next next
version of A-T.

thanks

--Geoff

Re: Apache-TEST RC Failure

Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Geoffrey Young wrote:
>> plan tests => 2, need [qw(CGI CGI::Cookie)],
>>-                      need_cgi, need_lwp;
>>+                      need_cgi, need_lwp, need_something_else;
> 
> 
> oops, that's not part of the patch, of course :)
> 
> 
> ------------------------------------------------------------------------
> 
> Index: lib/Apache/TestConfig.pm
> ===================================================================
> --- lib/Apache/TestConfig.pm	(revision 312711)
> +++ lib/Apache/TestConfig.pm	(working copy)
> @@ -2559,6 +2559,10 @@
>      TransferLog @t_logs@/access_log
>  </IfModule>
>  
> +<IfModule mod_cgid.c>
> +    ScriptSock @t_logs@/cgisock
> +</IfModule>
> +
>  ServerAdmin @ServerAdmin@
>  
>  #needed for http/1.1 testing

Patch applied clean, and all tests pass!

Thanks,
-=Chris

Re: Apache-TEST RC Failure

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>  plan tests => 2, need [qw(CGI CGI::Cookie)],
> -                      need_cgi, need_lwp;
> +                      need_cgi, need_lwp, need_something_else;

oops, that's not part of the patch, of course :)

Re: Apache-TEST RC Failure

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>[Mon Oct 10 18:14:21 2005] [error] cgid daemon process died, restarting
>>[Mon Oct 10 18:14:21 2005] [error] (13)Permission denied: Couldn't bind unix domain socket /var/run/cgisock

ok, let's make sure it opens a socket in our local test directory and not
elsewhere where it might conflict with production.  try this patch

--Geoff

Re: Apache-TEST RC Failure

Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Geoffrey Young wrote:
>>> - is your setup somehow nonstandard?  my 2.0.54 worker install defaulted
>>>to mod_cgid and I have no problems with any tests?
>>
>>
>>If it is, it's whatever Ubuntu 5.04 installs.
>>I'll tinker more with it tonight and see where cgid leads me.
>>
>>I seem to recall it was a pure error about permissions and not being
>>able to bind to a socket as a regular old user.
>>
>>I'll tinker when I get home.
> 
> 
> see if playing around with this in various ways helps matters at all
> 
>   http://httpd.apache.org/docs/2.0/mod/mod_cgid.html#scriptsock
> 
> we might need to add a check to the writability of t/logs/cgisock or
> somesuch if using mod_cgid.
> 
> --Geoff
> 

That's right on target.

If cgid and cgi are enables, it appears to use cgi all tests pass.
Of course, it's fine with just cgi loaded.
With just cgid loaded, error_log yields:

> [Mon Oct 10 18:14:21 2005] [error] cgid daemon process died, restarting
> [Mon Oct 10 18:14:21 2005] [error] (13)Permission denied: Couldn't bind unix domain socket /var/run/cgisock

On my Ubuntu install, var/run is:

> drwxr-xr-x  13 root root  4096 2005-10-10 18:06 run

$ sudo chmod o+w /var/run
$ make test

All tests, including the cookies.t tests pass! :-)

Now, the default apache2 install config is set to use
/var/run/apache2/cgidsock

How and why that differs from /var/run/cgisock under the test suite, I'm
not sure.

-=Chris


Re: Apache-TEST RC Failure

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>  - is your setup somehow nonstandard?  my 2.0.54 worker install defaulted
>>to mod_cgid and I have no problems with any tests?
> 
> 
> If it is, it's whatever Ubuntu 5.04 installs.
> I'll tinker more with it tonight and see where cgid leads me.
> 
> I seem to recall it was a pure error about permissions and not being
> able to bind to a socket as a regular old user.
> 
> I'll tinker when I get home.

see if playing around with this in various ways helps matters at all

  http://httpd.apache.org/docs/2.0/mod/mod_cgid.html#scriptsock

we might need to add a check to the writability of t/logs/cgisock or
somesuch if using mod_cgid.

--Geoff



Re: Apache-TEST RC Failure

Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Geoffrey Young wrote:
>>As it turned out, the Ubuntu Apache2 install comes with both mod_cgi AND
>>mod_cgid installed and mod_cgid enabled. A-T apparently detects cgid and
>>tries using that in the config. The dies a horrible death because my
>>user (or nobody when runnung A-T as root) can't fire up and bind a new
>>cgid process when trying to run the cookies.pl test file. Once I
>>disabled mod_cgid (leaving mod_cgi) alone, all was well and all tests
>>passed.
> 
> 
> hmm...
> 
> ok, I don't know much about mod_cgid.  so the questions I have are
> 
>   - is your setup somehow nonstandard?  my 2.0.54 worker install defaulted
> to mod_cgid and I have no problems with any tests?

If it is, it's whatever Ubuntu 5.04 installs.
I'll tinker more with it tonight and see where cgid leads me.

I seem to recall it was a pure error about permissions and not being
able to bind to a socket as a regular old user.

I'll tinker when I get home.

Re: Apache-TEST RC Failure

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> As it turned out, the Ubuntu Apache2 install comes with both mod_cgi AND
> mod_cgid installed and mod_cgid enabled. A-T apparently detects cgid and
> tries using that in the config. The dies a horrible death because my
> user (or nobody when runnung A-T as root) can't fire up and bind a new
> cgid process when trying to run the cookies.pl test file. Once I
> disabled mod_cgid (leaving mod_cgi) alone, all was well and all tests
> passed.

hmm...

ok, I don't know much about mod_cgid.  so the questions I have are

  - is your setup somehow nonstandard?  my 2.0.54 worker install defaulted
to mod_cgid and I have no problems with any tests?

  - do you have problems with that same install and any of the cgi-based
tests in the mod_perl test suite?

> 
> So, was this just an unlucky happenstance on my machine, or should A-T
> skip those tests if we have mod_cgid instead of mod_cgi? 

I'm not convinced that cgi versus cgid is the exact issue.  it may be, but
if I can run them but you can't then there's something else amuck.  I'd
think we need something like

 plan tests => 2, need [qw(CGI CGI::Cookie)],
-                      need_cgi, need_lwp;
+                      need_cgi, need_lwp, need_something_else;

what that final condition might be is the key.  if we can figure it out,
we're in good shape.  if it's something that only applies to mod_cgid and is
global (like non-root users or somesuch) then I'd add it to the underlying
conditions in need_cgi().

> I guess I
> wasn't aware that need_cgi passed with cgid.

yes, that's the basic idea.  need_cgi is basically just asking "hey, do we
have a cgi module around and activated" so you don't need to figure out
whether it's mod_cgi or mod_cgid depending on your particular install.

--Geoff