talkd goes wild

Jim Liu liu at pupphy.princeton.edu
Mon Jun 24 15:11:40 AEST 1991


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 at Phoenix.princeton.edu



More information about the Comp.sys.sgi mailing list