Bug 7766

Summary:	logrotate default gzip path is usually wrong
Product:	buildroot	Reporter:	Henrik Juul Pedersen <hjp>
Component:	Other	Assignee:	unassigned
Status:	RESOLVED FIXED
Severity:	minor	CC:	buildroot, hjp
Priority:	P5
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	Linux
Host:		Target:
Build:

Description Henrik Juul Pedersen 2015-01-06 13:48:41 UTC

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.

Comment 1 Henrik Juul Pedersen 2015-01-06 14:08:08 UTC

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.

Comment 2 Gustavo Zacarias 2015-01-06 14:20:09 UTC

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.

Comment 3 Henrik Juul Pedersen 2015-01-06 14:38:13 UTC

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

Comment 4 Gustavo Zacarias 2015-01-06 14:43:37 UTC

Try with http://patchwork.ozlabs.org/patch/425695/

Comment 5 Henrik Juul Pedersen 2015-01-06 17:05:07 UTC

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!

Comment 6 Thomas Petazzoni 2015-01-06 20:18:42 UTC

(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!