Minor - P4 Occasionally mongorestore fails to start with the following call stack:
sh27974| 2014-03-14T15:46:07.210-0400 [journal] Fatal Assertion 16842 sh27974| 2014-03-14T15:46:07.210-0400 jstests/dur/data/empty.bson sh27974| 2014-03-14T15:46:07.210-0400 going into namespace [test.empty] sh27974| 2014-03-14T15:46:07.213-0400 [journal] 0x10068edeb 0x100648712 0x10063827e 0x1000a33cc 0x10010a5f2 0x1001d2502 0x1006c31f5 0x7fff8c9257a2 0x7fff8c9121e1 sh27974| 0 mongorestore 0x000000010068edeb mongo::printStackTrace(std::ostream&) 43 sh27974| 1 mongorestore 0x0000000100648712 mongo::logContext(char const*) 114 sh27974| 2 mongorestore 0x000000010063827e mongo::fassertFailed(int) 110 sh27974| 3 mongorestore 0x00000001000a33cc mongo::getGlobalAuthorizationManager() 28 sh27974| 4 mongorestore 0x000000010010a5f2 mongo::Client::initThread(char const*, mongo::AbstractMessagingPort*) 640 sh27974| 5 mongorestore 0x00000001001d2502 mongo::dur::durThread() 34 sh27974| 6 mongorestore 0x00000001006c31f5 thread_proxy 229 sh27974| 7 libsystem_c.dylib 0x00007fff8c9257a2 _pthread_start 327 sh27974| 8 libsystem_c.dylib 0x00007fff8c9121e1 thread_start 13 sh27974| 2014-03-14T15:46:07.214-0400 [journal] sh27974| sh27974| ***aborting after fassert() failure sh27974|
This is because when the durThread starts it calls client::initThread, which calls getGlobalAuthorizationManager(), which has an fassert that the globalAuthorizationManager is set. In the run method of mongorestore, however, we briefly clear the globalAuthorizationManager to set it to a real implementation instead of a Mock. This leaves a small window where the globalAuthorizationManager is unset, which can trigger the fassert in getGlobalAuthorizationManager depending on the timing of the dur thread starting up.
Fix is to move the setting of the globalAuthorizationManager out of the Restore class' doRun method and into its constructor, which will run before the durThread is started.