Currently it is possible for services to deadlock with ServiceManager. This occurs if ServiceManager is tearing down services, and a child process is currently blocked waiting on a mojo call.

ServiceManager::Instance will delete its ServiceProcessLauncher which blocks on shutting down the child process.

mojo::Binding::WaitForIncomingMethodCall, when called from a child process will block indefinitely until an appropriate signal is called.

If the child service is waiting on a service which never starts before ServiceManager shutdown, then the wait method never exits.

Normally it is expected that the pipe closure would interrupt the wait. However when this occurs MessagePipeDispatcher::OnPortStatusChanged is never called.

An example of this can be seen in mash_browser_tests.
  quick_launch blocks on UI service
  ServiceManager tries to shutdown quick_launch before UI service has started
  ServiceManager blocks on trying to shutdown the child process
  quick_launch never gets OnPortStatusChanged, and stays in WaitForIncomingMethodCall

A similar timeout appears to be occurring with local_state, but I haven't debugged what local state is blocking on.

I have a proposed change which introduces timeouts on both side of the boundary: https://chromium-review.googlesource.com/c/chromium/src/+/624528

However I haven't debugged the root cause, of why the OnPortStatusChanged is never received.

With the patch, after the timeout, the child process can poll the pipe state to be told that the peer has closed. Without ever getting the notification.