|
|
| Author |
Message |
| 25 new of 162 responses total. |
janc
|
|
response 4 of 162:
| 
Jun 24 18:25 UTC 1999 |
No, helpers has been around a long time. It isn't very active.
I've put resp:1 into my TODO list for Backtalk. Unfortunately, I don't
have much time for Backtalk work just now.
|
kaplan
|
|
response 5 of 162:
|
Jun 27 16:34 UTC 1999 |
Helpers is the meeting place for the volunteers who take "write help"
requests.
|
keesan
|
|
response 6 of 162:
|
Jul 7 18:07 UTC 1999 |
I have noticed grex slowing down a lot since Sunday. Sunday I got a chat
request from someone at IIT KGP (Karaghpur, East Bengal) who said he could
not use grex for six months but it was working again. He has free email at
mailcity.com now. He asked me why he had until recently been getting a
message about being disconnected when he tried to access grex. Grex is still
accessible for him today, he is happy about this. Could the influx of IIT
students suddenly rediscovering grex be affecting speed?
|
janc
|
|
response 7 of 162:
|
Jul 8 16:36 UTC 1999 |
I doubt it. Mostly if Grex is slow it is because someone is running a
fork bomb or mail bomb or some other stupid thing.
|
jazz
|
|
response 8 of 162:
|
Jul 9 16:29 UTC 1999 |
Phenomenologically, yes, it could, but not for local users (to as great
of a degree; it has some impact on the system load obviously and ususally
adds a number of users to the telnet wait queue). If a number of people from
N site telnet to X site, and N site's bandwidth is limited, it can certainly
affect speed. A web-based interface is not as sensitive to slow speeds as
a telnet-based interface, and under many circumstances a telnet-based inerface
can consume significantly more bandwidth.
|
richard
|
|
response 9 of 162:
|
Jul 12 23:01 UTC 1999 |
Whats the problem with /a? grex isnt allowing normal logins at the
moment and the only way to get here seems to be via backtalk......
|
janc
|
|
response 10 of 162:
|
Jul 13 15:23 UTC 1999 |
The /a disk drive croaked. It's been replaced with a new disk, and
files have been restored, but I don't know the details.
|
krj
|
|
response 11 of 162:
|
Jul 14 02:43 UTC 1999 |
There are persistent reports that dialins are intermittently not working.
I just got one from russ, who talk-d me from M-net.
|
aruba
|
|
response 12 of 162:
|
Jul 14 05:56 UTC 1999 |
The dialins are working for me, but they're taking four rings to pick up
instead of the usual 1. No doubt this is playing havoc with some people's
scripts which have short timeout periods.
|
i
|
|
response 13 of 162:
|
Jul 14 10:24 UTC 1999 |
I'm seeing extra rings at -3000, but only one further up the trunk hunt.
My guess is that one of the modems isn't answering.
|
scott
|
|
response 14 of 162:
|
Jul 14 11:02 UTC 1999 |
I'll have to check out -3000, I guess. But the phone system does forward
after 3 rings to the next line, so no big problem.
|
senna
|
|
response 15 of 162:
|
Jul 14 14:36 UTC 1999 |
Took me three tries to get backtalk to start reading agora, which
started with this item.
|
richard
|
|
response 16 of 162:
|
Jul 14 21:10 UTC 1999 |
how come picospan seems to cut off one-line responses? often, when
someone does a one line response, picospan skips the text, and I have to
pull the item up in backtalk to read it
|
scott
|
|
response 17 of 162:
|
Jul 14 21:11 UTC 1999 |
That's usually a settings issue on your terminal.
(epadding to make more than one line)
|
tpryan
|
|
response 18 of 162:
|
Jul 14 21:52 UTC 1999 |
It just took four rings to get the terminal server to answer the phone.
|
scott
|
|
response 19 of 162:
|
Jul 14 22:46 UTC 1999 |
Yes, 761-3000 is not answering so it bumps up the hunt after 3 rings. I'm
going to be dropping by the Pumpkin this evening to check it out.
|
lowclass
|
|
response 20 of 162:
|
Jul 15 13:51 UTC 1999 |
As of 9:40 am, the 761-3000 modem seemed to pick up quickly.
(course this early in the morning, I might have dosed off between
rings..)
|
drew
|
|
response 21 of 162:
|
Jul 19 18:12 UTC 1999 |
On logging in, the message "Vfork failed" appeared. What does this mean?
|
mcnally
|
|
response 22 of 162:
|
Jul 19 18:43 UTC 1999 |
It means that the system vfork() call failed and whatever was trying to
do it reported the error to you.
vfork is one of a family of system calls that create new processes --
for example the system login program creates a shell process for you
when you log in. the most common reason why vfork might fail is if
the system is "out" of processes (simultaneous running processes are a
finite resource on Unix systems, you can only have so many at once.)
usually this occurs when either (a) some jerk is running a "fork bomb"
to deliberately use up processes, or (b) when the system has been
running for a very long time and processes have "leaked" for some
reason (i.e. processes that end for some reason haven't been returned
to the pool of free process ids available and eventually they all get
used up..) usually a reboot is needed to fix problem (b).
|
drew
|
|
response 23 of 162:
|
Jul 20 20:55 UTC 1999 |
The system did continue to function normally after that, so both (a) and (b)
seem implausible. Maybe there was just unusually heavy traffic at that time?
|
arund
|
|
response 24 of 162:
|
Jul 28 12:34 UTC 1999 |
pass.
|
nestene
|
|
response 25 of 162:
|
Jul 29 09:36 UTC 1999 |
I've been having trouble trying to dial in on 761-3000 these last few weeks.
Usually, things hang after I'm told it might take a few seconds to connect,
but today I didn't get anything after my modem's CONNECT notice. As usual,
dialing in on 761-3411 worked perfectly.
|
e4808mc
|
|
response 26 of 162:
|
Jul 29 14:29 UTC 1999 |
Same problem this morning. 3000 hangs there without giving me the few seconds
to connect notice.
|
scott
|
|
response 27 of 162:
|
Jul 29 16:05 UTC 1999 |
I think we may have a futzy terminal server port.
|
aruba
|
|
response 28 of 162:
|
Jul 29 16:42 UTC 1999 |
I couldn't get in on 3000 or 5041 today.
|
