borisv@ and norberg@ this looks exactly like the issue which we looked on Friday. 

I am afraid that this problem seems different. The machine has a system updater present, but the system agent is not able to talk to the system daemon. It would be great if we can repeat the installation and then see what is happening.

1. Install the latest version of the updater (as of last week 1.2.8.82), from the link in the error message: https://dl.google.com/mac/install/googlesoftwareupdate.dmg:
  a) Open the DMG file
  b) Launch "Install Google Software Update" app and follow the instructions.
2. Open the Terminal app
3. Copy paste the command below as one line:
/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/ksdiagnostics

4. Press 'Enter'. The command may ask for an administrator password. Supplying such will help, but the command will collect useful information even without it.
5. Attach to this bug the generated .zip file with the diagnostic reports.

1. Installed updater 1.2.8.82.
2. Attempted to update by visiting updater page in settings (chrome://settings/help)
3. Received error 12 again.
4. Quit Chrome, restarted.
5. Attempted to update in settings again
6. Received error 12 again.  Transcript: 

2017-08-08 00:00:12.132 GoogleSoftwareUpdateAgent[51630/0x70000e727000] [lvl=3] -[KSAgentApp(KeystoneThread) runKeystonesInThreadWithSettings:] Failed to connect to system update engine from the system agent. Please download and reinstall Google Software Update from https://dl.google.com/mac/install/googlesoftwareupdate.dmg
2017-08-08 00:00:12.135 GoogleSoftwareUpdateAgent[51630/0x70000e727000] [lvl=3] -[KSUpdateEngine updateProductID:] KSUpdateEngine no ticket to update for the specified product ID. (productID: com.google.Chrome) [com.google.UpdateEngine.CoreErrorDomain:3003]

ksdiagnostics update to come

In comment 3, for "4. Quit Chrome, restarted."

I mean that I restarted Chrome, not my Mac.

I just rebooted (into OS X 10.13 beta 5), and the same error recurred.

Also, just to confirm: did someone delete the ksdiagnostics output? 

Thanks a lot, could you please send the diagnostics file directly to my email borisv@chromium.org. Unfortunately, long time ago we had a bug where this report would leak the user name, say 'borisv' as a side effect of listing updater files (/Users/borisv/...). This was fixed more than a year ago (we now mask it with "USER"), but one of my colleagues have probably written a script to delete ksdiagnostics attachments from bugs to avoid leaking of PII data. I will follow up on that internally to make sure that we don't delete these anymore.

Actually, never mind. I have access to deleted comments, so I was able to obtain the .zip file.

Hmm, it took awhile, it seems like the Google Software Update (Keystone) daemon is disabled: 
"/Library/LaunchDaemons/com.google.keystone.daemon.plist: Service is disabled"

Can you try the sudo command below in the Terminal app to re-enable the daemon? Then retry checking for updates - the updates should succeed.

sudo launchctl load -w /Library/LaunchDaemons/com.google.keystone.daemon.plist

That fixed it.  This is apparently not a bug.  Thanks!

When I searched for steps to remedy this issue, I didn't find this proposed.  Would it make sense to have customer service put this command in their document?

https://support.google.com/chrome/answer/111996?hl=en

Thanks, do you recall disabling the daemon explicitly? I know it has been an year, but this will strongly help us narrow the reason. If it requires an explicit action, the priority would be lower. However, if disabling is a side effect of OS or Chrome update, then I am way more concerned.

In both ways, I will probably modify slightly the code in the updater installer, so that it re-enables the service. This way when the users click the link in the error message and follow the installation steps, updates will be auto-recovered.

I do not recall disabling it explicitly, and I don't have a record of disabling it in my .bash_history (although, if I did, I suspect it would have long left my .bash_history).

There is a chance that I disabled it explicitly when I was first trying to fix the lack of updates, but when I searched for troubleshooting steps, none of them said to try that. 

Also, I couldn't find any references in Google to 
"sudo launchctl unload -w /Library/LaunchDaemons/com.google.keystone.daemon.plist" that applied to fixing Chrome updates.

...which is all a very long-winded way of saying that I *probably* did not disable it, but I can't be sure.  

One more thing: when I was attempting to fix this, I did attempt to uninstall with this:

/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/ksinstall --uninstall

Yes, when I reproduced it locally, I noticed that explicit uninstall will not solve the problem, as disabling status is preserved even when the daemon is unloaded.

Some users describe problems with unloading and re-loading daemons on macOS 10.10 causing the daemon to be disabled. We are not able to reproduce this in our test labs, but it is possible than an unstable OS update has caused this.

I already implemented a change internally in the updater installation. It will ship with the next version of the updater. Thank you for your help with tracking the problem! This will help other users who encounter it. Furthermore, we may be able to recover them automatically from Chrome itself.

Fixed with internal b/64493881.