Several things: First, there is no mention of logrotate, or equivalent functionality in the install instructions. This seems like a pretty large oversight since without a log rotation scheme, the disk is going to fill up eventually any it will be "our" fault since we never told the "user" that they needed to do something about it. Second, once the user figures out that they need log rotation, they may try to "emerge logrotate" and find that it doesn't actually *do* anything out of the box (so to speak). I think the cron file and logrotate.conf files should be installed into /etc/cron.daily and /etc respectively. At least then, the user has something to start from. Better yet, this is Gentoo Linux after all, we're supposed to be the hot stuff here. Why not include a functional logrotate.conf that's closer to what people might want? Third, the default logrotate.conf uses the include functionality of logrotate to grab files from /etc/logrotate.d. The ebuild script doesn't create this directory.
Az, thoughts on this?
how about a nice explain how to do text after emerging ? einfo in the ebuild
For the second point, I agree in that there should be a base logrotate.conf based on the default daemons, etc which are installed. On the third point, getting logrotate up and running is a major PITA w/o any predefined scripts. I would be nice, but admittedly a ton of work, to populate each of the currently available daemon with its own script for logrotate.d. Perhaps a USE flag, logrotate, could be used to determine if the "extras" get installed?
Guess I never thought about it, as I use sysklogd with vcron, which rotates logs nicely all by itself.
Nicholas, you are the lucky canditate that can add the scripts, as it seems you sorda know something about them :P
Already one step ahead of you, I've modified (locally) the logrotate ebuild to install properly along with a default conf and cron script. I've also been "stealing" logrotate.d scripts from RedHat's rpm's. I will add them to ebuilds, but I need to know first if we should have a USEFLAG to determine their installation? Or should I just check for the existance of /etc/logrotate.d? Please advise.
I think just install them. They usually are small, and the user who use logrotate will delete/enable those he need. Rather that, than confusion about them not being there.
Here's the /etc/logrotate.d/syslog-ng I'm using here: /var/log/messages /var/log/mail.log /var/log/mail.err /var/log/kern.log /var/log/auth.log /var/log/cron.log { sharedscripts postrotate /etc/init.d/syslog-ng reload > /dev/null 2>&1 || true endscript }
Dragon, how's it going on this?
I'm working on it when I can (as you are aware I do have a fairly full plate), but there are a bunch of packages which need the logrartate config fragments. I would prefer to check the majority of these fragments in at once so that there is some uniformity. I also want to make sure I get as much coverage as I can on this first round. Also, I would like Martin to add /etc/logrotate.d to baselayout since he wants the fragments installed regardless of whether the person uses logrotate or not. Once the baselayout with this dir is stable, I will then commit the updated ebuilds and logrotate config fragments. However, if this is an issue, let me know and I'll devote more resources to completing it.
To be honest, I would suggest a WIB (worse-is-better) approach. I think that if we have some known culprits, we should get a first pass out there and not worry about the stragglers. We'll bring them into the fold as we can, but it might be too much to attempt to get a wide range of packages on the first pass. Regarding /etc/logrotate.d, there is no need whatsoever to wait for the baselayout change. The first package to add a snippet will automatically create that directory (as you know) and a subsequent baselayout update won't hurt anything. It's not a bad idea to get logrotate.d into baselayout, but I don't think that should hold us up. If there's anything I can do to help out, let me know. If you have some starter snippets, maybe you should add them as attachments here so you're not the only one with the info... ;-)
Right, I do not see what baselayout have to do with this ... it should actually be created initially by logrotate (maybe with keepdir ...).
Created attachment 8992 [details] A logrotate ebuild. I improved the logrotate ebuild before I found this bug, so I'll go ahead and include it here, just in case it has something that you'll find useful. It has the following changes: + Silences the CVS/Root spewage in the 3.6.5 "make" output. + Don't twiddle the Makefile, just set RPM_OPT_FLAGS with our CFLAGS (note that the tweaking of the Makefile was in the wrong section anyway -- it would have gotten repeated on repeated compilations if someone was using ebuild manually). + Installs a tweaked logrotate.conf file (doesn't refer to RPMs). + Installs a logrotate.d dir. + Installs a crontab file in the cron.daily dir. + The package now depends on virtual/cron. Take a look if you haven't already tweak all these items.
On the topic of putting logrotate.d into the baselayout, I agree with Martin (it just needs to be in the logrotate package). The .keep file is needed to prevent the directory from vanishing (which would cause logrotate to exit with an error). Having an empty .keep file in the dir does not adversely affect logrotate (it reads the file, but does not do anything nor does it complain about it being empty).
Martin, since logrotate isn't a required package, then what happens to the people who don't have logrotate emerged but emerge a package with a logrotate fragment? You told me that I should just have each fragment install by default, without any use flags or conditionals. There's no reason why putting it into baselayout would be bad. It's either that or a USE flag, as we need some way to make sure we don't get a sandbox error. Wayne, actually I've already done those things, but thanks nontheless for your contribution. The reason I need logrotate.d in baselayout is because of how we decided to impliment the installation of logrotate fragments [in this case, without conditionals]. Besides, it just makes things easier for me. Since Logrotate is developed by redhat, I'll be making my own tarballs based on cvs tags rather then by rpm or debian's sources. Anyhow, we'll get this fixed up.
Dragon, won't the directory /etc/logrotate.d be created automatically by any package installing a logrotate fragment? Possibly I'm misunderstanding something, but I don't think there is any need for the directory to exist prior to installing fragments...
Ok, I had a real brainfart when writing that last night. Aaron, you are totally correct, of course portage will make the dir! What was I thinking? Ok, well that solves that one, I'll just have logrotate's ebuild install the .keep file. Thanks for setting me straight :-).
Just FYI, I have added a logrotate.d snippet to the syslog-ng-1.6.0_rc1-r1 ebuild based on Michael's suggestion.
Re-assign to the original bug filer since he's now a dev and can decide what needs to be done next, if anything, to finish this out.
I was just fighting with logrotate here and had some problems. I wont speak of them here, but, I think a solution to your question of where to place the logrotate.d/* files would be to place them in /usr/share/logrotate-*/samples directory. Using this method would prevent confs from being installed for programs that do not exist on the user's system (and keep the cron log from filling up with errors). Placing a note at the end of the ebuild explaining the location of the confs would be beneficial as well. Thought I'd throw in my 2 cents and see if I could get some change anyhow :) -P
*** Bug 20907 has been marked as a duplicate of this bug. ***
Created attachment 11998 [details, diff] Fix a couple minor things in the 3.6.5-r1 ebuild A couple things I noticed in the new logrotate 3.6.5-r1 ebuild: - The src_compile() function is patching the source. This should be done in the src_unpack() function so that someone using ebuild manually can run "ebuild ... compile" multiple times. - The digest is missing the line for the selinux patch. I've attached a patch that fixes these problems.
Wanye - Thanks for the patch. I've applied it so please try out the latest logrotate ebuild. Thanks for testing.
Masked testing for long enough so unmasked and closing this bug.
