FreeBSD and filePro weirdness

[Fairlight]

Confusious (Walter Vaughan) say:
> We've noticed this happening a lot on our FreeBSD 6.1 filePro server. It
> seem like it started with the security upgrades to sshd recently. Zombie
> filePro processes that spin up to 100% CPU usage. Broken sessions cause
> this, and we've seen them for years on SCO Unix, and we just kill them
> off... they just seem to be running the CPU up to 100% on freeBSD vs
> idling at 0% on SCO. Ive seen it in the past few days with *clerk and
> *report as well.

I've seen it.  Usually in a web-based context, where the parent went away
(say the client/server connection timeout threshhold was exceeded), but
*report or *clerk would keep spinning.  Generally this ends up being an
error in fP coding or fP itself where it sits in a polling loop on STDIN,
eating CPU in realtime, waiting for something that will never come--a
keypress from a terminal that was never there.

I've also had bad experiences with fP not reacting to signals (technically,
when the parent processes go away on signals or otherwise, fP should as
well but doesn't).  I suspect something either isn't generating SIGHUP, or
SIGHUP isn't being honoured in your case.  If FBSD has strace (I'll use the
strace equivalent...try it with whatever tools are available), try:

strace -p [pid]

If you see read after read on fd 0 returning 0, that's exactly what's
happening.  For why fP isn't going away, ask fP-Tech.  I've always had a
problem with it not going away when its parent does, both under fPCGI,
OneGate, telnet, etc.  I've seen this on many systems.

mark->