Bug#301883: asterisk: sqlite logging enabled by default and never rotated

John Goerzen John Goerzen <jgoerzen@complete.org>, 301883@bugs.debian.org
Thu, 31 Mar 2005 08:15:46 -0600


On Thu, Mar 31, 2005 at 10:04:08AM +0200, Kilian Krause wrote:
> Am Donnerstag, den 31.03.2005, 00:07 +0200 schrieb Jose Carlos Garcia
> Sogo:
> >  Well, the main problem I see is how can this be made without the need
> > of stopping asterisk and restarting it again, as it is an sqlite file
> > instead of a usual plain file.
> > 
> >  We will have the same problem with cdr_mysql, if ever packaged.
> 
> ...but in that case rotation would be part of MySQL's problem, not ours.
> We just interface with MySQL in that mode and stuff our data into its
> API. 

... but only if it is not enabled by default!  If it is enabled by
default, I submit that it's your responsibility to rotate the logfiles,
regardless of whether they're plain text or database.

> For the same reason, i'm not entirely sure how to use the SQLite wisely,
> for shutting down the entire live PBX only to rotate a cdr file sounds
> like overkill to me.

Couldn't you write a SQLite program that goes through and uses SQL
queries to accomplish this?

> Any comments why you need it rotated *automagically* in the first place?

Well, it will fill up /var eventually otherwise.

> Would you also rotate MySQL or PostgreSQL db files for the same reason
> that they *COULD* theoretically explode when stuffing enough CDR data
> into there?

If the package is logging to those places by default, then yes.  Policy
10.8 seems to agree with me, at least by my interpretation.

If you provide cdr_mysql, but it does not enable any CDR recording by
default (perhaps requiring some user configuration first), then I would
say that you, as cdr_mysql maintainer, don't have to worry about
rotating; if the user turns something on, it's the user's responsibility
to take care of that.

I just object to installing something that, out of the box, will fill up
my disk -- and which provides me with no good way to address that.

-- John