powered by Jive Software

Admin-console.log grows dangerously fast

I recently had a configuration error regarding SSL, probably my own fault but that’'s beside the point right now.

This error flooded the admin-console.log with about 1Megabyte per second! Within 20 seconds the log-file was too big to be opened by most text-editors. Within a few hours (I hadn’'t noticed the error at first) parts of the server started to act weird. The admin-console.log file had become nearly 4GB and filled up the entire harddrive making it impossible for other deamons to have any temp storage, crippling all sorts of other functions this server has.

Wouldn’‘t it be wise to use some kind of circular logging making sure that (by default) logs don’‘t grow over 5MB (or any other sane amount that’'s still readable by common text-editors)? Furthermore, why not have continuous errors reported in the log once a minute, instead of 20 identical error-messages consisting of 10 lines each being written every second.

For the moment I’‘ve shut down Wildfire-server all-together because I’'m afraid the tiniest error might bring half the server down.

It won’‘t be hard to implement I can imagine and certainly wouldn’‘t hurt. What point is there in having a logfile that’‘s so big it can’'t be read?

Hi,

it shouldn’'t make any big difference if you have 1000* 4 MB log files or one with 4 GB, disc / partition full is usually the result.

In my opinion you have a risky server installation which has nearly nothing to do with Wildfire. I use a filesystem with 128 MB for it, you could also use quotas to limit the disk usage in the wildfireHome/logs directory, so you can run it again.

Is it possible that you post how one must configure SSL to reproduce this problem, the developers would be very glad to fix this problem

Looking at the code it should be possible to rotate the files either by size or by time but I have no idea how to configure this.

LG

Hi,

Thanks for answering.

I’‘m not suggesting to just start a new logfile after the previous one has reached a max size. It wouldn’‘t help a bit, I agree. I’'m suggesting to simply overwrite the oldest events in the logfiles when a max size is reached. That way there is always one admin-console.log and it never exceeds a certain size.

Apart from circular logging I think it’'s of no use to write huge amounts of error-data 50 times a second at a speed no human being is able to read. Continuous errors might just as well apear once a minute, as a reminder. Once on first occurence and then every minute, or perhaps half a minute.

By the way, the error is the well-known:

19:35:22.100 WARN!! [Acceptor [SSL: ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=9091]]] org.mortbay.util.ThreadedServer.acceptSocket(ThreadedServer.java:449) >02> EXCEPTION

javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.

at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(Unknown Source)

at org.mortbay.util.ThreadedServer.acceptSocket(ThreadedServer.java:423)

at org.mortbay.util.ThreadedServer$Acceptor.run(ThreadedServer.java:608)

It’'s due to a SSL configuration error. This piece of data is repeated in the logfile with insane frequency. Imagine a logfile of 4GB containing just this error repeated over and over again. :smiley:

I had this happen to me too. During my initial attempts to configure my new wildfire server, I didn’‘t have the faintest clue about getting SSL correct. And I wasn’‘t paying attenting to the MULTIPLE MEGABYTE SSL log that was created. It ended up killing my backups (not wildfire’‘s problem - but I didn’'t quite expect a nutty admin-console.log to be that large).

Something should probably be fixed here