getty and signals?

[Roger Cornelius]

>From article <1989Dec7.090500.6426 at nttor.uucp>, by rasmus at nttor.uucp (Rasmus Lerdorf):
- Hi, could someone tell me what signals a Xenix 2.3.x getty understands and 
- what the resulting getty action is upon receiving the signal?  And has there
- been a change from the 2.2.3 getty?  
- 
- I am asking because it seems uucico leaves the getty in a strange state after
- dialing out on a tty and not allowing logins on the same tty after it is done 
- with it.  A disable/enable fixes it, but I'd like to just modify my dialTBIT
- routine to give the getty a little nudge when it is done with it to wake it
- back up.  I have had moderate success sending the getty a SIGTERM, but I was
- wondering if there was a proper way of initializing the getty without having
- to disable and re-enable it.
- -- 
- Rasmus Lerdorf {lsuc,utzoo,mnetor}!dciem!nttor!rasmus |I'd rather be in Denmark
- Northern Telecom, Toronto, Canada. (416)597-2090x2505 |SD Eng Waterloo '93

I had this problem when I went from 2.2.3 to 2.3.2 also.  After dialout
via uucp or cu, getty calls the dialer program for that line with the -h
option (for hangup).  The problem is when dialTBIT is called with the -h
option it fails to put the modem in verbose mode before sending the
hangup string (MDHANGUP), consequently it never gets the OK string back
and returns an error status to getty which doesn't restart.
If you have process accounting turned on you can see that getty is
calling "dialTBIT -h" by running 'acctcom -b' just after a cu or
uucp call terminates.

You can fix this by modifying the hangup() function in dialTBIT to put
the modem in verbose mode before sending the hangup string, or just
set your modem up to always be in verbose mode.
--
Roger A. Cornelius           rac at sherpa            uunet!sherpa!rac