Webrick w/ XML-RPC w/ xinetd

greetings. I can’t find a clue on the net or in the forums for this one

I have a XML-RPC service that works fine in standalone mode. I
attempted to control it via xinetd, and while I’m able to get it to
launch, I have to deal with a problem in the response.

when I connect to my service I get

/usr/lib/ruby/1.8/net/http.rb:1990:in `read_status_line’: wrong status
line: “[2007-04-11 11:21:03] INFO WEBrick 1.3.1” (Net::HTTPBadResponse)

so I can tell that I’m getting the stdout from the creation of the
webbrick server instead of my intended response as the first line and my
client bails on that…

telnet 0 9090
Escape character is ‘^]’.
[2007-04-11 11:36:17] INFO WEBrick 1.3.1
[2007-04-11 11:36:17] INFO ruby 1.8.4 (2005-12-24) [i386-linux]
[2007-04-11 11:36:17] INFO WEBrick::HTTPServer#start: pid=15629 port=80
(yes those port numbers bother me but it appears to be working so maybe
it’s a mistake)

is there a way to tell webrick not to give that info on startup? or
some other method of managing the transaction?

thanks

-zaq

On Thu, Apr 12, 2007 at 12:43:39AM +0900, Zac E. wrote:

/usr/lib/ruby/1.8/net/http.rb:1990:in `read_status_line’: wrong status
line: “[2007-04-11 11:21:03] INFO WEBrick 1.3.1” (Net::HTTPBadResponse)

As you’ve discovered, you can’t run Webrick as an inetd service.

I’ve never seen anyone run a web service out of inetd. The nearest you
get
to this normally is a CGI, where the web server forks a CGI process and
provides it with a CGI environment, which is a modified form of HTTP
environment.

Having said that: there’s no theoretical reason why you couldn’t do
this.
But you’ll have to hack out the bits of Webrick which are of interest:
bypass the bit which starts up a listening socket, and pass the incoming
request directly to whichever bit handles one request. If you want to do
this, you’re on your own. Good luck.

But do you have any particular reason not to use Webrick? If you start
a
Ruby interpreter for every incoming request it will be horribly
inefficient
anyway. You can always put an Apache proxy in front of it if you’re not
happy with the outside world talking directly to Webrick. Or you can run
your application under fastcgi with mod_fcgid.

B.

Brian C. wrote:

On Thu, Apr 12, 2007 at 12:43:39AM +0900, Zac E. wrote:

/usr/lib/ruby/1.8/net/http.rb:1990:in `read_status_line’: wrong status
line: “[2007-04-11 11:21:03] INFO WEBrick 1.3.1” (Net::HTTPBadResponse)

As you’ve discovered, you can’t run Webrick as an inetd service.

I guess technically I did, but it’s not going to do what I want :slight_smile:
indeed it was a silly way to manage a problem. I just made it a normal
service and that works…I was looking for a way to manage the service,
and xinetd was my first attempt.

But do you have any particular reason not to use Webrick?

only in theory, as I wasn’t sure of the stability of the app. this
XML-RPC app needs to run constantly to provide status of the host. I’ll
test it over the next week to see if it has issues with longevity. it’s
not managing production traffic or anything, so this just responds
whenever someone needs a status (ie, did my code push work
ok…check…ok, thanks…sleep until next push…) My main app is a rails
thingy so I just tried the ruby XML-RPC code example as my first attempt
for proof of concept. a real C server should be the next gen of this
“server monitor” to talk to the rails XML-RPC client.

that said…thanks for the refresher

-zaq