Re: Run away 4GL's

---------- From: Jonathan Leffler To: Watson, Paul Cc: CDI Subject: Re: Run away 4GL's Date: 25 February 1999 00:10 On Wed, 24 Feb 1999, Watson, Paul wrote: [cutting] >I suspect that the problem is related to what happens when the PC process >vanishes, and a SIGHUP is generated by the kernel. The I4GL process then >goes into a tail-spin because it tries to reset the terminal settings (stty >settings) to those it found at startup, but the ioctl() call that does this >generates another SIGHUP because the terminal (actually a pty or pseudo-tty >device) at the far end isn't there, and this goes on repeating at rather >high speed for a very long time. This is certainly a problem that has >afflicted a number of machine types at various times. I don't recall it >being a problem on Solaris, but it is quite possible that it is the case. What do you mean by the PC process vanishing, the PC is still on the network and pingable, and the telnet session is still working OK as far I can tell. I think there is a lot mileage in the stty settings and resetting and could explain the why catting to the device clears the problem. If the PC has 'disappeared' or the telnet wasn't be closed correctly then I have no problems with what going on but this isn't the case. >You could verify what's going on by running truss on one of the runaway >processes (truss -p $runaway_pid) as root. If I'm right, you'll see a >clear pattern in the output running over a repeat cycle of about 15 lines. There is no repeating pattern just the same line continuously, read stdin >>It happens to a number of different 4ges, for users on different subnets. >> >>Oddly sending any message to the runaway screen clears the problem. >What do you mean by this? If I cat to the pty, talk to the id, generate mail message warning to the screen, basically any command that will echo to the 'problem' session. >I'd hazard a guess that sending a message to the >pty device leaves the pty in a non-HUP state for long enough for the I4GL >process to do its ioctl() thing and then exit. I'd be curious to see an >abbreviated version of the truss output as you do send the message -- if >I'm at all right, of course. This would be well worth catching >>It also never happened on the old E2000 Solaris 2.4 and Informix 4gl 4.14 >>SE 5.06. The termcaps on both machines are the same. >But the signal handling code was modified after that... True

Watson, Paul wrote: > From: Jonathan Leffler > On Wed, 24 Feb 1999, Watson, Paul wrote: > [cutting] > >I suspect that the problem is related to what happens when the PC process > >vanishes, and a SIGHUP is generated by the kernel. The I4GL process then [SNIP] > What do you mean by the PC process vanishing, the PC is still on the network > and pingable, and the telnet session is still working OK as far I can tell. [SNIP] Paul, Jonathan, I have a vague memory about a particular R4GL pcode runner that had been incorrectly coded to poll the keyboard for input rather than using a blocking read. If that memory is correct could 4.20 be that version? If I remember it was quickly caught and a new release made available that did not have the problem. This goes back about 5-6 years. Art S. Kagel