I have traced this issue to the field "profile.sync_password_hash" in the profile Preferences.

If I remove this entry from all profiles in the user-data-dir, Chrome starts once again.

This occurs also on the beta channel (67).

In case it's relevant, I'm using the basic (unencrypted) store for passwords:

From chrome_debug.log:
[25797:25797:0508/200803.093624:VERBOSE1:key_storage_util_linux.cc(53)] Password storage detected desktop environment: GNOME
[25797:25797:0508/200803.093652:VERBOSE1:password_store_factory.cc(213)] Trying libsecret for password storage.
[25797:25797:0508/200803.099557:VERBOSE1:password_store_factory.cc(227)] Trying GNOME keyring for password storage.
[25797:25797:0508/200803.102119:WARNING:password_store_factory.cc(240)] Using basic (unencrypted) store for password storage. See https://chromium.googlesource.com/chromium/src/+/master/docs/linux_password_storage.md for more information about password storage options.

My desktop environment is a minimal MATE environment, far from standard. No key store.

Unable to reproduce the issue on chrome reported version 66.0.3359.139 using Ubuntu 14.04 with steps mentioned below:
1) Launched chrome reported version through terminal using: mkdir /tmp/x; /opt/google/chrome/chrome --user-data-dir=/tmp/x
2) Signed in into chrome chrome from Chrome://settings
3) Exit the browser using "Ctrl-Shift-Q"
4) Again launched chrome through terminal using: /opt/google/chrome/chrome --user-data-dir=/tmp/x, chrome window got opened

Note: Tested the issue on Ubuntu 14.04, as this issue was reported on Debian unstable, as ET team doesn't have Debian unstable to test on it, so forwarding this issue to Inhouse to check and confirm the issue on Debian, hence adding TE-NeedsTriageFromHYD label to it.

Thanks!

Deleted: 840758.ogv 5.8 MB

	840758.ogv 5.8 MB View Download

I have done some more testing and I believe it is related to the basic (unencrypted) password store mentioned in comment 3.

I installed gnome-keyring and seahorse on my Debian unstable machine. I started chrome with the profile saved after step 3 of the reproduction steps and chrome started. I first got a prompt to create a password for the "Default keyring" and then the browser window opened. Subsequent attempts to start chrome (again from the saved profile) had the window open as usual (albeit with a sync error as the password store/keyring would not have had my chrome sync credentials).

I then removed gnome-keyring and seahorse, killed the gnome-keyring process, and started chrome again from the saved profile. The browser window now did not open, as per the original report.

I have tried the same test to reproduce this issue on my laptop, which is also Debian unstable, but I have failed to reproduce it. I did a "apt upgrade" on each machine prior to performing the test to ensure the same versions of libraries were present on each machine and I did the tests at the same time.

A colleague has also tried to reproduce the issue and has failed to do so.

My desktop continues to exhibit the issue.

One difference: My laptop is on kernel 4.14, the desktop on 4.16. I'll reboot my laptop into 4.16 and re-test.

I will also run a bisection on my desktop to see if the problem can be tied to a chrome version or not - it is possible that an external change (kernel perhaps) has triggered a latent issue in chrome.

Tested the issue using #66.0.3359.139 on Linux Debian Rodete Lenovo laptop and could launch the Chrome as per the steps mentioned below

Steps:
1) Launched chrome reported version through terminal using: mkdir /tmp/x; /opt/google/chrome/chrome --user-data-dir=/tmp/x
2) Signed in into chrome chrome from Chrome://settings
3) Exit the browser using "Ctrl-Shift-Q"
4) Again launched chrome through terminal using: /opt/google/chrome/chrome --user-data-dir=/tmp/x, chrome window got opened

Removing bisect label since this issue seems to be kernel side as per comment #6.

Thanks!!

As per comment#6 by reporter "an external change (kernel perhaps) has triggered a latent issue in chrome" and it is also mentioned that the issue is not seen on his Debian laptop. As of now ET team doesn't have the setup to check and confirm the issue, hence adding label TE-Hardware-Dependency.

Thanks!