Dan, is this something you could maybe get to in M-59? A delay on logout translates to a delay to restart, which is something we're trying to really keep locked down.

On a relatively fast machine like a link, we were seeing a 1s delay - it is probably longer on slower machines.

(tentatively assigning milestone, feel free to move if it isn't feasible)

This happened in M42 but just got filed now? How did that happen?

I agree that slow logout is bad since it blocks the next login, but I don't understand what's being tracked here.

https://chromium-review.googlesource.com/c/252803/ looks like it updated session_manager to wait for Chrome's entire process group to be gone instead of just the browser process (note that the BUG= line appears to be wrong). I think that this is the correct behavior.

The ui-post-stop script, which runs after session_manager exits, kills any remaining chronos processes. This script appears to use kill -9, so it's possible that it's faster than what session_manager is doing (since I think that session_manager sends TERM first and then waits a bit for processes to exit before sending ABRT). I think that it's still better to kill these processes gracefully to avoid data loss.

In any case, it sounds like the underlying problem is that Chrome isn't exiting as fast as we'd like. I think that that's the thing that needs to be scrutinized. I assume that we don't want to revert this two-year-old change that made session_manager do a better job of cleaning up Chrome.

Sonny has been investigating why our logout/restart is so slow. Among a few other issues which he found, this was one of them.

AFAICT, we used to wait on the browser process to terminate already, now we're waiting for its descendants also to exit. Do we know if this is really necessary? For example, would the renderer processes have any state to save? In any case, identifying which processes these are, is probably a good start.


Sonny, since you are already investigating this and have the devices setup, could you, on ToT, verify which processes in this process group are taking the longest to cleanly terminate?

It seems this might take some non-trivial instrumentation of session_manager.

After more inspection, it seems that the kernel CL (https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2fd20b643abb417a0de3b8d369728e09013413eb) is the cause of the delay. I suspect this causes some delay in display/graphics related operation, and the session manager wait would have been okay if without this display/graphics delay.

This kernel change is required for correctness, so there isn't much we can do about it. Also the reason for the long delay is the panel timing requirements on link which are crazy high. In short, the hardware is imposing this delay on us and there is nothing I can do about it.

Some idea for restart to happen faster is not to get drm_framebuffer_remove to get called during it. I.e. make FB owned not by Chrome, but by something else which is alive through Chrome restarts.

 Issue 705154  has been merged into this issue.