On 1/7/09 11:47 AM, Mark Post wrote:
There are only a very few sparse files ever written to /var/log/. If space is a concern because they might get really big when being copied, then having logrotate compress them will solve that. The few sparse files I am aware of aren't kept open all the time, so copytruncate isn't necessary for them in the first place; they just get renamed.
I'm not sure the original poster logged to /var/log -- I was just suggesting a solution for an existing problem, not a general solution. Even so, logrotate is the process that created the sparse file in the first place, when using copytruncate, then subsequently un-sparsed it's own sparse files. I really hate reading billions of virtual \x00 for compression, much less the virtually-same virtual \x00 each time a new generation is compressed. Hence my solution with sparse log files of reading only non-sparse blocks (well, reading the first non-sparse block and subsequent blocks) and feeding them, sans leading \x00's, to bzip2. I think logrotate's copytruncate is a remedial solution at best, and if you were going to resort to logrotate anyway, you may as well use my method instead, until you implemented proper regular log closing and rotation. Or just say to hell with it and let daemon run forever, using my method always -- keeps disk space usage to a minimum, allows compression of old logs, and splitting of logs by date/time/size. - Larry ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
