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.

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?

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. 

response 45 of 222:

May 8 19:39 UTC 2000

What happens if you close and restart your browser?

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.

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.

response 51 of 222:

May 10 13:48 UTC 2000

I've also seen a lot of the "Authorization failed. Retry" thing.  Almost 
always, when I see this problem, I cannot log back in for a while.  If I 
wait an hour and then connect again using Backtalk, I can get in.

I said "almost always" because today, for the first time, when I was 
prompted to log in again, I was able to do so immediately.

response 53 of 222:

May 10 18:51 UTC 2000

Your cookies are getting eaten?

response 55 of 222:

May 11 04:28 UTC 2000

Backtalk doesn't use cookies.  It's not a hardware problem.

I got the internal server error from backtalk, and logged on and found that
yes, there were 32 processes running as user 'nobody'.  This means that the
http server, which runs as 'nobody' can't fork more processes, so it can't
run backtalk, or the password authenticator.

About a dozen of those processes were 'fingerd' proceses, mostly very old.
Fingerd also runs as 'nobody' but the processes shouldn't be hanging around
that long.  This is probably some bug in fingerd.  I was too lazy to try to
figure out what was causing it.  Instead I taught robocop (Grex's process
table police) to assassinate all fingerd processes that are more than 10
minutes old.  This should reduce the problem.

Better things to do would be:
 (1) Switch 'httpd' to run as some user other than nobody.  This is a good
     idea for various security reasons, but it is also a good idea because
     it would no longer be competing with any other program for processes
 (2) Make the pwauth authenticator into a daemon instead of running it
     every time we you hit a page.  This would improve performance, and it
     would be running as root, not 'nobody' so it would always be available.
Unfortunately, either of these projects requires me to do a lot of work.

Normal Unix systems allow users to have a lot more than 32 processes.  Grex
has it set low because we need to choke back fork bombs.

response 57 of 222:

May 11 14:33 UTC 2000

There's a little shareware out there called "cookie cutter" which you can use
to selectively delete cookies.  When I downloaded it you could use it free
for 10 times, and then have to pay for further use.  The only confusing thing
is that you mark what you want to save, insead of marking what you want to
delete.

response 59 of 222:

May 11 16:06 UTC 2000

Is MagicCookie the software that does this or is it called Locked?

response 61 of 222:

May 11 16:19 UTC 2000

MagicCookie is where Netscape stores cookies. One just locks that file
so nothing can be written to it (this is an OS option - no extra software).
I am, incidentally, running MacOs (and I gather sno is running Unix), but
something equivalent should be available on the DOS platform.