filePro with no stdin (was Re: Hosting filePro applications)

[Fairlight]

In the relative spacial/temporal region of
Mon, Jan 23, 2006 at 08:48:49PM -0500, Kenneth Brody achieved the spontaneous
generation of the following:
> Quoting Fairlight (Mon, 23 Jan 2006 19:25:24 -0500):
> [...]
> > rclerk 0>/dev/null 1>/dev/null 2>/dev/null
> >
> > Watch your CPU time on the process fly.  Note that it -only- races when
> > STDIN is closed.  If you -only- close STDIN, it appears to race a
> > little, but, not as hard--as opposed to the racing you'll see in
> > realtime if all three main fd's are closed.
> 
> Is stdin really closed?  Given the syntax of the above, it looks as if
> stdin is set to an output stream, rather than input.

In this test case, it's redirected to an input channel.  In the case of
running under a CGI engine, the fd's should actually -close-.  Technically
speaking, there are the 3 fd's associated with httpd, inherited by the CGI
engine of choice (fpcgi, onegate, home-brewed, whatever...), and further
inherited by a shell in most cases (fpcgi uses system(), as does onegate),
and then on down to filePro.  The middle two children basically vaporize.
Both fpcgi and onegate will vanish.  I'm pretty sure the shell does as
well, since the 'ps' listings grepping for dreport never list the sh -c
for it--only the actual dreport processes themselves.  If those vanish, I
presume STDIN is effectively closed.  Actually, that's what I surmise.  I
don't -know- that for a fact, and would be interested in hearing a more
definitive word.  I see two options:  1) it closes the fd's, or 2) the fd's
point to a resource that is as unusable as /dev/null.

No matter the underlying action, you get the same result as in the test I
illustrated.

> In either case, the above would cause read()s on stdin to return right
> away.  (Though it would indicate an error, rather than returning any
> input.  And, a quick look at the source shows that this error would
> probably act as if '\0' were read.)

I figured it probably kept trying to get a positive integer on read().
It seemed the only explanation.  Which, basically, if you just did that
unconditionally in a non-blocking situation, would be the sort of polling
loop I originally -thought- was occurring.

> > It's bad enough when this will happen if someone generates a
> > keystroke-requiring error (say, a double-declared GLOBAL, Press Enter)
> 
> But that shouldn't cause any hangups, unless isatty() returns TRUE
> for stdin in the above situation.  When the "*** A filePro/System
> error has occurred ***" error message is displayed, if isatty() for
> stdin returns FALSE, filePro will not wait for a keypress, but will
> instead pause 10 seconds and continue.

I don't -look for- the situations, they just find me.  :)  

I just know what actually happens, not why isatty() would be inaccurate (if
it is).  I can only assure you that one and a half weeks ago, I had to kill
six dreport processes stuck at a double declared GLOBAL variable error.
The output stream was directed to a debug file, and the error, along with a
request to press enter, were clearly visible.  Run time of said processes
ranged from 38-63 minutes depending on the process--which is a bit longer
than 10 seconds I think it's safe to say.  They were started at different
test points by the developer during testing of a new module.  Platform was
RHEL3, fully updated, Apache 2.0.46 [patched 70 ways from Sunday] (okay,
that answers the question about Apache 2.x killing these--it ONLY kills
the top-level child when all fd's are closed--and further, only -monitors-
the top-level child).  OneGate goes away as it should, dreport remains and
slurps CPU like there's going to be a power outtage tomorrow.

Hardly the first time I've had to intervene, either.  I just know what
actually causes it now.

> Well, now that the condition has been identified, it can be fixed.
> 
> Of course, the question becomes "what should filePro do if it needs
> input and stdin is closed or at EOF?"

If I get to offer my professional opinion, it should attempt to write the
error to STDOUT and/or STDERR (I notice -only- the 0x07 currently goes to
STDERR, the rest goes to STDOUT...weird), and then immediately exit.  The
error message should indicate the reason (eg., "Input required, but no
terminal is attached.").

PLEASE don't skip the error reporting, as redirection debugging is
-crucial- to finding out why things crash or go awry in CGI programming.
The developers need these reports to be able to fix their code.  At least
if they get this, they can run the command line by hand and see where it's
waiting for keyed entry, then fix it.  The worst it can do is go nowhere if
the fd is closed or redirected to the bit bucket--which already causes no
problems when that's the case.  But it -should- be available.

> It's a lot better than "filePro's input is a polling loop".  :-)

It waddled and quacked like a duck until I shot it in the tail and it went,
"MMMooooooooOooOOoOOOoooo!"  :)

Sorry for the inaccurate report earlier, but I trust you see where it was
an honest mistake at first blush.

mark->