Description of problem: Really, an enhancement: rsnapshot generates a log file /var/log/rsnapshot, but there is no provision to rotate it. It just gets bigger and bigger. In my system, I have added a standard 5 weekly rotations to /etc/logrotate.d, but that may not be optimum. Version-Release number of selected component (if applicable): How reproducible: N/A. Steps to Reproduce: 1. 2. 3.
Created attachment 2664 [details] My file for /etc/logrotate.d/rsnapshot
another package really unmainted :s
Keywords: (none) => Junior_job
A pity. I could perhaps - very perhaps - supply a patch to fix this, but looking at the author's Web site, I haven't got the knowledge to be a maintainer.
Attachment 2664 mime type: application/octet-stream => text/plain
Debian is using this one: /var/log/rsnapshot.log { rotate 6 monthly compress missingok } I can add the file but probably in cauldron. Or do you think it's so big problem that it needs update? I'm not so sure about it.
CC: (none) => sander.lepik
I haven't seen the issue raised before. From the man page: "logfile /var/log/rsnapshot Full filesystem path to the rsnapshot log file. If this is defined, a log file will be written, with the amount of data being controlled by loglevel. If this is commented out, no log file will be written." loglevel is another variable. Debian rate the priority as low: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506218 implies that they provide for the log file to be rotated only if it exists. However it is done, the provision needs to be there. I have a standard rsnapshot.conf that I substitute without looking. The default in Debian is no logging, because the bug report mentions uncommenting the line referred to above. It may be the same for us. I could do without logging. My usual issue is the backups themselves getting too big for the allocated space. Leave it with me to research further. My HD just crashed and I am on a makeshift system until I can install a new one and put Mageia on it.
The default /etc/rsnapshot.conf turns on logging at loglevel 3, which differs apparently from Debian. I have no objection to the Debian file for logrotate.d, although in my case, that much logging is unnecessary. IMO, uniformity across Linux distros is a good thing, and doesn't conflict with the user's right to do it how he wants (as I have done.) Any defaults for sysadmins need to be respected. It can wait until Cauldron. My setup backs up several directories and has a lengthy list in the "exclude" parameter. This means a very repetitive log entry each time, but I have the disk space to contain a month's worth. If not, I can replace the default with my present file.
Changes commited. Will submit if BS is working again.
Status: NEW => ASSIGNEDHardware: i586 => AllVersion: 2 => CauldronAssignee: bugsquad => sander.lepik
Submitted, please test.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
Thanks Sander. Is the "please test" for me, or for your upstream?
(In reply to comment #9) > Thanks Sander. Is the "please test" for me, or for your upstream? For you as you are the reporter :)
Where do I retrieve your patch? I am only a user who likes to fiddle, but is the whole assembly-line set out somewhere?
rsnapshot is noarch package, so you could maybe even try cauldron package on mga2. My change is here: http://svnweb.mageia.org/packages?view=revision&revision=284651 Cauldron's package is located here: http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/cauldron/x86_64/media/core/release/rsnapshot-1.3.1-8.mga3.noarch.rpm
The overall logrotate config file starts as follows: # Mageia logrotate configuration # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 Isn't that a default for every log in /var/log ? Later files overwrite earlier ones, and those in logrotate.d are included later, but if there is nothing in /etc/logrotate.d, shouldn't logrotate.conf have enforced weekly rotations? It didn't in my case.