Open Bug 1536150 Opened 6 years ago Updated 15 days ago

Nightly does not restart automatically after an update (I have to start it manually)

Categories

(Toolkit :: Startup and Profile System, defect, P3)

Product:
Toolkit
Component:
Startup and Profile System
Platform:
x86_64
Linux
Type:
defect

Tracking

()

People

(Reporter: botond, Unassigned)

References

(
URL
)

Details

STR:

  1. Run Nightly on Linux
  2. When an update is available, click "Restart to update nightly".

Expected results:

Firefox restarts automatically.

Actual results:

Firefox closes, but does not restart. I have to start it again manually.

I feel like this has been happening for a while, but it's become more noticeable because Firefox has been forcing restarts more often (shows the "Sorry, just one more thing to keep going" page), which is quite annoying in and of itself, but that's another story...

Is this still happening with current builds? We had a regression like this due to the landing of bug 469990, but that was backed out and has since been fixed.

Flags: needinfo?(botond)

Yup, still happening today. Note, I'm running on Linux, whereas bug 469990 seems to be specific to Mac.

Flags: needinfo?(botond)

(In reply to Botond Ballo [:botond] from comment #2)

Note, I'm running on Linux, [...]

Oh, I skipped right over that. Setting affected platform accordingly. Thanks!

OS: Unspecified → Linux
Hardware: Unspecified → x86_64

I haven't heard of any other reports of this so not quite sure what could be going on. Are you still able to reproduce?

Flags: needinfo?(botond)

Yup, just updated again and had to restart manually.

Flags: needinfo?(botond)

Is the failure to restart only happening when you restart from the "Sorry, just one more thing to keep going" page, or also through other methods?

Flags: needinfo?(botond)

No, it happens after a regular hamburger menu -> "Restart to update Nightly" as well.

Flags: needinfo?(botond)

I just updated again with "Restart to update Nightly", and this time it did restart automatically. So I guess the issue is intermittent, or perhaps it only occurs after you've been running for a while?

Trying to think of a way to figure this out.

What should be happening is after the main application loop ends but before the process exits we re-launch Firefox (https://searchfox.org/mozilla-central/rev/f46e2bf881d522a440b30cbf5cf8d76fc212eaf4/toolkit/xre/nsAppRunner.cpp#4774). In theory everything necessary has been unlocked at that point so there should be no conflict between tow two processes even if the original takes some time to complete. Even if there were the new process is meant to display an error in that case.

I guess an strace might reveal a bit about what is going on but that could be pretty challenging to trawl through.

Once thought that might help here is seeing if this reproduces in a dev build. Locally made builds should have a restart option in the file menu which should be doing basically the same as we do for restarting for updates. If the problem can be reproduced in that way then that would give us more options for debugging this.

URL: https://bugzilla.mozilla.org/show_bug...
Priority: -- → P3

This issue is back in Nightly released on 2019-05-13.

Not seeing this problem anymore. I wonder if this is ready to be closed.

I still see it regularly. Not on demand though; usually it requires Nightly to have been running for a while (like a day or two) to reproduce.

This might have been an instance of bug 1597803; Botond did you see this happen again in the last two weeks?

Flags: needinfo?(botond)

Unfortunately, yes, I just restarted now and it happened.

Flags: needinfo?(botond)

Came across a reddit thread where the reporter has this problem (browser doesn't reopen after clicking restart) 100% of the time. https://www.reddit.com/r/firefox/comments/gtl10c/can_we_fix_the_misleading_descriptionbutton_text/

This still happens to me, regularly, and together with the fact that Firefox now asks for a restart ("Sorry, there's just a little thing we need to do first") way more often than before, it's making me want to switch away from nightly as my daily driver.

Let's try and figure out why it's getting stuck. At least we know it's not bug 1597803 because that was caused by the distro updating Firefox under the hood, not by Firefox' updater. When it happens the next time can you look up the parent process and kill it with kill -ABRT <pid>? That should launch the crash reporter, submit the crash and then let's have a look where it got stuck.

Flags: needinfo?(botond)

(In reply to Gabriele Svelto [:gsvelto] from comment #17)

When it happens the next time can you look up the parent process and kill it with kill -ABRT <pid>? That should launch the crash reporter, submit the crash and then let's have a look where it got stuck.

The parent process is not stuck, it exits successfully and Firefox never re-starts.

I confirmed this by launching Firefox from the command-line, without & (so that it does not give me back control of the prompt). When I clicked "Restart to update", the process exited and gave me back control of the prompt at that time (and Firefox did not re-start).

The only thing printed on the command line was a bunch of these:

###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

but these were printed during browsing, not specifically at shutdown time.

In case it matters, there is another Firefox instance (with a different profile) open as well. I haven't paid enough attention recently to see if that's always the case when the issue occurs (historically it wasn't, it used to happen even when only the one instance was running, but that may have changed), but it's been the case the last ~3 times the issue has occurred.

Flags: needinfo?(botond)

(In reply to Botond Ballo [:botond] from comment #18)

In case it matters, there is another Firefox instance (with a different profile) open as well. I haven't paid enough attention recently to see if that's always the case when the issue occurs (historically it wasn't, it used to happen even when only the one instance was running, but that may have changed), but it's been the case the last ~3 times the issue has occurred.

It just happened without another Firefox instance running. It was just the one, and it didn't restart. There are no firefox processes running.

We'd need some diagnostics around the call that actually restarts Firefox then. It sounds like the old instance launches the new one and then fails to shut down which is odd... but maybe more common than we expected.

(In reply to Gabriele Svelto [:gsvelto] from comment #20)

It sounds like the old instance launches the new one and then fails to shut down which is odd... but maybe more common than we expected.

I'm a bit confused... how does the symptom that there is no firefox process running after the window closes, lead you to believe it "fails to shut down"? Isn't it the opposite, it shuts down when it shouldn't?

Yes, what I actually meant is that it fails to launch the new one and then shuts down.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.