[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:
Related
related to SERVER-14992 Query for Windows 7 File Allocation F... Closed
related to SERVER-23277 Hotfix KB2731284 or later update is i... Closed
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.

CC mark.benvenuto



 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: SERVER-24395 Do not display startup warnings when querying for version
Branch: master
https://github.com/mongodb/mongo/commit/cc38d23180248e5c5a6b21adf6ee7a2b4e670f0f

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 SERVER-23570 and SERVER-14992.

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.

Generated at Thu Feb 08 04:06:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.