The default paths for gzip and gunzip in logrotate are located in /bin/, however, both standalone gzip and busybox-gzip installs to /usr/bin by default (as far as I can see, however). As the standard logrotate.conf file enables delayed compression, this meant, that only one rotation happened on our system (leading us to think that logrotate worked), but after the first rotation, the memory was slowly filled with logs due to logrotate not locating gzip and stopping: rotating pattern: /var/log/modemd 524288 bytes (7 rotations) empty log files are rotated, old logs are removed considering log /var/log/modemd log needs rotating rotating log /var/log/modemd, log->rotateCount is 7 dateext suffix '-20000101' glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]' compressing log with: /bin/gzip error: failed to compress log /var/log/modemd.1 ----------- I consider three options for fixing this: 1) logrotate is "fixed" upstream with a function looking for gzip based on the environment PATH variable. However, I dont see this as a likely option, as I believe RedHat and Fedora still uses /bin/ for these kinds of programs, and thus has no interest in changing it. 2) It is simply fixed in logrotate.mk by appending: -DCOMPRESS_COMMAND=/usr/bin/gzip -DUNCOMPRESS_COMMAND=/usr/bin/gunzip to the CC part of: $(MAKE) CC="$(TARGET_CC) $(TARGET_CFLAGS)" LDFLAGS="$(LDFLAGS)" -C $(@D) 3) Patching the config.h file of logrotate to use /usr/bin I don't see what seems more fit? I'll help as much as possible with testing and implementation.
After looking closer into the LSB and FSH, it seems that /bin is actually still used by the standard, and it states: The following programs, or symbolic links to programs, must be in /bin if the corresponding subsystem is installed: ... gzip The GNU compression utility (optional) gunzip The GNU uncompression utility (optional) ... So I guess that only looking for gzip in /bin/gzip is correct according to the standard, and the real issue is why no symlink exist in /bin/ for the two programs. I'll look into this, and possibly file another bug on the subject.
I've never seen anyone close their own bug as invalid so fast :) Keep it open, it's actually valid, but you missed a few details i think. If you use busybox, it's gzip/gunzip is properly installed to /bin, so i'm assuming you're not using busybox at all (or disabled gzip in it) and using "big fat" gzip which installs into /usr. So the solution would be to make the gzip package install into / rather than /usr. I'll cook a patch and send it to the list soon.
Great!, thanks, I've just concluded that as well - that busybox installs it correctly into /bin, and that gzip is the culprit (actually our system has both /bin/gunzip from busybox, and /usr/bin/gunzip from the gzip package - so some cleaning up is needed). I seems like it can be fixed in the gzip.mk file quite easily? Best regards, Henrik
Try with http://patchwork.ozlabs.org/patch/425695/
Just testet it quickly (havent have time to boot my target with it yet), but it looks good! :) GZIP_CONF_OPTS = --exec-prefix=/ should be: GZIP_CONF_OPT = --exec-prefix=/ though, and the slash can be entirely omitted. Good work! thanks!
(In reply to comment #5) > should be: > GZIP_CONF_OPT = --exec-prefix=/ Not in recent Buildroot versions. GZIP_CONF_OPTS is now the right variable. I've applied Gustavo's patch, as http://git.buildroot.net/buildroot/commit/?id=09d6597cb5ab326097533cd4be7b9764b960c930, so I'm closing this bug. Thanks Henrik and Gustavo!