How much should katip support log rotation?

[MichaelXavier]

Some logging utilities actually manage log rotation for you. Others simply provide hooks for reopening handles on certain signals so external log rotators can do the rotation and signal to the process when to reopen. Is this something katip should do? There's also the question of a generalized rotation strategy, as rotating elasticsearch logs has also turned out to be important in the real world.

I'm of the opinion that katip shouldn't be responsible for rotation. At a certain point I think log libraries just start reimplementing buggy, less robust log rotation features when there's already easy to use tools available (such as logrotate). I don't see any benefit for us trying to do logrotation other than the convenience of specifying rotation schedules alongside other log settings when using katip. This is achievable by other means.

[ozataman]

My thought on this has always been that we'd have a separate backend - basically an enhanced Handle backend- that, among other things, would also take care of rotation.

The ability to signal from the outside though might be worth looking into. If it's real easy, we could bake it into the basic Handle backend as well.

[MichaelXavier]

I could see that being contributed. For reopening logs I usually use copytruncate in logrotate which seems to eliminate the need to reopen. The challenge with adding reopening to the current handle scribe is it gets passed a pre-opened Handle, so it can't reopen it because it doesn't know the file to open.

[sopvop]

If GHC.IO.hDuplicateTo is atomic, then reopening logs from outside is not a problem.
If it isn't, then you'll need some kind of locking, like taking MVar Handle instead of just Handle.

But that would require some kind of queue for messages for good efficiency, so you can log messages in batches, like the one in logging-effect package.