I'm not aware of anything that restarts the process.  Adding a bunch of other people.

I tested this locally on dev and I'm seeing similar behavior:

1.) Launch Chrome Dev, adb shell ps | grep chrome
u0_a111   13813 3457  1210896 107396 SyS_epoll_ 0000000000 S com.chrome.dev
u0_a111   16846 3457  1106524 49408 SyS_epoll_ 0000000000 S com.chrome.dev:privileged_process1
u0_i59    18023 3457  1011788 39024 SyS_epoll_ 0000000000 S com.chrome.dev:sandboxed_process1

2.) Swipe Chrome Dev away, adb shell ps | grep chrome
u0_a111   18121 3457  1010716 33120            0000000000 R com.chrome.dev

Followed shortly by:
u0_a111   18121 3457  1013448 40600 SyS_epoll_ 0000000000 S com.chrome.dev

--- I don't know what is triggering the alarm, but looking at
adb shell dumpsys alarm

Batch{4e276b num=1 start=74136313 end=74136313}:
    RTC #0: Alarm{90b92c8 type 1 when 1483642002153 com.chrome.dev}
      tag=*alarm*:com.chrome.dev/com.google.ipc.invalidation.external.client.contrib.AndroidListener$AlarmReceiver
      type=1 whenElapsed=+831ms when=2017-01-05 10:46:42
      window=0 repeatInterval=0 count=0 flags=0x0
      operation=PendingIntent{f569f61: PendingIntentRecord{2779a86 com.chrome.dev broadcastIntent}}

  u0a111:com.chrome.dev +51s727ms running, 0 wakeups:
    +41s412ms 0 wakes 372 alarms, last -4s213ms:
      *alarm*:com.chrome.dev/com.google.ipc.invalidation.external.client.contrib.AndroidListener$AlarmReceiver
    +28s928ms 0 wakes 134 alarms, last -26s978ms:
      *alarm*:com.chrome.dev/com.google.ipc.invalidation.ticl.android2.AndroidInternalScheduler$AlarmReceiver
    +136ms 0 wakes 4 alarms, last -4h45m58s462ms:
      *alarm*:org.chromium.chrome.browser.omaha.ACTION_REGISTER_REQUEST

Could this be sync based on the invalidation alarm stuff?  Do we expect this to be called with Chrome dead?  I assume it is not loading the native library and is likely a very light weight process anyway?

This might be working as intended, but I don't know.

The Omaha stuff definitely sets an alarm to fire some point after Chrome has launched because it uses an IntentService.  That'd be working as intended, though.

I know that prefetch feature starts Chrome occasionally to do prefetches, but that it would happen immediately after a process is killed would be strange. The only other use I know of is when chrome://flags are modified, we restart by killing the process and setting an alarm to restart Chrome, but the repro doesn't seem to support this scenario.

Original reporter, adding a logcat from your phone to this bug report would be helpful.

Invalidation code also uses timers to do their work, ending up in an IntentService. But they don't load the native blob by doing that, so the impact is not the same as loading up all of Chrome.

Dear Chrome engineer,
I've attached log.txt and it tells us that AlarmReceiver creates Chrome process

01-09 11:22:23.172   866   879 I am_proc_start: [0,8973,10048,com.android.chrome,broadcast,com.android.chrome/com.google.ipc.invalidation.ticl.android2.AndroidInternalScheduler$AlarmReceiver]
01-09 11:22:23.172   866   879 I ActivityManager: Start proc 8973:com.android.chrome/u0a48 for broadcast com.android.chrome/com.google.ipc.invalidation.ticl.android2.AndroidInternalScheduler$AlarmReceiver

Deleted: log.txt 141 KB

log.txt 141 KB View Download

So looks like this is invalidation code. Tommy, is there any way to say whether these alarms are firing as expected?

They are expected, but I'm not sure how to remove them. At some point in the future we'll probably fully move away from Tango anyway, which would remove the issue. But for now, it might not be very easy to fix.

Same issue is observed in Chrome v60.0.3112.116.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+tschumann for posterity.  We are looking at migrating away from Tango, so hopefully this is no longer an issue.