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 2007-04-11 17:43
on 2007-04-11 22:05
On Thu, Apr 12, 2007 at 12:43:39AM +0900, Zac Elston 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.
on 2007-04-11 22:30
Brian Candler wrote: > On Thu, Apr 12, 2007 at 12:43:39AM +0900, Zac Elston 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 :) 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