Summary: | logrotate loses log output if sharedscripts, postrotate and compress options used together | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Gerard Neil <xyzzy> |
Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 192468 | ||
Bug Blocks: | |||
Attachments: | Longer description of bug details |
Description
Gerard Neil
2005-09-20 00:18:26 UTC
Created attachment 68844 [details]
Longer description of bug details
This is exceptionally difficult, based on the structure of the program. Basically, without forking and re-writing parts of it, it's not possible. (the original file is compressed, then moved, one at a time. This is done in a loop, then the shared postrotate is run after they're all done) I suspect this is why delaycompress was added in the first place. I may yet fork and re-write, as the program is not well maintained (a loose, unoffical coalition of distros maintains it) for the moment, I'd suggest you either don't use sharedscripts with compress, or use delaycompress, as you suggested. I will leave this bug open, so that I can updated it when I get a better fix in place. Alternative suggestion seeing as I just ran into this as well: if sharedscripts is specified, make it imply delaycompress? This is a bad compromise, but it does "fix" the problem. The alternative mechanism would be to use a "queue" of sorts to just queue the to be compressed files until logrotate is done with everything else. I'll take a quick peek at the code to see how easy/difficult this would be. /me is almost praying that logrotate is written with C++ and not pure C, even if just for the stl. Still valid with 3.8.1? |