Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-5520

Shutdown rewrite (tracking ticket)

    • Type: Icon: New Feature New Feature
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Internal Code
    • Labels:

      This ticket is the dual of SERVER-5112. The result of SERVER-5112 is that the server has a very explicit initialization system that ensures a well defined initialization order. Each subsystem can define its own startup code, and specify exactly what it depends on and what depends on it. In particular, this solved the "static initialization order" issue, in which constructors for statically defined classes run in an undefined order at before main() gets called.

      The shutdown process needs similar attention. There is some "shutdown" code that needs to be run when the server is shutting down. However, this code is often run implicitly in destructors, or is lumped all together with process exit.

      To start, we have duplicated definitions of the "dbexit" function, which is the entry point to the shutdown system.

      One for mongos:
      And one for mongod:

      This function is the entry to point to the current shutdown process in the server. The fact that these signatures are identical (and used from some libraries that both mongod and mongos share) and have diverged shows that the shutdown process has not been properly factored out. "server.cpp" is the main() for mongos, and "instance.cpp" is a legacy file with old file and process related code.

      There is also an "inShutdown" function, of which there are also multiple definitions:


      This function is effectively in place as a way to notify other parts of the server that we are shutting down. However, this function is not thread safe, and it is not clear when this call is needed. This could potentially be replaced by some more explicit notification of the various components that need to be notified of shutdown.

      Finally, the "dbexit" call, in addition to shutting down the database components, also exits the process. This lack of separation is a problem specifically for the tools, since some tools internally start up a database server to enable the "--dbpath" direct data file access functionality. This means that when the server gets shut down, the process exits which means the tools have limited control over how the process exits in this case. See SERVER-9473, SERVER-8064, and SERVER-1994.

            schwerin@mongodb.com Andy Schwerin
            ian@mongodb.com Ian Whalen (Inactive)
            0 Vote for this issue
            7 Start watching this issue