Complete.Org: Mailing Lists: Archives: gopher: May 2004:
[gopher] Re: Pygopherd and xinetd
Home

[gopher] Re: Pygopherd and xinetd

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gopher@xxxxxxxxxxxx
Subject: [gopher] Re: Pygopherd and xinetd
From: Alessandro Selli <dhatarattha@xxxxxxxxxxxxx>
Date: Fri, 28 May 2004 21:12:58 +0200 (CEST)
Reply-to: gopher@xxxxxxxxxxxx

Il giorno Fri, 28 May 2004, John Goerzen così ha scritto:

|From: John Goerzen <jgoerzen@xxxxxxxxxxxx>
|To: gopher@xxxxxxxxxxxx
|Date: Fri, 28 May 2004 08:08:32 -0500
|Subject: [gopher] Re: Pygopherd and xinetd
|
|On Fri, May 28, 2004 at 11:25:09AM +0200, Alessandro Selli wrote:
|>   I finally set pygopherd_2.0.9 up and running on route-add.net, after 
|> installing python2.3 side to side with the server's native python2.1.
|> I noticed that I cannot run it from xinetd, when I try to I get this error 
in 
|> the log:
|
|PyGopherd does not have any support for running from inetd or xinetd at
|present.  That support would probably be trivial to implement, but it's
|just not there right now.

  Oh well, it doesn't matter.  The old sparky has got so much RAM I can 
leave pygopherd run all the time whithout trouble.

|Let me explain some of the errors you're getting:
|
|> May 25 20:28:16 brillante pygopherd[25192]: Pygopherd starting, using 
|> configuration file /etc/pygopherd/pygopherd.conf
|> May 25 20:28:17 brillante pygopherd[25192]: mimetypes initialized with 
files: 
|> ['./conf/mime.types', '/etc/pygopherd/mime.types', '/etc/mime.types']
|> May 25 20:28:18 brillante pygopherd[25192]: unknown-address [None/None] 
|> EXCEPTION error: (48, 'Address already in use')
|
|That's because PyGopherd attempts to listen to a port that is already
|being listened on by xinetd.

  Just as I thought!  :^)

|> May 25 20:28:18 brillante pygopherd[25192]: Application startup NOT 
successful!
|> 
|>   When I run it as a standalone server, it runs all right.  When I wan to 
run 
|> it as a xinetd-run service, I put "detach = yes" in 

  Well, this was wrong anyway, when a server is run from xinetd it should not 
detach/fork (are the two terms interchangeable?) on its own, since xinetd 
takes  care of that (I realized this some time ago when I wanted Qpopper to 
run from xinetd and it failed, IIRC).  I either remebered wrong what I did, or
I wrote the wrong thing or I messed up xinetds' configuration.

|Unfortunately, all detach does is tell PyGopherd to run as a Unix daemon
|-- that is, it forks itself off, continues listening for connections in
|the backgrouns, and returns immediately.

  So, if I put "detach = no" then the server is busy and does not answer 
new connections until the current one ends (that is, until the current data 
transfer completes)?

|> Oh, by the way, John, I noticed this typo in the pygopherd/README file:
|
|Oops :-)

  I want to be mentioned in the next Cahngelog!  :-D



  Sandro


-- 
Bellum se ipsum alet
       La guerra nutre se stessa

Livio, "Ab urbe condita", XXXIV,9


[Prev in Thread] Current Thread [Next in Thread]