OS X Private Folder - Runaway file "crash recovery" 126.61GB!

Woke up this morning any my 250GB, which had approx. 50% free space last night, was totally out of disk space!

Took me all day, but finally found a file in /private/var/audit/ called "20110423020458.crash_recovery" that is 126.61GBytes!

I've tried running daily/weekly/monthly via Onyx. Running most all the cache cleaning scripts. Used Techtool, the DiskWarrior. Finally went to SnowLeopard Cache Cleaner and Applejack deep cleaning.

Nothing got rid of it. Only reason I eventually found the file at all is that it showed up in DaisyDisk (it didn't in other mappers).

Question is => is it safe top delete /private/var/audit/20110423020458.crash_recovery ?

I know there is various Unix core stuff in /private, but that is about the limit of my knowledge there. I've got all manner of good backups (CCL, Time Machine, Dropbox) – so I'm not as worried about data loss as I am jsut anxious to get my system back (everything working normal except disk space issued...booted from external drive and deleted 5GB to make some breathing room).

Thanks for any advice / tips in advance! - Larry

(System: MBP Late 2010 Unibody, 8GB RAM, 250GB HD, OS 10.6.7)

Yes. You have enabled auditing somewhere along the line, being a wise person, but you have not trimmed the file, being a human, like I. Note the instant edit ;)

man -k audit

if you can get a shell will show you where you need to go

( look at them on the apple dev site )

i think here you want

audit -e 

to get rid of your old audit files.

From the man page:

The audit utility controls the state of the audit system. One of the following flags is required as an argument to audit:

 -e      Forces the audit system to immediately remove audit log files
         that meet the expiration criteria specified in the audit control
         file without doing a log rotation.

 -i      Initializes and starts auditing.  This option is currently for
         Mac OS X only and requires auditd(8) to be configured to run
         under launchd(8).

 -n      Forces the audit system to close the existing audit log file and
         rotate to a new log file in a location specified in the audit
         control file.  Also, audit log files that meet the expiration
         criteria specified in the audit control file will be removed.

 -s      Specifies that the audit system should [re]synchronize its con-
         figuration from the audit control file.  A new log file will be
         created.

 -t      Specifies that the audit system should terminate.  Log files are
         closed and renamed to indicate the time of the shutdown.

On my system:

ls /var/audit
20110414160828.20110415024057 20110420155533.20110421134946
20110415024148.20110416200834 20110421140348.20110421151928
20110416200951.20110417013744 20110421152018.20110422125418
20110417014358.crash_recovery 20110422125606.20110422205003
20110417024720.20110417120347 20110422205003.20110423102007
20110417135346.20110419142539 20110423102114.20110423204207
20110419144659.20110419150605 20110423204320.20110424094847
20110419150626.20110419201121 20110424094940.not_terminated
20110419201223.20110419225009 build
20110419225100.20110420153215 current
[root:8va:0:~ ]# du -h /var/audit
4.0K    /var/audit/build
6.0M    /var/audit

Yes. It's audit -e

[root:8va:0:~ ]# audit -e
Trigger sent.
[root:8va:0:~ ]# du -h /var/audit
4.0K    /var/audit/build
6.0M    /var/audit