Closed Bug 1553781 Opened 3 months ago Closed 3 months ago

RemoteService fake profile is not entirely cleaned up when using XRemote

Categories

(Toolkit :: Startup and Profile System, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla69
Tracking Status
firefox69 --- fixed

People

(Reporter: glandium, Assigned: mossop)

References

Details

Attachments

(1 file)

The fake profile that is currently created in /tmp/firefox (see bug 1553771) is not always cleaned up.
STR:

  • Open firefox
  • With firefox open, run firefox https://someurl.com

What happens is that the fake profile is removed during startup of the first Firefox, but the Xremote call creates a new one, and doesn't clean it up entirely.

The reason for that, in turn, is that nsRemoteService::UnlockStartup() is never called when using the Xremote client. In fact, it's not called in all sorts of cases where XRE_main may fail. It seems like it should be called from the nsRemoteService destructor if it wasn't called manually already.

Indeed, it is cleaned up when firefox is run on an account that had no firefox running.

But when running a second instance, the same directory is recreated but not cleaned up and /tmp/firefox/.parentlock still exists, locking out other users into a 5-second wait on each /usr/bin/firefox invocation.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1553829 for details.

Confirmed here on Xubuntu 18.04.

Symptom: 5-second lag before a new window appear

Steps to reproduce:

  • user A runs Firefox (keeps running, don't quit)
  • user B runs Firefox (keeps running, don't quit)
  • each time user B calls /usr/bin/firefox from command line, there is a 5 second wait time before expected new window appears and command line returns.

In practice, the users use a global key shortcut to open another Firefox window, which causes /usr/bin/firefox to be run.

Before v67: a /tmp/firefox_$USER was created and not removed, leaving /tmp/firefox_$USER/.parentlock, which was not a real problem.
Since v67: the dir is /tmp/firefox with restricted permission, hold by user A. When user B tries, strace reveals this:

symlink("127.0.1.1:19986", "/tmp/firefox/lock") = -1 EACCES (Permission denied)

repeatedly for 5 seconds, then window appears.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1553829 for details.

Assignee: nobody → dtownsend

This fixes the issue in a few redundant ways:

  • nsProfileLock is made to properly clean itself up when destroyed.
  • nsRemoteService makes sure the unlock when destroyed.
  • nsAppRunner unlocks when a remote client has been found.
Duplicate of this bug: 1553829
Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/18ace6e65729
When the remote service finds an instance to remote to it doesn't clean up the startup lock. r=glandium
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
You need to log in before you can comment on or make changes to this bug.