Received: with ECARTIS (v1.0.0; list gopher); Fri, 28 May 2004 14:12:32 -0500 (CDT) Return-Path: X-Original-To: gopher@complete.org Delivered-To: gopher@complete.org Received: from localhost (localhost [127.0.0.1]) by glockenspiel.complete.org (Postfix) with ESMTP id 88A0B114 for ; Fri, 28 May 2004 14:12:31 -0500 (CDT) Received: from glockenspiel.complete.org ([127.0.0.1]) by localhost (glockenspiel [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 26569-04 for ; Fri, 28 May 2004 14:12:29 -0500 (CDT) Received: from dns2.EurNetCity.NET (dns2.eurnetcity.net [80.68.196.9]) by glockenspiel.complete.org (Postfix) with ESMTP id 01801C9 for ; Fri, 28 May 2004 14:12:28 -0500 (CDT) Received: from brillante.route-add.net (postfix@brillante.route-add.net [80.68.194.26] (may be forged)) by dns2.EurNetCity.NET (8.11.6p2-20030924/8.11.6) with SMTP id i4SIXUQ17611 for ; Fri, 28 May 2004 20:33:30 +0200 Received: from marana (marana [192.168.1.4]) by brillante.route-add.net (Postfix) with ESMTP id 957051030 for ; Fri, 28 May 2004 21:12:06 +0200 (CEST) Date: Fri, 28 May 2004 21:12:58 +0200 (CEST) From: Alessandro Selli To: gopher@complete.org Subject: [gopher] Re: Pygopherd and xinetd In-Reply-To: <20040528130832.GB9268@excelhustler.com> Message-ID: References: <20040528130832.GB9268@excelhustler.com> MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-EurNetCity-MailScanner-Information: Please contact the ISP for more information X-EurNetCity-MailScanner: Found to be clean X-MailScanner-From: dhatarattha@route-add.net X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at complete.org X-archive-position: 924 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: dhatarattha@route-add.net Precedence: bulk Reply-to: gopher@complete.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: Gopher X-List-ID: Gopher List-subscribe: List-owner: List-post: List-archive: X-list: gopher Il giorno Fri, 28 May 2004, John Goerzen così ha scritto: |From: John Goerzen |To: gopher@complete.org |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