UNIX for Dummies Questions & Answers

In our shop, we have a situation where a log file from our interface engine software has begun maxing out in file size (reaching the 32-bit "2147483647" limit). Currently, the only way to rectify this is to stop the interface and restart it, which generates a new log. Easy enough, but the interface is for a medical facility - so intermittent stops/starts is highly discouraged. I've tried deleting contents of the file (after first backing it up) with various commands. Although I get what APPEARS to be an emptied file, it shows the same file size when moved back into the directory where it's written to. When viewing the log, there IS blank space up to the "new" log entries - but the file size remains the same - thus, defeating my intent. Is there any way to clear the log file, and revert it back to zero-size, without having to shut down this interface? I cannot create a new file; it is appended with a PID, which has to remain the same. Thanks for any help.

Which commands did you try to use to empty this file?

Try renaming the logs then sending SIGHUP to whatever daemon is writing to these files. If the daemon is well-behaved, SIGHUP should cause it to reopen its logfiles without restarting(you should see new files created), after which you can safely delete the old, renamed logfiles.

I used the "cat /dev/null > filename", and also tryed vi'ing the file and deleting contents with ":g/.*/d". Both seemed to work, inasmuch as deleting the contents; just won't get it back to a zero-size file (in the log's "live" environment). Thanks

Corona688 is right here. You will need to force the process to close and reopen the file.

When you redirect output onto the existing file (>logfile or cat /dev/null >logfile) you are causing the file to be unlinked from the filesystem, but if any processes still have an open file descriptor to the file, the disk space is not released and the process will continue to see the file that it has been using all along. This is why you see an empty file in the file system (reported by ls) but the space is still used (reported by du/df) and the application still has issues.

As others have posted, if the process is well-behaved, you should be able to rename the file then send it a SIGHUP and it should start using a new file. You might have to create the new log file using something like "touch" first, though.

If that doesn't work, the application is broken. Assuming you have an uptime requirement, the failure of the application to properly handle log files is causing it to fail to meet its uptime requirement. Make the developer fix it.

Because it's broke.

Just because the developer didn't THINK about the impact of of failing to manage log files doesn't mean it's OK to fail like that.

As mentionned above, moving your file will not solve your issue, another alternative if it works in your case would be to copy (not move!) the file elsewhere, then blanking the log file:

Code:

>logfile