[JDEV] Re: jabberd 1.4.2 chokes on its own log file

[Frank Seesink]

Sydney,

This is a replay to a 6 month old post of yours (I'm in a weird mood, 
going through the mailing list postings, and ran across this), so please 
ignore if you're already aware of this.

But in short, if you haven't seen it, please check this posting I wrote 
on 3 Nov 2003 regarding this very same subject (relevant info near end 
of post).  The URL to Gmane's Web-based version is here:

	http://article.gmane.org/gmane.network.jabber.devel/20441

and maqi's response:

	http://article.gmane.org/gmane.network.jabber.devel/20442

In short, this was a bug which was fixed in jabberd 1.4.3.  If you 
haven't already upgraded to jabberd2, or have reasons for staying with 
jabberd 1.4.x and are still running 1.4.2, I would strongly suggest 
upgrading to 1.4.3.


Sydney Weidman wrote:

> On Thu, 2003-07-31 at 10:11, Jamin W. Collins wrote:
> 
>>On Thu, Jul 31, 2003 at 12:13:09AM -0500, Sydney Weidman wrote:
>>
>>>/var/log/jabberd/error.log filesize: 2147483647 bytes.
>>>
>>>Jabberd filled this file up with a billion lines like this:
>>>
>>>[warn] (mio_ssl.c:225): SSL accept without an IP
>>>
>>>and then died from SIGXFSZ
>>>
>>>This is a terrific security feature :-)
>>>
>>>Have I missed a FAQ somewhere?
>>>
>>>I am trying to just run jabber on my local lan, so the server doesn't
>>>have a FQDN. Is that the problem?
>>>
>>>Out of ideas and disk space.
>>
>>You might want to take a look into _logrotate_.  I added a script to it
>>for the Debian Jabber package a while ago:
>>
>>   /var/log/jabber/*.log {
>>      rotate 5
>>      size=100k
>>      copytruncate
>>      delaycompress
>>      compress
>>   }
> 
> 
> Yes, thanks for the suggestion. I should set that up. But unfortunately,
> it wouldn't have helped because logrotate is normally run only daily
> from a cron job, while this log filled up in a matter of an hour or two.
> I had only just started the daemon when i was suddenly logged out of
> jabber and everything died.
> 
> Also, I am still curious why 
> 
> a) so many instances of this log message have to be written and 
> b) what the message actually means in terms of my configuration
> 
> I wonder if one could implement a 'speed limit' for writing to log
> files. I don't know if other programs have such things to prevent
> runaway operation. Perhaps this is better left to the operating system
> or corrected or managed by external utilities like logrotate.