prplMesh icon indicating copy to clipboard operation
prplMesh copied to clipboard

easylogging: resolveFilename: use same file for all debug levels

Open vitalii-komisarenko opened this issue 5 years ago • 2 comments

For each debug level the log file name is calculated separately. Normally, it's always the same name, so the log file will be opened only once. However, if the second happens to tick by in the middle of the initialisation of the logging, we will have two different log files with 1 second difference, and half the log ends up in one log file, the other half in the other log file.

In the case of that CI job, it lead to a failure because we grep the log file to check the status of the agent, and we were grepping the wrong log file.

This commit ensures that all file name calculations use the same time stamp.

vitalii-komisarenko avatar Mar 09 '20 10:03 vitalii-komisarenko

Unfortunately, I don't think this is acceptable...

There's another feature that we use, log cycling. I don't remember exactly how it's configured, but after some time the log files will be closed and reopened under a new name. However, the "new name" bit is just that it has a new timestamp. With this change, the timestamp is calculated only once, so log cycling will just reopen the same file again.

I could be wrong though - maybe the TypedConfigurations object is re-created when the logs are cycled, in that case all is well.

IIRC the log cycling is done within easylogging++ itself, so it should be possible to simply reset m_dateTimeNow when log cycling is done.

arnout avatar Mar 13 '20 14:03 arnout

Not approving as I'm not sure if this change is required (especially since it's modifying a third-party library).

Well, it really is a bug in the upstream library. In easylogging++, if you want to put DEBUG and INFO logs in the same file, the only way to do that is to configure DEBUG and INFO to use the same filename (pattern). The problem is that if that pattern contains a timestamp, they may expand to different filenames.

Perhaps the CI issue can be handled differently:

It's not just a CI issue, it's also a production issue. You really don't want the logs to be in two separate files.

arnout avatar Mar 13 '20 14:03 arnout