Brave profile locked after changing network hostname on Linux

Browser Support
, , ,
1

Description of the issue:
Brave reports “profile in use by another process” after changing the network hostname.

[71346:71346:1117/150207.094641:ERROR:process_singleton_posix.cc(358)] The profile appears to be in use by another Brave process (2200756) on another computer (<old_hostname>). Brave 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 Brave.
[71346:71346:1117/150207.094778:ERROR:message_box_dialog.cc(190)] Unable to show message box: Brave - The profile appears to be in use by another Brave process (2200756) on another computer (<old_hostname). Brave 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 Brave.

❯ hostname
<a_different_hostname>

Steps to Reproduce (add as many as necessary):

  1. Change the network hostname of the machine.
  2. Attempt to launch Brave Browser.

Actual Result:
Brave displays an error that the profile is locked by another process.

Expected result:
Brave should launch without errors.

Reproduces how often:
Always, after changing the hostname.

Operating System and Brave Version (See the About Brave page in the main menu):
Linux, Brave Version [Brave Browser 130.1.71.121].

Additional Information:
Removing ~/.config/BraveSoftware/Brave-Browser/SingletonLock resolves the issue.

2

Looks like you have the solution, and running

rm ~/.config/BraveSoftware/Brave-Browser/SingletonLock

in the command line, is a step of the process in which a Linux OS Brave Browser user changes the Linux OS PC machine’s hostname.

3

The issue is that Brave does not explain how to unlock or fix this issue. This is simply a workaround until someone at Brave responds with the appropriate steps. Thanks for your reply.

4

OK, you have a request similar to:

5

@ArandomUserName,
This is not something that comes up particularly often. As such, the team is not likely willing to sink the time into auto-detecting/auto-fixing this issue when it occurs at this time.

That said, I have opened this issue to at least improve the error messaging to inform the user performing the action as to what is causing the error and the relevant command needed to fix it:

Hope this helps.