I noticed that Portage does not provide any logrotate configuration snippet in /etc/logrotate.d. I think it should provide one for /var/log/emerge.log, in order to avoid this file to grow uncontrolled.
hmm, that would make the portage logfile analyzers nearly useless.
Yes, you're right... hmmm... how about providing an option to limit the maximum size of the logfile, setting it to unlimited by default, then? In this way logfile analyzers won't be hurted, but it would be possible to keep it under control. Maybe something like: --- begin --- # Maximum size of /var/log/emerge.log logfile, in bytes (append K or M to express # the value in kilobytes or megabytes, instead). # If you need to use some kind of analyzer, keep it to the default value of zero, meaning # unlimited size. EMERGE_LOGFILE_SIZE=0 --- end --- in make.conf would do the job. I have no idea of how much could it be complex to achieve, though.
What do you consider out of control? My development/testing box that I use for portage only has a 3 meg file. You can delete it if you'd like. It's their for administration convenience. I don't see a good reason to limit it. megalo root # ls -l /var/log/emerge.log -rw-rw---- 1 portage portage 2287477 May 23 04:44 /var/log/emerge.log development root # ls -l /var/log/emerge.log -rw-rw---- 1 portage portage 3304386 May 23 04:20 /var/log/emerge.log
It's just a matter of "best practice": if you have the potential for a certain file to grow indefinitly, you should also have a way to limit it, especially in unattended contexts such as a production server. It could well remain limited in size no matter how much you use emerge, but it's not relevant IMHO: the potential for unlimited growth still exists. Or am I too much fond for controlling everything? :-)
Shifting data is quite painful. The operations are atomic... meaning that each line is a complete open,write,sync,close set. At the 'full' point, you'd cause a tremendous amount of IO. A patch would be the best way to get this moving.
Maybe I didn't explain it well: I didn't mean to keep the logfile to a fixed size, I agree that it would be crazy to continuously remove one single line to write another. I meant that, once the file has reached the configured size, it is archived somewhere and replaced by a new one. By the way, logrotate has an option to rotate logfiles according to their size instead of the time since last rotation: maybe it could be a way to solve the problem? I didn't get what you mean with "a patch would be the best way"... I only know the patch command, but I don't think it's what you were referring to. Could you please explain better? Thank you in advance! :-)
Not of great interest, and nothing posted.
*** Bug 121951 has been marked as a duplicate of this bug. ***
*** Bug 179855 has been marked as a duplicate of this bug. ***
