Move pruning enabled log message beneath the cut #6128

We should print it with startup messages for the current run, not before the cut and at the end of the last run.

hmmmm. I think this is a symptom of a different problem.

We have a set of messages that appears before the debug log is initialized. These should be buffered and dumped into the current log.

Moving messages down just adds code in places where it would not otherwise go, if not for this log issue.

Is that still true (in light of the params modularization)? I actually implemented a quick buffer but since came to realize that it might be completely unnecessary. At least in the non-exception case, the logs are initialized as soon as the parameter interaction checking begins in AppInit2 and nothing really needs to hit the logs before that. It looks like this may be as simple as just moving the cut and the version string to the start of the parameter interaction checks...

This might change the ordering of the messages, but it does have the desirable property of keeping locality between messages and related code.

What do you think?

On Wed, May 13, 2015 at 12:06 PM, Jeff Garzik notifications@github.com wrote:

hmmmm. I think this is a symptom of a different problem.

We have a set of messages that appears before the debug log is initialized. These should be buffered and dumped into the current log.

Moving messages down just adds code in places where it would not otherwise go, if not for this log issue.

— Reply to this email directly or view it on GitHub #6128 (comment).

Can't we move "the cut" up instead? I'd personally prefer that to buffering, as buffering logs tends to add complexity for avoiding message loss in crashes. Writing directly to file is nice and robust.

@laanwj Not really, no. This is a familiar problem in many softwares: You need logging at the earliest instant -- yet the logging itself has dependencies, such as reading the configuration file and determining the log file location. Logging occurs before this point, no matter where you locate the cut.

Regardless, the cut and version message are going to have to be moved earlier in the init process since they now happen quite late after parameter checking. I'll push two commits, one that moves the cut earlier in the initialization process. The second will add buffering.

Again, while playing yesterday, I noted that with the cut and version message moved very nearly to the top of AppInit2, nothing ended up in the buffer. A cursory glance indicated that nothing really calls LogPrintf() before then either. I'll push some code and then we can talk.

Ok, opened a new very simple PR #6147 that just moves the emission of the log cut to a sensible place. I'm working on trying to get the code to emit a message before this cut now. If I succeed, I'll PR the more complex buffering stuff.