Tomas Volf <~@wolfsden.cz> writes: > 1. Per-log file settings. Some files I want to never rotate (the data > has sentimental value). Some files I want to rotate, but keep *all* > previous versions (if I would be using Guix at work, this is required > for auditing reasons).
OK. > 2. Option to limit number of rotated versions being kept. Currently, > any single "log stream" can occupy unlimited disk space even with > frequent rotations. To prevent that, I would like to express expiry > in terms of "keep current and 4 rotated versions", but that is not > possible as far as I can tell. Expiry is expressed as a duration. I’m skeptical about expressing it as a number of files. One thing we could do is make #:expiry a procedure taking a file name and returning its expiry. > 3. Run-time discovery of log files to rotate. I have no idea how to use > shepherd for rotating samba's log files for example, their names are > (in my configuration) dynamic based on the host name of the machine > that connects to the samba share. Their only shared trait is that > they are under /var/log/samba.d and end in .log. Yeah. The “external log file” mechanism could be extended to support glob patterns or regexps. > What is your opinion on turning the log rotation into a plug-able > mechanism? I did not look too closely yet how this part of code works, > but for example being able to set global parameter to a callback to do > the log rotation could allow lot of flexibility while keeping it out of > Shepherd itself. We could expose more extension points. (It would also be possible to maintain a separate log rotation tool outside the Shepherd: there’s a well-defined protocol to query the log files of services and to perform atomic rotation.) Thanks for your feedback! Ludo’.
