Re: cgi-fcgi problems on Linux

Mark Brown (
Thu, 05 Sep 1996 10:12:13 -0400

Message-Id: <>
Subject: Re: cgi-fcgi problems on Linux 
In-Reply-To: <M.090596.012239.38@P133> 
Date: Thu, 05 Sep 1996 10:12:13 -0400
From: Mark Brown <>

Don Julien reports:

    I think the source code compatibility provided between CGI and
    FastCGI via fcgi_stdio is great.  However, I am having trouble
    with cgi-fcgi ...

    The examples/tiny-cgi and examples/tiny-fcgi2 sample programs are
    working for me, but examples/tiny-fcgi is not.  I am getting an
    errno of 22 back from the getpeername call in FCGX_IsCGI() in
    libfcgi/fcgiapp.c, which is making examples/tiny-fcgi think that
    it is CGI when it's not (consequently it tries to do a regular
    printf instead of FCGI_printf).

One thing I've been learning through my work on FastCGI is that
asssumptions about errno are almost never portable.  Especially
so for non-POSIX calls.

On all of the Open Market supported platforms (Solaris, SunOS, HP-UX,
Digital UNIX, IRIX, AIX, BSDI) the errno that comes back is ENOTCONN,
and EINVAL is not even mentioned as a possible errno value for
getpeername.  Sigh.

Does a different errno come back when you run the program as CGI?  If
so you can easily tweak the test and keep going for now.  If not you
will need to use a more elaborate work-around.  For instance, rather
than using cgi-fcgi as a command interpreter (#! cgi-fcgi -f) you
could run /bin/sh as a command interpreter and use it to set a special
environment variable before running cgi-fcgi.  Then test for this
special variable in FCGX_IsCGI.  Gross, but it would work.

One totally reliable test is to perform a non-blocking accept on the
file descriptor.  This will fail if the file descriptor is not a
listening socket.  There is some extra complexity caused by the
possibility that the accept will succeed in making a new connection;
then FCGX_IsCGI has to put that connection somewhere so that
FCGX_Accept will find it later.  We've already made this change but it
is connected to some other changes that aren't ready to release yet,
so you will need to do something yourself.  Sorry.

    The getpeername is using socket# FCGI_LISTENSOCK_FILENO, which is
    #defined to be 0.  I'm not too familiar with sockets, but is this
    a bad value for use with Linux, or is something else wrong
    instead?  What would be the impact to the rest of FastCGI if I
    changed this to something else?

It would be pretty weird for Linux to treat file descriptor zero in a
special way.  I doubt this is the source of your problem.  You could
of course make sure by changing the code to perform a dup before
calling getpeername.

Let us know what you find out.