Winston: log rotation feature crashes intermittently

[nikdunn]

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.

[rdpoor]

+1

Even though it doesn't appear this is related to timed rotations, I've been adding comments to https://github.com/winstonjs/winston-daily-rotate-file/issues/36 . If it is a core issue, perhaps @mattberther will realize that and move the issue back here.

[ghost]

Happening for me as well.

[nogashimoni]

Any updates on this issue?

[i-made]

Any updates on this issue. It's still there, not fixed it

[DABH]

Do folks see this issue in the latest versions of winston (3.1.0 or master) or does this seem to be 2.x-only? Trying to triage and/or see if the significant changes to the File transport in 3.x might have fixed these issues.

[gubbaraviteja]

This is happening when I'm running the application in cluster mode. I'm using the version 3.8.0. Is this being looked into as I see its hanging from more than 2 years?

[SunshowerC]

Any updates on this issue?