Re: [Asterisk-Users] asterisk logger - urgent!!!

[Warren Burstein]

Kevin P. Fleming wrote:
> Dov Bigio wrote:
>
>> Any way, if any developers are reading this, I don't think that rotating
>> asterisk logs is the best way to handle this problem!
>> Maybe a more user-friendly message could be logged, infoming which file
>> reached the 2.0GB.
>>
>
> Unfortunately when we receive SIGFSZ from the kernel, we have no way to
> know which file caused it. The assumption in Asterisk is that the only
> files we write to that will ever reach that size are log files. If any
> other file does, there will be trouble, as you have seen.
>
How about if it would set a global variable before each disk write so
the SIGFSZ handler would know which file caused it?
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

[Kevin P. Fleming]

Warren Burstein wrote:

> How about if it would set a global variable before each disk write so
> the SIGFSZ handler would know which file caused it?

Ha!

Signals are asynchronous. This global variable would to be
lock-protected, would require copying (possibly long) paths for every
write, and would not necessarily be correct when the signal arrived.

Sorry, this is not a solution. There is no solution, other than paying
attention to your server and making sure that files don't get
ridiculously large.

[Bob Goddard]

On Saturday 11 Feb 2006 00:10, Kevin P. Fleming wrote:
> Warren Burstein wrote:
> > How about if it would set a global variable before each disk write so
> > the SIGFSZ handler would know which file caused it?
>
> Ha!
>
> Signals are asynchronous. This global variable would to be
> lock-protected, would require copying (possibly long) paths for every
> write, and would not necessarily be correct when the signal arrived.
>
> Sorry, this is not a solution. There is no solution, other than paying
> attention to your server and making sure that files don't get
> ridiculously large.

Well, you seem to have totally ignore what I said.

Using fopen/fputs to ONLY append to a file, is quite frankly, stupid.
Change it to open/write and you will be able to trap via the write
return code and errno.

B

--
http://www.mailtrap.org.uk/

[Kevin P. Fleming]

Bob Goddard wrote:

> Using fopen/fputs to ONLY append to a file, is quite frankly, stupid.
> Change it to open/write and you will be able to trap via the write
> return code and errno.

Patches to fix bugs are most welcome. Given that these files are written
using fprintf (because they are using format strings and long lists of
arguments), using write will require allocating memory, building the
output there and then calling write(). Seems like an awful lot of work
to avoid a simple system administration failure.

[Michael Collins]

Perhaps there's a happy medium: sprintf()?

I am curious to know if putting the output into a char array with
sprintf() (to preserve the output formatting) and then writing it with
write(). How much additional overhead would this take? Hard to know
without trying it.

Is anyone in a position to write some test code that would do this and
report back the results?

-MC