Update of /export/home/ntop/ntop
In directory jabber:/tmp/cvs-serv10099
Modified Files:
address.c globals-defines.h globals-structtypes.h hash.c
http.c initialize.c leaks.c main.c ntop.c ntop_win32.c pbuf.c
reportUtils.c sessions.c util.c webInterface.c
Log Message:
Add ntop memory failure trap...
1. Convert myGlobals.capturePackets from binary to tri-state.
As a binary, ntop either captured packets or was in the process of terminating.
Once it termed, the data was lost.
Add ntop memory failure trap...
1. Convert myGlobals.capturePackets from binary to tri-state.
As a binary, ntop either captured packets or was in the process of terminating.
Once it termed, the data was lost.
As a tri-state, the settings are RUN, STOPCAP and TERM.
STOPCAP keeps the ntop web server up - with a message "Packet capture stopped" at
the top and bottom. This allows the user to view configuration and traffic data
then kill ntop cleanly through the "shutdown" option.
The transition from RUN -> STOPCAP occurs if the ntop memory allocation routines
detect a failure (i.e. out of memory). Log messages are issued (1st time only).
2. As part of this change, a number of key c|m|re allocs were adjusted to fail more
softly. The goal is to give the STOPCAP enough time to take affect, not to make
ntop more fault tollerant.
3. Note also that the rrd process keeps running through ONE more cycle, so that the
data from the prior cycle to the setting of STOPCAP is not lost.
4. The packet capture thread(s) will continue until the next packet. Address
resolution is not (at present) terminatable. It sits waiting for something
that will never come until the main process is shutdown.
5. --disable-stopcap returns ntop to the (unpredictable, bad, et al) behavior of old.
But heed this warning - just like before, if you run out of memory and get the
ERROR: allocation failed message - with --disable-stopcap set, ALL BETS ARE OFF.
ntop will probably crash in a horrible and spectacular way...
Also:
Remember that even with STOPCAP, ntop still wasn't able to allocate memory
it needs and things still could go badly wrong.
-----Burton (ref 189)
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
