[bedevtalk] Zeta trouble

[Raymond C. Rodgers]

Mark Hellegers wrote:
> Hi all,
>
> I hope someone is still subscribed that can help me with this annoying
> problem.
> I have a small website running on a Zeta 1.2 computer.
> Every now and then the webserver stops responding to http requests.
> I can ssh into the machine, but immediately get a message: "Killed (by
> death)".
> After this message I am still logged in and can do ls commands and such
> stuff.
> I can also do ps to see what is running, but I can't see anything strange.
> Attempts to run most programs from the ssh shell result in the "Killed (by
> death)" message.
> Shutting down the webserver software and the postgresql database also
> don't help with the problem.
> An attempt to reboot the machine causes it to hang and I can only get it
> running again by hitting the reset switch on the machine.
>
> Is there a way to see if Zeta is running out of resources and to see which
> application or part of the operating system is causing this ?
>
> Thanks for any help,
>
> Mark
>
>   
Imagine finding you here.. :-) Although my days of being a BeOS expert 
are long gone and I never had a copy of Zeta, it sounds like either an 
out of memory error (due to a memory leak most likely) or a trip to KDL. 
I've noticed that somethings will continue to run and respond normally 
after a KDL, or at least they think they're running normally. I'd bet on 
the out of memory error though.

Try this: type the following in a terminal window or in a telnet session 
before running the web server and postgresql.

export NEW_LEAK_CHECK=1
export MALLOC_LEAK_CHECK=1

That should turn on the memory leak detection. Then start the web server 
and postgresql from that terminal. Let them run for a while, then shut 
them down separately. If there's a memory leak, you'll be able to 
determine it from the output. It'll indicate the number of memory 
allocations and the type (new/malloc) and a list of stack traces that 
should help you identify where the memory was allocated, and potentially 
where it should be freed. You can pop the addresses into a certain 
dialog in bdb to take a peek. Of course, this is only useful if you have 
the sources for the web server and postgresql, but it might help. It 
might not though, because there are/were some memory leaks in BeOS 
itself, and I'm sure inherited by Zeta...

Raymond

(Below is a copy of the output from the NEW_LEAK_CHECK for the Network 
preference on BeOS Max.)
$ app exiting, final list:
17 current new allocations, 7302 bytes, sorted by count: ------------
call: 8000d6c1, 8000d837, 8000d535, 1 calls, size 104
call: 80010828, 8000f489, 8000da83, 8000d729, 8000d837, 8000d535, 1 
calls, size 4
call: 80012464, 80010873, 8000f489, 8000da83, 8000d729, 8000d837, 
8000d535, 1 calls, size 60
call: 80012b9c, 8000f53b, 8000da83, 8000d729, 8000d837, 8000d535, 1 
calls, size 4
call: 8001c307, 8001d304, 8000da27, 8000d729, 8000d837, 8000d535, 1 
calls, size 3586
call: 8001d2f6, 8000da27, 8000d729, 8000d837, 8000d535, 1 calls, size 3104
call: 8001d9cb, 8001c515, 8001d304, 8000da27, 8000d729, 8000d837, 
8000d535, 1 calls, size 8
call: ea09b46a, 8001953a, 8000da40, 8000d729, 8000d837, 8000d535, 1 
calls, size 12
call: ea0a631a, 800196c1, 8000da40, 8000d729, 8000d837, 8000d535, 1 
calls, size 4
call: ea288d03, 8001932f, 8000da40, 8000d729, 8000d837, 8000d535, 1 
calls, size 16
call: ec161eb2, ec15d7c4, ec15e2de, ec1623e4, 8000d679, 8000d837, 
8000d535, 1 calls, size 16
call: ec18333e, ec162655, ec15d58b, ec15c858, ec083eae, ec08427a, 
8000d52a, 1 calls, size 60
call: ec1b0aba, ec15d819, ec15e2de, ec1623e4, 8000d679, 8000d837, 
8000d535, 1 calls, size 20
call: ec1b0b3a, ec15d819, ec15e2de, ec1623e4, 8000d679, 8000d837, 
8000d535, 1 calls, size 76
call: ec1b0bc3, ec15d819, ec15e2de, ec1623e4, 8000d679, 8000d837, 
8000d535, 1 calls, size 76
call: ec1b0c57, ec15d819, ec15e2de, ec1623e4, 8000d679, 8000d837, 
8000d535, 1 calls, size 76
call: ec1b0ce1, ec15d819, ec15e2de, ec1623e4, 8000d679, 8000d837, 
8000d535, 1 calls, size 76