YATES@c.chem.upenn.edu ("YATES, JOHN H.") (06/22/91)
A couple times a month I run out of process slots due to 20 or 30 copies of talkd being active. We run IRIX 3.3.1 , is there a bug in it so I should remove it from the system? Perhaps there is a known way novice users can "abuse" it? Worst case: some hacker has found a hole and ... Thanks, John yates@a.chem.upenn.edu
liu@pupphy.princeton.edu (Jim Liu) (06/24/91)
Yes, we've experienced the same problem with talkd running wild on our Iris 4D machine. I've traced the problem here to the way talkd notifies users that someone wants to talk to them. I haven't had too much time to study the problem since talk/talkd have now been disabled here. But I'm pretty sure I figured out what happens with talkd. Anyway, the problem we ran into seems to occur with the pseudo terminal interface and only involves the /dev/ttyq?? terminal lines. What talkd does when someone wants to talk is that it looks in utmp to find if the user is logged on and to see what terminal line he's on. Now, what apparantly happens is that the utmp file is corrupted (a pretty common occurence), so talkd finds a bogus entry corresponding to the user and this entry has a /dev/ttyq?? that is not being used (ie the master side is not open). Talkd then forks off a process whose sole purpose is to broadcast the message 'Message from Talk Daemon...' to the slave tty. Unfortunately, if the master side of the pty interface is not open, the open(2) of the slave tty blocks and the child then blocks forever. Finally, what must happen is that the person who's trying to talk to his friend doesn't get any response so he just lets his talk program ring his friend 30 or 40 times, thus causing talkd to spawn that many children.... So what's going on here? It's kind of a talkd bug, I guess, but it's also due to the unexpected behavior of the pseudo terminal interface in that the slave ttyq's hang upon open (for writing) if the master side is not open. What makes matters worse is that it seems impossible to open the corresponding master side since that control is not possible with the /dev/ptc interface. I guess the solution, then is to set an alarm clock in the talkd child to automatically kill itself if it hangs on the open or write to the terminal (the reason talkd even forks at all is that it doesn't want to acquire a controlling tty). It's probably just a one line change in the source. 'course, the solution here was to remove the problem - namely just disabling talkd. - Jim jtliu@Phoenix.princeton.edu