This item is for system problems.  If something on Grex isn't working 
right (line noise on a modem, weird behavior from a program, etc.), 
this is the place to announce it.  Except for security holes.  If you 
find a hole in system security, mail information about it to "staff".

162 responses total.

I consider it a Backtalk "bug" that it doesn't show you "response"
zero when you ask (from the item menu) to read new responses, and
some new items only have response 0.

Agora 4 linked as Helpers 82.

Helpers?  Is that a new Conf?

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.

Helpers is the meeting place for the volunteers who take "write help"
requests.

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?

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.

        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.

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......

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.

There are persistent reports that dialins are intermittently not working.
I just got one from russ, who talk-d me from M-net.

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'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.

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.

Took me three tries to get backtalk to start reading agora, which 
started with this item.

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

That's usually a settings issue on your terminal.  
(epadding to make more than one line)

        It just took four rings to get the terminal server to answer the phone.

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.

        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..)

On logging in, the message "Vfork failed" appeared. What does this mean?

  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).

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?

pass.

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.

Same problem this morning.  3000 hangs there without giving me the few seconds
to connect notice.  

I think we may have a futzy terminal server port.

I couldn't get in on 3000 or 5041 today.

I can't get 761-3000 to work today.                    
Last night, in party, dea said that he had to hunt around a bit to find
a working phone line on Grex.

Same problem yesterday and today.  We thought it was in the computer, tried
three different modems, two com ports, a new version of Procomm, and then
another computer.  Glad to know it is not at our end.

I dinked around with the terminal zerver this afternonn, but couldn't find
anything really wrong.  I power-cycled a few modems and left it for now.  I
dial in enough to notice any problems...

        Problem persists.  And I thought you where practiceing shutting down
early.

Ah well. back to the salt mines...

I was not able to get in on 761-3000 just now, but 761-5041 got me in.

Took me several tries at 761-3000, but eventually it worked.

I couldn't get in on 300 or 5041 tonight, but 3411 worked.  So I'm betting
it's the 5041 port that has a problem.

the idle buster doesn't seem to be working..

Last night Grace tried to log in, from home (dialin).  Connected to the modem,
no further response.  I've now tried; I've been connected to the modem for
over 15 minutes with no response.   Possibly from this fact it would be
possible to deduce which modem is to blame.  (From work I can telnet in, so
as to enter this.)

Telling which modem is the culprit is a lot harder than it used to be.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss