Same log file opened multiple times in write mode, truncating file on each write about log4r HOT 3 OPEN

We are seeing this too with many processes writing to the same log file. There is certainly a race condition between checking if its time to roll and opening the next file. When the second process re-opens the same file in "w" mode you get lots of craziness because, unlike append mode, "w" does not seek to the end of the file for you when writing. That means the processes will be battling it out and overwriting the middle of the file.

from log4r.

I'll note that simply changing "w" to "a" brought up another issue -- we got occasional errors where log4r was looking for a log file that didn't exist and raising an error, on the line @start_time = File.ctime(@filename). It only happens once a week or so for us so I haven't had time to debug it further.

from log4r.

We've run into this issue in production as well; the cause of this seem to be multiple unicorn worker using the same RollingFileOutputter.

Every process tracks the log size itself (https://github.com/colbygk/log4r/blob/master/lib/log4r/outputter/rollingfileoutputter.rb#L128) and never actually checks the file size. This means that workers decide to roll over to the next file independently and when rolling over they can just overwrite existing file generated by another worker (https://github.com/colbygk/log4r/blob/master/lib/log4r/outputter/rollingfileoutputter.rb#L198).

from log4r.