Hello Jan, ----- Original Message ----- > From: Jan Kaluža <jkaluza@xxxxxxxxxx> > Subject: Re: logrotate(8) and copytruncate as default > This is usually fixed by sending some signal to daemon in postscript > informing it that logs should be reopened. That way, no messages are > lost. The worst thing which can happen is that some messages get logged > in the rotated file for short time (after rename is done by logrotate > and before daemon reopens the new log). Right, I did try that, but it does not help. Because 'ndjbdns' servers run inside a chroot(1) jail. At start-up these servers open the log file under - /var/log/ - and change root directory to a secure location. Now when logrotate(8) rotates the file, even if it signals to a DNS server that it needs to start writing to a newly created file, server can't do it because - /var/log - is not visible/accessible from inside a chroot(1) jail. > If you use copytruncate, there is chance that some messages get lost (as > stated in man logrotate). Making it default could surely make things > much easier and less error-prone, but I'm afraid we just can't remove > old behaviour completely right now and therefore it wouldn't save > anything regarding the problems you have mentioned. I'm not sure if there would be much of data loss during copy-truncate. Because that time window is tiny small. It is a similar race condition issue as the current one, but much less severe. There's no chance of unprivileged user access etc. I also doubt if making copy-truncate default behaviour would break any packages which depend on logrotate(8) to rotate their logs. > I'm not sure right now if the benefits of the "copytruncate" usage > are strong enough in comparison with the possibility to lost the messages > during rotation. I think we should try to evaluate for real how much data is lost, if any. > I will definitely try it and see how bad it is, but I presume for bigger > logs it could be a problem. That's cool! Please do let me know if I could help in any way. > Maybe it's just better to try to fix existing bugs and not abandon the > "rename and reopen" way completely? Well, existing bugs would be fixed anyway. I'm not saying we abandon rename and reopen completely, may be we could provide it as an option in place of 'copytruncate' say - 'createlog' or 'renamelog' or something like that. Thanks so much! --- Regards -Prasad http://feedmug.com -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
