Today, during initializing mongod process , a default fast clock source of the global ServiceContext is configured (code) before initiating the signal handler thread. Shortly afterward, a new background thread fast clock replaces the default clock source on ServiceContext, automatically causing the default fast clock source to be destroyed. This workflow creates an issue where the signal handler thread still retains the pointer of the destroyed fast clock source (code), leading to segmentation faults when attempting to use it. Here is the current work flow:

• disable multithreads
• makeServiceContext with a default fast clock source
• register the shutdown task that refers to ServiceContext(code)
• set sigmask to block the exclusive SignalHandler signals
• enable multithreads
• spawn signal handler thread (code)
• [SignalHandlerThread]:
  • unmask signals
  • enter loop dispatching handler actions to registered shutdown tasks if configured
• serviceContext->setFastClockSource
  • start the fastClockSource's background thread (code)

In this ticket, we want to fix the issue by enhancing the work flow to be:

• disable multithreads
• set sigmask to block the exclusive SignalHandler signals
• enable multithreads
• spawn signal handler thread.
• [SignalHandlerThread]:
  • unmask signals
  • enter loop dispatching handler actions
• makeServiceContext
• serviceContext->setFastClockSource
  • start the fastClockSource's background thread
• register the cleanupTask that refers to ServiceContext now that it's configured. 

The mongos initialization should also be changed in the similar way.