alexis@panix.uucp (Alexis Rosen) (11/16/90)
For reasons unrelated to the problem with talk, we rebooted the system.
All of a sudden, inet.d and portmap decided they were going to work. Great.
I've rebooted the system five or six times in the last few weeks (because of
the modem troubles), why did they pick _now_ to work?
Unfortunately, talk is _still_ not working. I don't know why. It now starts
up and says something about checking for invitations on _caller's_ host.
But I am the caller, and there's only one host, this one. Of course, I can
wait forever, and it won't connect with the person I'm trying to talk to.
What's going on???
Thanks in advance (I'm being optimistic...)
---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
{cmcl2,apple}!panix!alexissteveg@ni.umd.edu (Steve Green) (11/16/90)
In article <1990Nov16.040912.16092@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >For reasons unrelated to the problem with talk, we rebooted the system. >[...] >Unfortunately, talk is _still_ not working. I don't know why. It now starts >up and says something about checking for invitations on _caller's_ host. >[...] Try removing /etc/utmp and re-logging in. I had/have similiar problems and that always seems to do it. From what I can tell, talk{d} uses utmp to figure out what tty you are on and if its munged, well, you know. -- Silica gel -- No not eat. steveg@ni.umd.edu -- Silica gel -- No not eat. steveg@ni.umd.edu
urlichs@smurf.sub.org (Matthias Urlichs) (11/17/90)
In comp.unix.aux, article <1990Nov16.040912.16092@panix.uucp>,
alexis@panix.uucp (Alexis Rosen) writes:
< For reasons unrelated to the problem with talk, we rebooted the system.
<
< All of a sudden, inet.d and portmap decided they were going to work. Great.
< I've rebooted the system five or six times in the last few weeks (because of
< the modem troubles), why did they pick _now_ to work?
<
< Unfortunately, talk is _still_ not working. I don't know why. It now starts
< up and says something about checking for invitations on _caller's_ host.
< But I am the caller, and there's only one host, this one. Of course, I can
< wait forever, and it won't connect with the person I'm trying to talk to.
On this machine (which has bnet and slip, but no ethernet card) it works...
Some random thoughts:
- Do ping, telnet, ftp, ... work?
- "_caller's_" is an alias for your machine in /etc/hosts ?
- When you boot your machine, are you using "launch -v" to watch the various
startup messages? Sometimes tthese say something interesting, but the
default is jsut the progress bar which doesn't really tell you anything.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/alexis@panix.uucp (Alexis Rosen) (12/02/90)
Well, I've figured this one out. Sort of, anyway. But the solution is bad.
The problem was that talk wouldn't work. Another missing feature (which I
didn't notice until I 'fixed' the problem) was that there was no notification
when mail was received (shells would tell you, but that's different).
The fix was to edit the /etc/hosts file, and put my system's name ("panix")
on the first line, before the loopback names, as follows:
0x7F.0x00.0x00.0x01 panix loop localhost
Now this looks very suspect to me. Why can't I just add another line after
the loopback line, like this?
223.1.1.1 panix
... or something like that? When I do that instead, nothing works. The name
_must_ be in the loopback line, or so it seems.
Is it in fact correct for this name to be there? If not, how can I make things
work?
Thanks,
---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
{cmcl2,apple}!panix!alexis