A script like:

#!/bin/sh
stop ui
rm /var/run/disable_chrome_restart
start ui 
sleep 1
touch /var/run/disable_chrome_restart

can work around this but it seems horrible.

Anyone know who the right owner for this would be these days?

I think all we need is to check this only if it's ever started once.

https://cs.corp.google.com/chromeos_internal/src/platform2/login_manager/browser_job.cc?rcl=404c6cd98a4e651bae64b27dfd740f7ffade9ec5&l=80

derat@ am I correct? If so, I can work on a fix.

I don't have any inside knowledge about why this was originally added, seemingly six years ago (!) by http://codereview.chromium.org/479011.

It looks like it initially had the behavior that's requested in this bug, though, so restoring that sounds fine to me.

Thank you for checking!

Bulk closing Infra>Client>ChromeOS issues untouched in over a year.

I'm reopening this issue, it still seems to be broken as described.
"touch run/disable_chrome_restart && restart ui" definitely seems to not run chrome.
I'm not sure how important this feature is, but it's worth triaging or keeping open.

I'm happy to fix the code to only disable restarts. Can you describe the use case(s) for this, though? The code is lacking in descriptions of why it's there.

Moving out of the Chrome OS infra triage queue as this isn't something we can directly help with.

I'll delete this code if nobody needs it anymore.

Uploaded https://crrev.com/c/1177187 to remove support for checking the file if nobody objects.

Per Robert on https://crrev.com/c/1177187 :

"What I want:

* on boot or start ui, Chrome starts.
* if Chrome crashes, it waits and doesn't re-start,"

I've experimented with making the ui-respawn script (rather than session_manager) check /var/run/disable_chrome_restart. It looks like session_manager still tries to restart Chrome a few times before exiting (which makes ui-respawn run), though.

If it's okay for Chrome to crash and restart a few times before we give up, I think that that part may already work (on dev-mode systems) without any changes. ui-respawn avoids rebooting if:

  crossystem "cros_debug?1"

returns 0. I think that that corresponds to being in dev mode, so I'm confused if developers are seeing their systems reboot.

Robert, can you double-check whether you're still seeing your system reboot if Chrome crashes at startup? If so, can you check what that crossystem command returns and also check what ui-respawn is logging to /var/log/messages?

Alternately, is the issue that sshd takes a long time to start when Chrome is crashing, or that it's hard to switch to the terminal with Ctrl+Alt+F2 while Chrome is crashing?

Irrespective of all this, I'll try to clean up ui-respawn a bit since it's a mess.

I'm out of the office (took detour on way back from Vancouver) but will update per above when I'm back in the office.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/c22e6b5617ba4d8d78a80d34ed777c6a57704ede

commit c22e6b5617ba4d8d78a80d34ed777c6a57704ede
Author: Daniel Erat <derat@chromium.org>
Date: Thu Aug 23 14:37:11 2018

login: Refactor ui-respawn.

Update the ui-respawn script that's responsible for
restarting the "ui" Upstart job after session_manager
exits. No functional changes intended; just remove a bunch
of hard-to-read nesting and repetitive logging calls.

BUG=chromium:597101
TEST=sent SIGABRT to chrome over and over again; verified
     that "Respawning ui." is logged at first and then "Not
     auto-rebooting due to debug mode."

Change-Id: If60ba9ee0167557193f2cd966e872b06de354f7a
Reviewed-on: https://chromium-review.googlesource.com/1180471
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/c22e6b5617ba4d8d78a80d34ed777c6a57704ede/login_manager/init/scripts/ui-respawn

Have you had a chance to get more info about the behavior that you're currently seeing, Robert?

Please reassign this back to me after answering the questions in #14.