|
|
| Author |
Message |
| 25 new of 222 responses total. |
hhsrat
|
|
response 25 of 222:
| 
Apr 24 22:59 UTC 2000 |
I had a rather unusual occurance with BackTalk today. I tried to
connect at www.cyberspace.org/cgi-bin/bt and it timed out. When I tried
www.grex.org/cgi-bin/bt everything worked fine.
|
jp2
|
|
response 26 of 222:
|
Apr 25 14:51 UTC 2000 |
This response has been erased.
|
otaking
|
|
response 27 of 222:
|
Apr 25 15:06 UTC 2000 |
I hit CNTL-X to send an e-mail, only to get the message "illegal command: core
dumped" The system froze until I exited out of the program entirely.
|
janc
|
|
response 28 of 222:
|
Apr 26 01:00 UTC 2000 |
I don't think there is any difference between the names 'grex.org' and
'cyberspace.org'. There may be some weird situations where Backtalk is
temporarily slow in responding (due to a locked file or some such).
This is especially likely when the load on Grex is high.
|
hematite
|
|
response 29 of 222:
|
Apr 28 16:57 UTC 2000 |
Is ther any particular reason why in the middle of reading Agora through
backtalk that I can't get into backtalk at all? I was halfway done when I
was asked for my password, after typing it in a half a dozen times it
still won't let me connect and now I'm logged in through telnet, which is
working fine. Help?
|
krj
|
|
response 30 of 222:
|
Apr 28 17:40 UTC 2000 |
/var is full, bringing party to a complete halt.
|
jor
|
|
response 31 of 222:
|
Apr 28 17:42 UTC 2000 |
confirmed, not that confirmation was needed
|
drew
|
|
response 32 of 222:
|
Apr 28 19:53 UTC 2000 |
Party is complaining that /var is full. (/var/spool/mail is a separate
partition, and thus not to blame.)
|
krj
|
|
response 33 of 222:
|
Apr 28 20:33 UTC 2000 |
/var got better for a little while but it is full again.
|
scott
|
|
response 34 of 222:
|
Apr 28 22:01 UTC 2000 |
Wish I knew what was filling it up. :(
|
krj
|
|
response 35 of 222:
|
Apr 28 22:16 UTC 2000 |
/var has gone this afternoon from 100%, down a little bit, then up
to 103% and now 105%.
|
krj
|
|
response 36 of 222:
|
Apr 29 18:22 UTC 2000 |
Today's problem is that telnet connections are being very unstable.
See the party log over the last hour to read lots of people, from
different ISPs, whining about being dropped or having connections
freeze.
|
atticus
|
|
response 37 of 222:
|
Apr 30 14:14 UTC 2000 |
Re #29: The same thing happened to me too; a couple of times in the last
few days.
|
jor
|
|
response 38 of 222:
|
May 1 18:12 UTC 2000 |
something very funny is going on.
there seems to be no lag at all.
well that's an exaggeration but still.
this is very unusual.
|
janc
|
|
response 39 of 222:
|
May 7 04:13 UTC 2000 |
I think /var/log/bt_crash.log is filling it up. Backtalk seems to be
crashing a lot. I've turned off logging of this for a bit, but haven't
removed the last file put there, because I need time to analyze it some
more.
|
hematite
|
|
response 40 of 222:
|
May 8 02:56 UTC 2000 |
Backtalk has been crashing for me at least twice daily. I'm logged into Grex
now cause it crashed in the middle of my reading one of the conferences...
|
bdh3
|
|
response 41 of 222:
|
May 8 09:45 UTC 2000 |
Hmm, I have never had any problem using 'backtalk'. Wonder if it is
because I use it using netscape either running on AIX or Linux?
|
scg
|
|
response 42 of 222:
|
May 8 17:56 UTC 2000 |
If Backtalk itself were crashing, you would be able to hit the back button
and try again, since Backtalk is a program that is run every time you fetch
a Backtalk webpage. It sounds like Wendy is talking about her browser
crashing instead. This could be Backtalk sending it something it can't
handle, but it's more likely to be a problem with the browser installation
on Wendy's computer.
|
atticus
|
|
response 43 of 222:
|
May 8 19:12 UTC 2000 |
What is happening in my case is that the browser gives an "Authorization
failed. Retry?" message. The retry never succeeds. (The first time it
happened, I even suspected that someone had broken into my account and
changed the password. But I was able to login via telnet just fine.) I
don't think the problem lies with the browser.
|
hematite
|
|
response 44 of 222:
|
May 8 19:21 UTC 2000 |
(That's what I thought the first time it happened to me too, Sreeni)
That's what happens to me, it keeps asking and asking for my password
but won't accept it then says Authorization failed, won't let me go
back to a previous backtalk page either. If I telnet in, I can read
agora fine.
|
scg
|
|
response 45 of 222:
|
May 8 19:39 UTC 2000 |
What happens if you close and restart your browser?
|
cmcgee
|
|
response 46 of 222:
|
May 8 21:23 UTC 2000 |
I've had trouble today logging in to engin.umich.edu. I get Trying xxx.xxx.
then I get "Connecting to maize.engin.umich.edu
then I get "Escape is ^]"
then I get "Connection closed by remote system
CAEN tells me its a problem at the Grex end. However I can telnet to
login.itd.umich.edu with no problem, and can telnet from there to
login.engin.umich.edu
anybody have any clues about what to look for or how to solve this?
|
other
|
|
response 47 of 222:
|
May 8 21:32 UTC 2000 |
I had the same authorization failure problem with Backtalk yesterday.
Jan reported an unusually high crash frequency with BT lately, and that
being the cause of /var filling up.
Those problems are apparently all fixed now.
|
hhsrat
|
|
response 48 of 222:
|
May 8 21:36 UTC 2000 |
I've had no backtalk problems recently, although it has been seeming
slower than usual. This could be due to high loads, when I telnetted in
today it also seemed slow. One problem was that I got put into the
telnet queue, when there were plenty of open ports - "56 remote users +
3 local users. 72 max remote users" It took me 5 minutes from that
point to get to a login prompt.
|
janc
|
|
response 49 of 222:
|
May 8 22:03 UTC 2000 |
Actually, the backtalk crashes that were filling up the log turned out
not to be exactly crashes. Something was killing backtalk processes,
and when the bullet hit backtalk, it reacted by logging a crash. I'm
pretty sure that the shooter was the http server (Apache). I'm guessing
that when people hit 'stop' button while loading the page, Apache kills
backtalk, since nobody wants to see the output. Since this is perfectly
OK, I taught backtalk not to log this as a crash.
The Backtalk login box is actually a completely separate program from
Backtalk (the web version of the vote program uses it too). The
failures with that are different. I dug through today's log file and
found a bunch of failures for user hematite. These failed because the
http server could not fork a new process for the authenticator to run
in. Probable we were running out of processes. I think the last time I
upgraded apache, I left the process limits at the default settings, but
they probably need to be scaled back to because of the tight process
limits that we set here to keep fork-bombers from running.
Hmmm...I wonder if what was killing backtalk processes was not the
httpd, but the kernel noticing that user 'nobody' had more than 32
processes and deciding that Apache was a fork bomb. I think it then
kills everything. The root Apache runs as root, so it would be immune.
Don't know.
Anyway, I've scaled back Apache's limits on child processes to the
values we had in the previously installed version of Apache. Maybe
things will be better now. Let me know.
|
