log rotation feature crashes intermittently

The original issue was inexplicably closed and moved over here: https://github.com/winstonjs/winston-daily-rotate-file/issues/9 so I’m reopening it. I’m not using time-based log rotation at all I’m using the core File Transport functionality. I have newer information that may help me find a solution.

I have no idea if it is related to the other crash issues I’ve seen documented, but I am seeing:

Error: ENOENT, open ‘/work/server/server.log’

Every once in a while. In the directory there is a server.log.gz that is 0 bytes along with other log files that have been successfully rotated.

The issue seems to happen when logging frequency and content is high.

I’ve handled the uncaught exception, but there’s not really anything I can do about it since the logger blew chunks.

I’m doing:

winston.add(winston.transports.File, {
    filename: __dirname + '/server.log',
    json: false,
    colorize: true,
    timestamp: true,
    maxsize: 10000000,
    maxFiles: 50,
    showLevel: true,
    tailable: true,
    zippedArchive: true,
});
winston.remove(winston.transports.Console);

The problem seems to be a result of the self._archive variable being set to ‘/work/server/server.log’ when the code enters the compressFile() function. See the code here: https://github.com/winstonjs/winston/blob/master/lib/winston/transports/file.js#L468-L530

Usually, when the code executes: self._stream = fs.createWriteStream(fullname, self.options); fullname is ‘/work/server/server.log’ and self._archive is ‘/work/server/server1.log’

So winston opens a new file for writing new log data (‘/work/server/server.log’) and opens a read stream (‘/work/server/server1.log’) that gets piped through gzip and to a write stream (‘/work/server/server1.log.gz’).

I believe the crash occurs when ‘/work/server/server.log’ sneaks through into the compressFile() function.

I think the sequence is:

1. self._stream = fs.createWriteStream(fullname, self.options). This does not wait for the ‘open’ event to be emitted before,
2. compressFile immediately tries to do fs.createReadStream(String(self._archive)) and in some circumstances the file does not exist yet.

That’s my current theory anyway.

My question is: should winston ever gzip ‘/work/server/server.log’? Is this for the non-tailable log rotation case? Am I on the right track?

Okay fine that was three questions.

[ghost]

Happening for me as well.

[SunshowerC]

Any updates on this issue?