log rotation about semantic_logger HOT 2 CLOSED

Hi @reidmorrison ! A question about your doc of log rotation.

Logrotate manual clearly states that copytruncate option may lead to some data losses due to the fact that there might be a delay between copy and truncate. Your doc seems to indicate the opposite.
I know you probably ment that's the best way to rotate semantic logger logs, but I think it could be missleading for someone that doesn't fully understand the underlying mechanism. Do you think the doc could be improved to be a bit more clear regarding this? (at least a comment referring to logrotate doc).

On a related matter, have you thought of adding some easy way to reopen logs on a signal (like HUP)? (if you want I can open an issue to discuss this feature)

from semantic_logger.

Linux has exceptional support for log rotation using logrotate.

For example for log rotation on a daily basis, create a file called /etc/logrotate.d/my_app

/var/www/rails/my_app/log/*.log {
        daily
        missingok
        copytruncate
        rotate 14
        compress
        delaycompress
        notifempty
}

This log rotation example is based on log file size and is useful if the application is logging a lot of data, or if you want several days in one log file for low traffic sites:

/var/www/rails/my_app/log/*.log {
        size 2G
        missingok
        copytruncate
        rotate 7
        compress
        nodelaycompress
        notifempty
        dateformat .%Y%m%d
}

Other log rotation tools are also available, the only requirement from a Semantic Logger perspective is that the files must be rotated using copy-truncate to ensure that no data is lost during log rotation.

from semantic_logger.