This technique is not supported by the project, and will cause leakage of file handles and can easily result in unpredictable crashes of the process due to race conditions in the logging library. It will be explicitly disallowed in V3. If you want to externally control logging, use syslog.
The Shibboleth SP comes with logging capabilities provided by log4shib, a fork from log4cpp, which includes the RollingFileAppender. One can edit the file shibd.logger for example to specify the maximum size of the log files or the maximum files you want to keep.
However, if you want log rotation on a daily basis you may want to use a third party tool such as logrotate to manage the Shibboleth logs. This might also be beneficial for other reasons, such as centralized log management. In this case, you will need to make Shibboleth reopen log files without interrupting its services and states. It turns out it is pretty simple to do so:
# do whatever log rotations you want below such as
mv shibd.log shibd.log.01
mv transaction.log transaction.01
# change the modified time of shibboleth.xml by touching it
After this is done, you will notice that Shibboleth has created a new shibd.log and a new transaction.log and stopped writing to the old log files. The cost of doing this is that metadata and all the other related components will get reloaded. However, the services Shibboleth SP provides are not interrupted in this process.
A sample configuration file for logrotate could therefore look like:
create 640 shibd shibd
touch /etc/shibboleth/shibboleth2.xml > /dev/null
This should result in files like: shibd.log, shibd.2013-09-15.log, shibd.2013-09-14.log.gz, shibd.2013-09-13.log.gz, ...
Next, change all appenders in
FileAppender. This prevents the logs from getting rotated by Shibboleth itself based on their size.
Comment out lines with
maxBackupIndex as well. E.g. for shibd.log:
Proceed likewise for