Kenneth Porter wrote:
> --On Monday, February 07, 2005 8:45 PM -0600 Steve Cohen
> <scohen@javactivity.org> wrote:
>
>> Thanks, but I don't think it's a firewall issue. I don't have one. This
>> is basically a home PC that runs Linux. It is protected from the outside
>> world by a broadband router with a firewall, but I think this just
>> affects eth0, not lo. Or do I have that wrong?? At any rate, iptables is
>> running on my system but is set to allow everything.
>
>
> What does "iptables -L" report? That will definitively tell you the
> contents of the firewall.
# /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
>
>> No, that isn't it either. It now appears that port 15835 is specified in
>> basic_tests.py as the port to listen on. So that makes sense as the port
>> to be specified in the spec.
>>
>> I think that what the test is trying to tell me is that something is
>> wrong with my apache setup. Still don't know what, though.
>
>
> I don't think Apache is even involved. It sounds like a standalone
> Subversion server is set up for the tests to work against. It listens on
> that port for connections from the test harnesses.
>
I think you're wrong about that. Here's the test output just before the
block of tests that failed:
+ echo '*** Running regression tests on RA_DAV (HTTP method) layer ***'
*** Running regression tests on RA_DAV (HTTP method) layer ***
+ killall httpd
+ sleep 1
++ pwd
+ sed -e 's;@SVNDIR@;/usr/src/redhat/BUILD/subversion-1.1.3;'
++ pwd
+ /usr/sbin/httpd -f /usr/src/redhat/BUILD/subversion-1.1.3/httpd.conf
httpd: Could not determine the server's fully qualified domain name,
using 127.0.0.1 for ServerName
+ sleep 1
It looks to me that the test is killing the apache daemon (httpd) and
then restarting it with the config that comes with the build.
Interestingly, after the build completes, reporting failure, my apache
daemon is in a bad state:
# /sbin/service httpd status
httpd dead but subsys locked
It is easily restarted using
/sbin/service httpd restart
and then everything works fine, including my already
installed-from-binary-rpm subversion.
So I think that quite definitely apache is involved here, somehow. The
question is, how?
Looking at the files in /var/log/httpd, I see a few entries that are
possibly of interest at the time of the tests, but I don't know what
they signify here:
/var/log/httpd/error_log:
[Mon Feb 07 22:29:37 2005] [warn] child process 7277 still did not exit,
sending a SIGTERM
[Mon Feb 07 22:29:37 2005] [warn] child process 7278 still did not exit,
sending a SIGTERM
[Mon Feb 07 22:29:37 2005] [warn] child process 7279 still did not exit,
sending a SIGTERM
[Mon Feb 07 22:29:37 2005] [warn] child process 7280 still did not exit,
sending a SIGTERM
[Mon Feb 07 22:29:37 2005] [warn] child process 7281 still did not exit,
sending a SIGTERM
[Mon Feb 07 22:29:37 2005] [notice] caught SIGTERM, shutting down
Judging from the timestamps, and the test output above, I surmise that
perhaps the shutdown of httpd was not complete. Is "sleep 1" enough
time to for the shutdown to complete? If I try to shutdown manually:
/sbin/service httpd stop
there is a noticeable delay before it comes back, although I'm not sure
it's as much as a second.
Well, can anyone make sense of all these symptoms and tell me what's
going on?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 8 13:00:24 2005