earle@POSEUR.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) (10/19/90)
A customer here complained that `talk' wasn't working right. On further investigation, it appeared that the problem was because `talk' got confused by old, dead /etc/utmp entries for the user he was attempting to `talk' to. The user in question uses X11 R4, with mwm, a few xterms, etc. etc. These entries were left by one or more xterms. (This is X11 R4; all 18 fixes) I asked how he enters/exits X, and I found out that everything is starting up in the background, with the window manager started last. To exit X, he simply quits the window manager. What we noted was the following: each running xterm received a SIGHUP when the window manager was exited, and the system started to come down (i.e. their .xinitrc equivalent completed, xinit finishes etc.). At this time, the xterms try to do some sort of 160 character read and write. The case we watched was interesting: one of the xterms successfully completed this 160 character read() and write(). The other two did not (one appeared to be writing a message to `syslog'; the other one appeared to be trying to render the shell prompt); each one got EPIPE on the write(). These were both almost instantly thereafter followed by the xterm getting SIGPIPE and stopping dead in its tracks, thus preventing it from cleaning up the pty's and removing the utmp entry like a good dog. Thus causing the utmp leftovers which caused `talk' indigestion. This seems like something really fundamental here. Am I stating the obvious, is it simply the case that `xterm' is unprepared to handle receiving a SIGPIPE (I still don't know the exact reasons why), and thus it dies instantly because it does not catch it? (SunOS `trace(1)' style outputs available upon request) -- - Greg Earle | "This is Kraft. It uses a blue box. Sun Microsystems, Los Angeles | This is Stouffer's. It uses red. JPL on-site Software Support | The choice is yours." earle@poseur.JPL.NASA.GOV | Pretty damn convincing argument, eh?