Moving relevant part of email conversation here:

----

On Wed, Jun 14, 2017 at 2:50 PM, Sadrul Chowdhury wrote:
On Wed, Jun 14, 2017 at 12:08 PM, Mattias Nissler wrote:
> > FWIW, my understanding is that session_manager checks
> > the PID that sent the message is identical to the PID
> > that it fork()ed to run the browser. +1 to the idea
> > of comparing PIDs seen by session_manager - I guess
> > I'd bet some money that they'll not match ;-)
> 
> I think so too. The cros session-manager (process A)
> launches 'chrome --mus' (process B), which is used as
> the chrome service-manager process, which then forks
> again the create the chrome-browser process (process C).
> Process A expects the restart request to come from B,
> but with --mus/--mash, the restart request is coming
> from C. This is my understanding of how things are right
> now. So we would have to find a way for C to trigger the
> restart request from B.

Or alternatively change the logic in session_manager to
allow C to invoke the method. It's unclear to me how to do
this safely though (we specifically don't want to allow
non-browser-processes to trigger chrome restarts).

Is chrome --mus running a background service manager in the main browser process, or a separate parent service manager process (like in the old mash_runner days)?

What about chrome --mash?

Yes to both, per:
https://cs.chromium.org/chromium/src/chrome/app/chrome_main_delegate.cc?rcl=0607b7981ab9de1b2bbfc1de6a9ae2c2fb70786b&l=1132

I assume we don't actually want that in the "mushrome" case at least

Ken, service_manager is currently in its own separate process (main process launched by chrome --mus), and the browser process (i.e. content_packaged_services process) is the child of it - is this not correct?
When you say we don't want that in the "mushrome" case - what do you mean?

That is correct.

I thought the mushrome config was to have mus+ash embedded in the browser
process, in which case having a separate service manager seems like a
pointless exercise which adds unnecessary complexity.

Of course if that's not what mushrome is, then you can ignore that comment.
I have trouble keeping track of what the codenames mean and/or are supposed
to mean. :)

Yes, the current plan for Mushrome is to have Mus Window Server, Ash, and Chrome all in the same process. Display Compositor/GPU Service ("viz" is the new name) would still be in a separate process though (at least when we are done with WS/GPU split). Do you think that would warrant keeping the service_manager separate as well? We haven't discussed moving the service_manager in-process until now.

Additional, moving WS into the same process as Chrome and Ash, is proving to be a bit of a challenge because of various overlapping singletons and thread safety restrictions. Perhaps moving service_manager in-process would be easier, but I am a little paranoid :)

The decision comes down to one simple constraint: do you want any service
to be able to run without the browser process being up. If not, there is no
point in making the service manager a separate process.

Service Manager is not a very complex component and it has no such issues
(we already run one in-process in production Chrome). Changing the behavior
for mushrome is not particularly difficult: it requires removing a few
lines of special-case handling of "--mus" in the startup code, and probably
updating a catalog somewhere.

Ok, then I guess it makes sense to run service manager in-process in Mushrome. That should also fix the issue described in this bug for the Mushrome case.

I'm closing out assuming this is stale.