rasmus@nttor.uucp (Rasmus Lerdorf) (12/07/89)
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 '93rac@sherpa.uucp (Roger Cornelius) (12/09/89)
From article <1989Dec7.090500.6426@nttor.uucp>, by rasmus@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@sherpa uunet!sherpa!rac