midis sometimes does not start on chrome crash. |
|
Issue descriptionOn Chrome crash, session_manager tries to shutdown the ARC related services, including midis. However, in some cases, emitting stop-arc-instance may fail. On my local test I obtained the following log; 2018-10-17T13:57:16.732103+09:00 ERR session_manager[1357]: [ERROR:object_proxy. cc(581)] Failed to call method: com.ubuntu.Upstart0_6.EmitEvent: object_path= /c om/ubuntu/Upstart: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the messag e bus security policy blocked the reply, the reply timeout expired, or the netwo rk connection was broken. 2018-10-17T13:57:16.732394+09:00 ERR session_manager[1357]: [ERROR:session_manager_impl.cc(1701)] Emitting stop-arc-instance impulse failed. In the case, midis does not stop (so not restart). Because midis tracks Mojo connection, the reconnection attempt from new Chrome instance fails. IIUC, similar to other ARC services, we should add "stopping ui" or "stopped ui" to stop condition. I'm not sure which is preferred, though. Yusuke, Dylan, what do you think?
,
Oct 19
I agree it's good to align the stop condition of midis with other services. But why does emitting stop-arc-instance fail?
,
Oct 26
Did dbus crash anywhere? You'd see "dbus-daemon exited unexpectedly" in /var/log/messages. I wouldn't think it's that, but we should rule it out. Did the error message occur 25 second after the initial dbus message was sent? If so, I'm guessing one of the jobs hung while it was executing it's stop code. You might be able to determine which one from the logs. I can take a look if you can point me to them. |
|
►
Sign in to add a comment |
|
Comment 1 by yusukes@chromium.org
, Oct 18