Re: Run away 4GL's

On Thu, 25 Feb 1999, Watson, Paul wrote: >From: Jonathan Leffler >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. [...more details...] > >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. Something has occurred to break the connection for the application. >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. I'm not clear what's going on, but something is cutting the standard input connection to the I4GL program, and it is not handling that very well. >>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 OK - the repeat cycle is 1 line, and the bug is not related to signal handling. Most of my previous hypotheses are therefore irrelevant. The bug is that zero bytes are being read (the read() call returns either 0 or -1, doesn't it?), and this is being ignored by the executable. This problem is supposed to be fixed, too, but maybe it isn't. I forget the details of the correct fix, but when you get zero bytes from the terminal in raw mode (so that control-D or equivalent is not being interpreted by the terminal driver code), there isn't a terminal left and the program should give up -- but isn't doing so. >>>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 Even though the signal handling should not be relevant, it would still be interesting to see what happens to the application to take it out of its spin cycle - so if you get the opportunity to use truss on a runaway and then terminate the process by sending a message to the pty, then I'd be interested to see (an abbreviated version of) the clean up actions, from the last 5 reads() in a loop to the end, say. Yours, Jonathan Leffler (jleffler@informix.com) #include <wish/I/was/skiing.h> Guardian of DBD::Informix v0.60 (v0.61_02) -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn

In article <7b4993$o21$1@news.xmission.com>, Jonathan Leffler <jleffler@informix.com> writes > >I'm not clear what's going on, but something is cutting the standard input >connection to the I4GL program, and it is not handling that very well. Correct. > >The bug is that zero bytes are being read (the read() call returns either 0 >or -1, doesn't it?), and this is being ignored by the executable. This -1 = fail, anything else is the number of bytes read. It is valid for read() to return less bytes than requested. I believe that the read call is returning 0 and the program should exit then, this is a known bug which also affected dbaccess/isql and should be fixed in the later versions... We had fun watching dbaccess clock up over 10000 seconds of CPU time!! > >Yours, >Jonathan Leffler (jleffler@informix.com) #include <wish/I/was/skiing.h> >Guardian of DBD::Informix v0.60 (v0.61_02) -- http://www.perl.com/CPAN >Informix IDN for D4GL & Linux -- http://www.informix.com/idn > -- David Williams