The logrotate script for samba-2.0.7-4 (for example) specifies
files /var/log/samba/log.*. This causes already-rotated files
such as log.nmb.1 to be rotated to log.nmb.1.1, etc. Each
rotation, every file in the directory gets rotated and an additional .1
is appended to its name.
A quick and dirty workaround is to specify explicitly the name of every
file to be rotated. In samba, however, these file names are not known
a priori--there is a name for every SMB machine on the network.
The fix that is needed is either for logrotate to be aware of what
files are already rotated and ignore them even in the presence
of wild cards or to give users better ways to specify what files
are the original logs and what ones are rotated.
(cf. also bug report 6998)
This is not a problem if you
require all log files you rotate end with
an extension like .log
Logrotate can create files with .gz and .1 .2 .3 ...
extensions and no exponential expansion will be performed.
The problem wit Samba was specific format
of log files format.
This should actually be a samba bug because the logrotate file comes with the
samba rpm. The original rpm from samba.org doesnt have this problem.
This is already fixed in the latest samba packages.
IMHO, a nicer solution would be for logrotate itself to avoid rotating files
.1, .2, .gz, .z, .Z, or whatever. For example, the junkbuster package creates
log files like
/var/log/junkbuster/junkbuster. Here, there is no wildcard spec in logrotate
that will stop
the proliferation of rotated files. Yes, you can argue that that's a junkbuster
bug (and I
have made that point to the packager, but it's still not been fixed), but I
think it would be
less irritating to fix the problem once and for all in logrotate. Then we don't
need to rely
on the kindness of strangers to keep things running smoothly.
I am using RH 6.2 with the latest samba-2.0.7-4 and I am still experiencing this behaviour. Which "latest samba packages" fix this problem?
This bug can cause logrotate to create so many files that the filesystem # of
files limit will be reached. That can create a number of really nasty problems,
so it should warrant an Errata release. I filed a bug #28919 asking for an