uugetty respawning

[Jean-Pierre Radley]

In article <1991May24.155552.19129 at candle.uucp> root at candle.uucp (Bruce Momjian) writes:
>
>I am using AT&T 386 Unix 3.1.  When cu and uucp use the modem, they respawn
>uugetty.  When Pcomm 1.2 uses the modem, it does not respawn uugetty, and 
>the next time someone tries to log in, they get a connect but no login prompt.
>
>To fix this, I currently run pcomm from a script, which also calls
>another script with set-uid to root and which executes:
>
>UUPID=`/bin/ps -ef |\
>	/bin/grep " *root.*uugetty[^x]*$" | \
>	/bin/sed 's/^.*root *\([0-9]*\).*$/\1/'`
>if [ "$UUPID" -gt "1" ]
>	then	/bin/kill $UUPID
>fi
>
>... which kills the uugetty ( I only have one uugetty running) and respawns. 
>Obviously, this is a kludge.  
>
>Does anyone know how cu and uucp respawn the uugetty properly, so I may add
>this to the pcomm source.  (BTW, is there a more recent pcomm than 1.2).


I don't know about AT&T Unix 3.1 I do know about SCO, and I just posted this
message in CompuServe's UnixForum:

In SCO Xenix 2.2, there is an ungetty program which can be called to suspend
a running getty; ungetty -r will then restart getty.
In SCO Xenix 2.3, the getty is like the uugetty in SCO Unix. For either of
those, sending the getty/uugetty SIGUSR1 will suspend it, and then sending it
a SIGUSR2 will zap it and cause a new getty/uugetty to start up.
This is the scheme implemented in xcmalt's xcport.c

Jean-Pierre Radley   Unix in NYC   jpr at jpr.com   jpradley!jpr   CIS: 72160,1341