Date: Tue, 17 Sep 1996 12:09:57 -0700 (PDT) From: "Eric J. Schwertfeger" <firstname.lastname@example.org> To: email@example.com Subject: Re: Having problems with external servers In-Reply-To: <Pine.BSI.3.94.960916184759.14421A-100000@harlie> Message-Id: <Pine.BSI.3.94.960917075519.11833A-100000@harlie> On Mon, 16 Sep 1996, Eric J. Schwertfeger wrote: > I've just started using fastcgi, and while I like it, it adds new layers > of complication to things :-) > > I'm trying to use an external server, launched with > > ./cgi-fcgi -start -connect :9979 /usr/jay/bin/tiny.fcgi > > This runs, gives no errors, but nothing can connect to it. If I do a ps > on the machine (a SunServer 20, uname -a reports "SunOS arch9 5.4 generic > sun4m sparc") the process doesn't show up, and a netstat -an shows nothing > bound to port 9979. Has anyone seen this? > If it makes any difference, we don't have a compiler on this machine, so > I had to compile fast-cgi on a similar machine, but running 5.3 Most certainly makes a difference. I tried the same thing on the machine that I compiled it on, and it works fine there. So, shuffled disk space, installed the compiler on the other machine, and now it works, for the most part. The question is, the server is responsible for relaunching any fcgi procs that die that run locally. How can you do this if it isn't local? These things die entirely too easily. Telnet to it, control-D, and enter, and you take the server process with you. This is kind of important to me, since I need to have a single, controlling and coordinating process running at all times. I'll have to play around with shared memory if I run multiple server instances. This is one of our intranet apps, so it needs to run predictably On the other hand, if something bizarre happens, and my server process dies, I need to relaunch one, because things don't work without it.