Chrome won't start after renaming your machine (hostname change) on Fedora

Symptom

You renamed your machine (hostnamectl set-hostname), and Google Chrome no longer starts. Clicking the launcher shows a spinner for a few seconds, then nothing happens — no window, no error dialog, no crash report.

Launching Chrome from a terminal reveals the real error:

/opt/google/chrome/google-chrome

ERROR:chrome/browser/process_singleton_posix.cc:365] The profile appears to be
in use by another Google Chrome process (37903) on another computer (fedora).
Chrome has locked the profile so that it doesn't get corrupted. If you are sure
no other processes are using this profile, you can unlock the profile and
relaunch Chrome.

ERROR:chrome/browser/ui/views/message_box_dialog.cc:200] Unable to show message
box: Google Chrome - The profile appears to be in use by another Google Chrome
process ...

The second error explains the silence: Chrome cannot display its warning dialog because no browser UI exists yet, so the process just exits.

Root cause

Chrome protects a profile against concurrent access from two machines sharing the same $HOME (a common NFS setup). The mechanism is a symlink in the profile directory whose target encodes hostname-pid:

ls -l ~/.config/google-chrome/SingletonLock

lrwxrwxrwx. 1 user user 12 Jul 17 17:45
  /home/user/.config/google-chrome/SingletonLock -> fedora-37903

Three lock files work together:

File	Target	Role
`SingletonLock`	`hostname-pid`	Identifies the owning host and process
`SingletonSocket`	`/tmp/.com.google.Chrome.XXXXXX/SingletonSocket`	IPC endpoint used to forward new URLs to the running instance
`SingletonCookie`	random number	Validates the socket handshake

At startup, Chrome reads SingletonLock and compares the encoded hostname to its own. If they differ, it assumes another computer holds the profile and refuses to start — the PID check is skipped, because a PID from another host is meaningless.

The lock is created at launch and removed at clean shutdown. Renaming the machine while Chrome is running therefore leaves a lock that can never match again: the value written at launch (fedora-...) is frozen, while the host is now newname. If the browser is then killed, crashes, or the session ends before a clean exit, the stale symlink survives every reboot.

This affects every Chromium-based browser (Chromium, Microsoft Edge, Brave, Opera, Vivaldi) and Electron applications (VS Code, Slack, Discord), which all inherit the same ProcessSingleton implementation.

Solution

Confirm that no Chrome process is actually running:

pgrep -af chrome

If the command returns nothing, delete the stale lock files:

rm -f ~/.config/google-chrome/Singleton{Lock,Socket,Cookie}

Relaunch:

/opt/google/chrome/google-chrome

Chrome starts normally and recreates the locks with the current hostname. No further action is required — the fix is permanent as long as the hostname stays stable.

If pgrep does return live processes, terminate them first. Deleting the locks while an instance is running defeats the protection and risks the exact profile corruption it guards against:

pkill -f google-chrome

Other browsers

Same procedure, different profile directory:

rm -f ~/.config/chromium/Singleton{Lock,Socket,Cookie}
rm -f ~/.config/microsoft-edge/Singleton{Lock,Socket,Cookie}
rm -f ~/.config/BraveSoftware/Brave-Browser/Singleton{Lock,Socket,Cookie}

A generic sweep, useful when several browsers are stuck at once:

find ~/.config -maxdepth 3 -name 'Singleton*' -type l

Inspect the list before deleting anything, then:

find ~/.config -maxdepth 3 -name 'Singleton*' -type l -delete

Verify

ls -l ~/.config/google-chrome/SingletonLock
hostname

The symlink target must now start with the current hostname.

Prevention

Rename the machine cold — close all Chromium-based and Electron applications before running hostnamectl set-hostname, or perform the change and reboot immediately:

sudo hostnamectl set-hostname newname
sudo reboot

For kiosk or appliance setups where the hostname is assigned dynamically (DHCP, cloud-init, Raspberry Pi images), remove the lock at every boot rather than fighting the symptom:

rm -f ~/.config/google-chrome/SingletonLock

Notes

The message box error (message_box_dialog.cc) is what makes the failure silent. Always launch a non-starting GUI application from a terminal before investigating further — the useful diagnostic is on stderr.
Do not confuse this with the “Google Chrome cannot determine or set the default browser” message. That one comes from xdg-settings failing to find a matching .desktop file, and is typical of the Flatpak build of Chrome, which registers as com.google.Chrome.desktop while the browser looks for google-chrome.desktop. Installing the official RPM resolves it.