Gridcoin-research: Enhancement Request: Rolling Log File

[HighTower79]

Unfortunately I'm not a programmer, but I would like to see some kind of configurable log settings.

It would be great to have a rolling log file, which can be configured by an options dialog inside the client.
I've created a picture with some possible settings which I think might be useful.

1. Specify when the log file will roll.

   • Option A: When the client starts/restarts (save the old log files if present)

   • Option B: On a specific time of the day (e.g. midnight)

   • Option C: By Size (e.g. when the log has a size of 100 MB)

2. Additionally you can specify how much logs you will keep. So you can specify how many log's you'll keep, because currently each time the client starts, the logs get cleared.

Possible Log File Naming Convention: debug[0-9]_yyyymmdd-hh24miss.log_ (using the date and time when the log file was created)

May be there can be additional settings which might be useful.

I don't know how much effort this will be, but I think it would be a great feature for the client.
And it might make debugging more easier when you have "old" logs as a backup.

[tomasbrod]

Related function util.cpp:ShrinkDebugFile().

[pwnorbitals]

I'd suggest adding a debug tab instead of log, in which we could include : hide/show client messages, log rolling, an 'open last log' button (if you like the idea) and maybe the coin control features. Thoughts ?

[tomasbrod]

What about doing it properly and logging to Syslog?

[pwnorbitals]

Because syslog is not supported on windows (afaik) and it would make us introduce platform-dependant code, something we are trying to get away from, I guess

[tomasbrod]

Although there is syslog ("Windows (r) Event Log") in windows, the api is so complicated that Internet advises to not use it.
On Linux, we can use syslog (logging to systemd user log), and Windows users will get their debug truncated from time to time.

[pwnorbitals]

Manual log rolling would be multiplatform, not introduce any problem and we could just test for the existance of syslog and write to it if available. That would keep our code #ifdef-free, readable and would also solve both problems of custom logging and system-wide logging

[tomasbrod]

That would be best, @MagixInTheAir

[pwnorbitals]

If anyone is good enough in UI design, I would be interested to see proposals of how the debug tab could be laid out :)

[HighTower79]

I'd suggest adding a debug tab instead of log, in which we could include : hide/show client messages, log rolling, an 'open last log' button (if you like the idea) and maybe the coin control features. Thoughts ?

I like the idea of adding a button to open the last/latest log file, so you could easily open it from within the client.
My intention for this ER was to have a rolling log file and to be able to configure it using the settings on a tab (log) in the client options dialog.

But, the idea with the debug tab instead of the log tab, I don't know.

We might also add an additional menu option in the main menu, e.g. Log with the following sub-entries:

• Show current log (opens the current log using the system editor or displays a new dialog with the content of the current log)
• Configure Log (displays a dialog like the one I suggested to configure log settings)

It might also be feasible to specify the debug level's on this settings tab (debug2=true,....)

[jamescowens]

@denravonska and I have been discussing this as of late. I would like to implement log archiving/rolling logs for the Denise milestone. We can also implement compression of the archived logs to save space.

[tomasbrod]

What about logging to syslog (under user facility) and letting the system manage the logs?

[jamescowens]

That would be elegant, but the issue is that is really a Linux only solution. The Windows logging API (event logs) is unnecessarily complicated, and I don't think we want to get into writing a troublesome adapter to deal with it. Further exporting Windows event logs for analysis is much harder...

Conversely the log archiving I did in the scraper is literally 20 lines of code.

[tomasbrod]

maybe: http://log4cpp.sourceforge.net/, boost::log
But considering there is already a logging groundwork from bitcoin, I agree, it should be extended instead.

[jamescowens]

Quite a few changes in the latest Bitcoin code for logging, now separated into logging.* compared to us. Still it does not appear they have implemented log rolling and compression, just made the truncation options more fancy. They have also changed the log categories approach it appears. And, more importantly, the logger is a scoped object rather than global...

[jamescowens]

If we adopt the BCLog class approach, it actually makes it easier to drop in the archiving functions, much like I did in scraper's log class.

I would really like to extend Bitcoin's logging so that multiple output files are supported. (In other words direct a specific category to another file rather than the main file.) This would allow us to use a single log class abstraction yet separate out stuff that deserves its own file like the scraper log entries. This is similar to the logging facility provided in Linux...

[jamescowens]

Also, I would like to mention I did exactly what the authors suggested for the scraper on the debug tab for the scraper. It implements essentially a tail of the scraper log in the UI using a size limited text box. This has to be done with signals and slots BTW, and I get nervous about having two of these running simultaneously, one for the scraper and one for the main log. The UI code locks cs_main in the plumbing I think and having fine grained signals with two rolling logs is asking for trouble. (I.e. unresponsive UI...)

What we can do is switch the log tab I have created to the main log when we backport Bitcoin's BCLog...

[jamescowens]

[philipswift]

Sorry to stick my nose in however how about https://github.com/gabime/spdlog). Keeping it fast and wretch free?

[jamescowens]

@denravonska recommended that package. It could probably be hooked in. This will take us in a different direction from Bitcoin, but we don't have to do everything exactly like them, and I think their approach to logging is in general, while improved in their current codebase from where we forked the code, lacking.

[jamescowens]

Closing this issue. We can address the UI part as part of the UI rewrite.