I agree that systems should be well-adminstered,  I also prefer programs that don't run amok even when there are lapses in administration.

Since detecting which file caused the SIGFSZ is impractical, how about if we do this.
a) don't rotate logs on SIGFSZ if it's done it recently.
b) when it does rotate files on SIGFSZ,. it should rotate the csv file, too, and any other files that are written to (maybe only of they are larger than the file size limit)

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.
  
_______________________________________________
--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

Reply via email to