1736504 - Firefox Nightly destroys its own Linux directory path on update

Status: RESOLVED WORKSFORME

(Toolkit :: Application Update, defect)

Description

[Dennis Clarke]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

Notice Firefox nightly claims that an update is available. Accept and download update. See dialog box that suggests restart.

Actual results:

Firefox shuts down. Never returns.

I see in the directory where firefox runs from that the inode number has changed.
I have seen, many times, nightly never restarts after update.

Why?

I run firefox directly from an XTerm in a bash shell.

So if I cd into my local firefox directory and look at the inode numbers BEFORE I run firefox I see :

nightly$
total 40
14156850 drwxr-xr-x 4 16411 20002 4096 Oct 18 14:02 ./
14155788 drwxr-xr-x 47 16411 20002 24576 Oct 18 13:51 ../
14188661 drwxr-xr-x 8 16411 20002 4096 Oct 18 13:49 firefox/
8193 drwxr-xr-x 8 16411 20002 4096 Oct 18 12:30 thunderbird/
nightly$

If an update runs the directory for "firefox" is destroyed and I get a new inode number :

nightly$ cd ..
nightly$ cd firefox/
nightly$
nightly$ pwd
/home/dclarke/local/firefox
nightly$ ls -lapbin ..
total 44
14156850 drwxr-xr-x 4 16411 20002 4096 Oct 19 00:08 ./
14155788 drwxr-xr-x 48 16411 20002 24576 Oct 18 23:31 ../
14157531 drwxr-xr-x 8 16411 20002 4096 Oct 18 20:49 firefox/
8193 drwxr-xr-x 8 16411 20002 4096 Oct 18 12:30 thunderbird/

This may explain why nightly never restarts.

Expected results:

Firefox should restart.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Application Update' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[AmirH [:Amir]]

Are you able to restart Firefox manually and do updates take place?

Comment 3

[Dennis Clarke]

I can start FireFox manually however NOT from the directory that the shell was left in. Why? Because there is nothing there and there seems to be some confusion because "pwd" will show the path and "ls -lap" shows nothing. One may then "cd .." and do "ls -lap" to see the firefox directory. However I now know that the inode numbers have changed. Simply "cd firefox" and then start manually as per usual. This may happen over and over and over in a single day because, of course, "nightly" does not update once nightly. It updates over and over and over as the CI process throws out code and spits out executables without a single person ever doing a test or even seeing the results. So this happens over and over and over in any given day. Such as right now as I write this comment "nightly" wants a restart. For me that means a manual dance inside a bash shell/XTerm session and then start manually. Must be the same way for others too.

Comment 4

[AmirH [:Amir]]

I believe this was a duplicate of this bug that got resolved:
https://bugzilla.mozilla.org/show_bug.cgi?id=1736373

Please reopen if you think this is still ongoing.

Comment 5

[Dennis Clarke]

Seems to still happen on my Debian Linux stable system where I get notified that there is an update available within the "Help About" dialog box. I of course click on the download update button and then restart. Whereupon I see a command prompt which is the way I launched Nightly :

admsys@deimos:~/local/firefox$ 
admsys@deimos:~/local/firefox$ ./firefox
[fluent] Missing message in locale en-CA: main-context-menu-toggle-show-password
admsys@deimos:~/local/firefox$ pwd
/home/admsys/local/firefox
admsys@deimos:~/local/firefox$ ls -la 
total 0
admsys@deimos:~/local/firefox$ cd ..
admsys@deimos:~/local$ cd firefox/
admsys@deimos:~/local/firefox$ ls -la firefox
-rwxr-xr-x 1 admsys admsys 16144 Dec 20 10:18 firefox

Above you see that the current directory is empty.  It seems that the update does destroy the previous directory and then applies the update into a new directory with the name "firefox". However the pwd of the shell that launched Nightly is still in the pre-existing path which of course no longer exists. Makes for a funny situation.

Of course I can simply "cd .." and then cd back into the now new firefox directory and re-launch nightly.

This happened just now with https://hg.mozilla.org/mozilla-central/rev/c223d66e6148b604c1579863ab9a65906b547cdd

Dennis

Comment 6

[Robin Steuber (she/her) [:bytesized]]

This does not look to me like a duplicate of Bug 1736373. However, it also does not look like a bug. This looks like the way that we designed the updater to function. Is there some reason that you think that it should not function this way?

---

Side note, I don't specifically remember, but I think that it is quite likely that we won't remove the containing directory if you don't use update staging (i.e. if app.update.staging.enabled is false). Disabling staging will effectively cause the patch to be applied when Firefox launches/restarts, rather than applying the patch in advance and swapping for the updated version on (re)start. This means that updating will seem to take longer, because we will be doing more of the work while you are waiting for Firefox to start. But it is a behavior that we support.

Comment 7

[Robin Steuber (she/her) [:bytesized]]

Oh, I should have read more of the bug. What is described in Comment 0 sounds like a bug. But Comment 5 just sounds like regular behavior. Are you still experiencing the issue from Comment 0?

Comment 8

[Dennis Clarke]

https://hg.mozilla.org/mozilla-central/rev/a6af5cff5adf1e7aebb5072f917bef5b12ade24d

With Nightly right now everything seems to work fine.

Comment 9

[Robin Steuber (she/her) [:bytesized]]

Great! I'll close this for now. We can reopen it if the problem reoccurs. Perhaps it was indeed a problem due to Bug 1736373.