[SERVER-24395] Do not display startup warnings when querying for version Created: 03/Jun/16 Updated: 08/Jan/24 Resolved: 30/Aug/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Admin, Logging |
| Affects Version/s: | 3.3.6 |
| Fix Version/s: | 3.3.14 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | David Golub | Assignee: | Mark Benvenuto |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Sprint: | Platforms 16 (06/24/16), Platforms 17 (07/15/16), Platforms 18 (08/05/16), Platforms 2016-08-26, Platforms 2016-09-19 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
In MongoDB 3.3.6, running mongod --version on Windows without the KB2731284 hotfix installed will cause a startup warning to be displayed before the version information. This causes the Automation Agent to fail because the output is not in the format it's expecting. It is crucial that this does not make it into any production version of MongoDB, as doing so would prevent customers from being able to deploy clusters running the latest MongoDB version on Windows using automation. |
| Comments |
| Comment by Githook User [ 30/Aug/16 ] |
|
Author: {u'username': u'markbenvenuto', u'name': u'Mark Benvenuto', u'email': u'mark.benvenuto@mongodb.com'}Message: |
| Comment by Andy Schwerin [ 24/Jun/16 ] |
|
I don't want to restrict the behavior of logging too much during initializers or static initialization. If this behavior is important, I'd rather that we added a test for it, and split the logging portion of collectSystemInfo from the part needed for the secure allocator. Then, we move the logging part into a mongo initializer that runs after "default" (and hence after command line options). Now, the rule becomes that if you write a mongo initializer that logs, it must either be fatal or occur after command line processing. That's good for log redirection, anyhow. If you're using --logpath, I bet that the hotfix message isn't getting in. Similarly, any logging in static initialization (which is legal) must be fatal. We could enforce this behavior by making the logging code abort the process if it occurs before command line processing is done, or we could just hope to test it with the aforementioned jstest. |
| Comment by Andrew Morrow (Inactive) [ 24/Jun/16 ] |
|
I'd also be interested in comments from mira.carey@mongodb.com and mark.benvenuto, as this is mostly a bad interaction between |
| Comment by Andrew Morrow (Inactive) [ 24/Jun/16 ] |
|
Command line options parsing occurs as part of the mongo initializer chain. If, during options processing, we find the --version flag, we then print the version info and terminate. However, also during mongo initializer execution, we call ProcessInfo::SystemInfo::collectSystemInfo so that we can obtain the page size. We need the page size so that we can use the SecureAllocator to protect security relevant command line options. As a result, we (must) call SystemInfo::collectSystemInfo before we have examined the command line options. Within SystemInfo::collectSystemInfo we log the status of the Hotfix if we find that we are running on system that would be affected by the underlying MS KB issue. As a result, we end up logging before we even have examined the command line options, so the Hotfix log line is emitted even when --version is present. The best short term solution is probably to issue the message about the KB/Hotfix as a startup warning from within logMongodStartupWarnings, rather than as a bare log within the processinfo_windows.cpp file. However, this is a stopgap solution. Any call go log() in library code called from the mongo initializer chain is suspect: if it becomes scheduled before options processing in the initializer dependency graph, this issue will resurface as a regression. There is no easy way to prevent this from happening. One possibility might be to make the mongo log() buffer, rather than write to stdout/stderr, until after the mongo initializers are all complete. schwerin - Any thoughts? |
| Comment by David Golub [ 22/Jun/16 ] |
|
I just discussed this on Slack with ramon.fernandez. I had misinterpreted how it was classified, specifically the use of the term "backlog." My mistake. |
| Comment by David Golub [ 22/Jun/16 ] |
|
I believe that this ticket is incorrectly prioritized. It is critical that this bug not be included in any production release of MongoDB, as doing so will break automation on Windows with existing versions of the Automation Agent. While it doesn't have to be fixed tomorrow, it does need to be fixed before MongoDB 3.4 and should not be put on the back burner indefinitely. I expect that this will probably be a trivial fix involving moving a few lines from one place in the code to another, so I doubt it will require a large time investment. |
| Comment by David Golub [ 03/Jun/16 ] |
|
The message is displayed when actually starting a mongod process with older versions, but only 3.3.6 displays it when running mongod --version. Also, I'm not sure why this was changed to be an improvement rather than a bug. It will break automation on Windows if included in a production release, so it should be treated as critical. |
| Comment by Mark Benvenuto [ 03/Jun/16 ] |
|
The warning message is in 2.6 and later releases. An update to fix this for later Windows 7 kernels was made recently. |