romain@pyrnj.uucp (Romain Kang) (04/16/87)
In article <6596@allegra.UUCP> mp@allegra.UUCP (Mark Plotnick) writes: | I suppose I could have uucico do a TIOCNOTTY before the exec of uuxqt. | It already looks like it's closing all its file descriptors. It seems to me that any children of a slave uucico need to be protected from hangups. For instance, when you set mandatory callback in USERFILE (or Permissions), your slave uucico waves goodbye to the master and tries to spawn a uucico to do the callback. However, there seems to be a window where your slave might catch the hangup before it reaches the exec; it logs some message like CAUGHT SIGNAL 1. I've seen related behavior when uuxqt spawns rmail on pyrnj. I have some systems set up as "local" uucp hosts in my sendmail.cf. Mail for them runs uux without the default "-r" flag, which in turn execs uucico in master role; 4.3 uucico then opens /dev/tty to do a TIOCNOTTY. This is a good idea; however, if the uuxqt was spawned as a child of a slave uucico, its controlling tty (and its descendants') may be a dialup where carrier is no longer present. Result: child uucico gets hung until someone else dials in (not a problem for BIG relay sites...) Evidently, it is desirable for uucico to detach its controlling tty before it execs anything, but where is the best place? On a heavily loaded system, it seems possible for the uucico to catch a hangup before it finishes the final handshake with the remote system. With the new generation of fast (>= 9600 bps) packetizing modems, this may become a more common scenario. Would it be harmful to TIOCNOTTY before the final OOOOOO handshake? (Or for non-BSD people, ignore SIGHUP?) -- Romain Kang {allegra,cmcl2,mirror,pyramid,rutgers}!pyrnj!romain Pyramid Technology Corp. / 10 Woodbridge Center. Dr / Woodbridge, NJ 07095 "Eggheads unite! You have nothing to lose but your yolks!" -Adlai Stevenson