You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you are logging to a file and that file gets manually deleted, the logger does not re-create the file and continue logging, instead looses logs from that point.
The text was updated successfully, but these errors were encountered:
It handles the write if there's a stream, but doesn't handle the situation where there's no stream, nor does it do anything other than emit an error when the stream write fails.
Researching this shows this isn't a bug. Deleting a file removes the reference link to the file's inode. The stream continues to write to the inode, but isn't accessible via the file system since you deleted the link to it. The best thing to do is send a signal (SIGHUP or SIGUSR1) to the logging process when you move its file away so that it can recreate the log file.
Yes this isn't really a bug as such, hence why I haven't moved on it. But it is something I saw someone do and be surprised about when using the software.
We could work around it by closing and opening the stream periodically - such as at the end of a batch of writes, this doesn't affect performance too much but does add a large cost to starting a new batch of writes which could itself be the reason that multiple logs get written at the same time.
It's not too difficult, just need to choose a scheme and go with it, but as it stands, keeping the file open is a fairly basic and straightforward way to work - just with this quirk when you delete a file.
Once the rotation happens, you do get logs again, so it's not loosing all logs forever.
If you are logging to a file and that file gets manually deleted, the logger does not re-create the file and continue logging, instead looses logs from that point.
The text was updated successfully, but these errors were encountered: