Taskboy.com and Pudge.net are on the same server. This machine has an unusually apache set up:
one apache server answers on port 80 and uses name-based virtual servers to handle Taskboy and Pudge.net. The virtual server conf actually palms the requests off to another apache process (configured with mod_perl) running on local host. Responses are then proxied back through the first apache process. Sound confusing? It is. Now, let's throw XML-RPC into the mix.
mod_perl, Apache and XML::Parser don't mix without special care. Why? Because XML::Parser and Apache each have their own expat libraries. Since mod_perl jams these two things into the same process space, seg faults happen whenever a mod_perl script (like an XML-RPC client) tries to use XML::Parser.
The solution is to compile Apache without expat, which isn't hard.
The server config mentioned above made this problem really obscure. I was getting 502 proxy errors from the server on port 80. This was bugging me out until I check its error_log and noticed the seg faulting children. Then it clicked.
I'll resolve this problem tomorrow (there are also two versions of Perl on the system, so I need to be awake when compiling).
Re:"perl6"
jjohn on 2001-10-20T22:40:45
/usr/bin/perl is 5.004x;/usr/local/bin/perl is 5.6.1. This led to a fun round of "what the hell isn't the module I just installed showing up?!"
Re:1.3.22
jjohn on 2001-10-20T22:39:14
I am now using 1.3.22 with mod_perl 1.26. I still took out EXPAT from apache, since I don't need it.Re:1.3.22
pudge on 2001-10-21T03:23:31
Does this mean we have *three* Apaches running on the server? We can surely shrink it down to two... Re:1.3.22
jjohn on 2001-10-22T21:00:32
Yes. There are three apaches. Expect a casino to appear soon.Re:1.3.22
pudge on 2001-10-22T21:15:19
We need to get together and share one mod_perl-enabled Apache if we can.
