I've been operating under the impression that since I embed my MultiDeviceSetupService in the browser process, it will be destroyed upon logout/shutdown. Ken, I believe you alerted me of this when I was originally implementing the service. Do I need to add some special handling instead?

James is correct; they're guaranteed to be shut down only if run on the IO thread. See this thread: https://groups.google.com/a/chromium.org/forum/#!topic/services-dev/orJmSM0Bb-E.

Note that in that thread I produced a proposal for this problem, but I never implemented it.

+sky just FYI

If the design decision is that embedded services leak at shutdown, that's fine with me, I just didn't know that and was surprised.

Personally I think that it's incongruous that embedded services are shut down if they're run on the IO thread but not otherwise. It makes more sense from my POV to either (a) just leak all embedded services and be very clear about that, or (b) leak embedded services by default but provide a mechanism for services to specify that they should be shut down (this is similar to the proposal we ended up at on the email thread IIRC). However, I don't have any cycles to make changes here, so these are just like, my opinions, man.

I don't think we want to adopt a policy of leaking by default in the browser process, since it can pretty easily mask real leaks.

As discussed in the thread you linked, the process simply shouldn't shut down until all its embedded services have quit on their own volition. Because we are far from living in that world however, it seems reasonable to allow embedded services to force their quit tasks to block shutdown as you suggested.