Bug 2553 - ytalk doesn't work (hangs)
ytalk doesn't work (hangs)
Status: CLOSED DUPLICATE of bug 2799
Product: Red Hat Linux
Classification: Retired
Component: ytalk (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-05-05 00:02 EDT by xp
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-06-19 18:36:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description xp 1999-05-05 00:02:06 EDT
Problem:
After upgrading from RedHat 5.2 to 6.0, I found that ytalk
would allways hang and would not get any connection

Solution:
Uninstalling the talk package and installing the ntalk
package from RedHat 5.2 cured the problem for me. No changes
were needed to the ytalk package.
Comment 1 rhardy 1999-05-09 05:06:59 EDT
We had the same problem. We solved the problem by doing an rpm -e
ytalk, installing Redhat's SRPM, rebuilding the ytalk rpm with
rpm -bb and installing the new RPM.
Everything seems to work fine now.
Comment 2 rhardy 1999-05-10 16:24:59 EDT
I was incorrect in my previous statement. A recompile has no effect
on the hanging of ytalk. Both in.talkd and in.ntalkd seem to fight
over ytalk connections. Commenting out the in.talkd line and leaving
the in.ntalkd line active makes ytalk behave normally.
Comment 3 rhardy 1999-05-10 16:31:59 EDT
I thought I should reword my previous incomprehensible message...
When a ytalk process hangs, both a in.talkd and in.ntalk can be
observed running on the destination machine. The only way we could
stop ytalk from hanging was to comment out the in.talkd line in
inetd.conf (leaving in.ntalkd active).
Comment 4 Chris Evans 1999-05-14 09:23:59 EDT
I logged a duplicate bug yesterday..

Note that even when you disable in.talkd, and get it working through
in.ntalkd, there is still a bug. When a talk session terminates, the
in.ntalkd process is left hanging around. This also needs fixing.

The severity, "normal" sounds wrong to - the whole talk subsystem is
knadgered which is quite serious :-)
Comment 5 Alan Cox 1999-06-19 18:36:59 EDT
*** This bug has been marked as a duplicate of 2799 ***

Note You need to log in before you can comment on or make changes to this bug.