Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's a mystery to me how Firefox updates on Ubuntu. Sometimes it goes through auto updates, but sometimes I'll try to open a new tab and it tells me that it will NOT allow me to do that until I restart. This is exceptionally annoying and not something that happens on Windows.

What is this related to?



It's explained here pretty well: https://bugzilla.mozilla.org/show_bug.cgi?id=1492023

My reading is that if your package manager updates FF on disk while it's running, it can no longer guarantee that new tabs can be created safely, since creating a tab requires spawning a child process and the parent was created with an executable that no longer exists/knows anything about the executable it needs to use when spawning.

It is super annoying and I feel like there are some obvious fixes. I'm also not 100% sure why it only happens on Linux (it updates fine on Windows and MacOS while running right?)


On Windows it downloads the updater in the background and then executes it when you next restart Firefox.

(At least, as far as I can tell)


Yes, but that's because it's updated by firefox itself.

If you install, say, FDE directly on linux, you'll get the same behaviour.

But if you use the distro's package manager then I don't think there's a viable workflow for it, as the package manager doesn't have hooks into process management.

The package manager would probably have to be subsumed by systemd for that to even be feasible.


From what I can see the bug is about packages, not snaps

Package is multiple files app needs replaced, so you have old app getting the files replaced under it during upgrade, that's why restart is needed.

In case of snap there is layer between, the "snap" is just a blob that is mounted by a daemon that then runs app off it.

If you just move/delete old snap the daemon should just be accessing old one till the app stops


On windows it just doesn't do the update until the browser is closed. It's odd that they don't have the same behavior on linux.


On Windows applications control their updates, on Linux distros the updates can be triggered externally by the package manager.

Or at least, you get an error if you try and modify an executable that is currently being used by a process on Windows.


Hmm, in that case it seems like the package manager should stage the new update and wait for the process to end before doing the update.

But I suppose linux is generally geared towards servers, where that isn't an issue.


You can get that behavior if you install Firefox from a tar [1], Firefox will then manage its own updates the same as on Windows (though the user running Firefox will need to have permissions to modify the files, which may be risky).

But if you install it through apt or some such package manager, the PM is doing the updates, and it doesn't take into account that Firefox is running.

[1] http://archive.mozilla.org/pub/firefox/releases/latest/READM... has instructions for getting a release tar.


More specifically, Firefox is updating itself in that situation so it knows not to do anything until startup/shutdown. When the you-have-to-restart tab appears, it's because Firefox didn't do the update, something external on linux (apt or snap or something) did it in a way Firefox can't handle.


Not an excuse but that wouldn’t work on a multi-user system of course.

The solution is to version the files and keep the old versions until the processes are closed. As Windows enforces because it doesn’t allow you to delete files that are in use.


Pretty sure that's exactly how it works in the FlatPak version.


My Microsoft Edge on macOS breaks when updates are applied (through my company's 3rd party updater). New tabs just go blank.


On Windows, Firefox can't be updated while it's running because the files that comprise it are locked by the running application.

On Linux, you can delete or replace open files, and even running applications. Instead of updates being handled by dozens of individual updaters that coordinate closely with each app so that updates happen between restarts, updates happen in the background without really coordinating with running apps.

Sometimes, after Firefox has been updated, there's some kind of incompatibility between the old running binary and the new assets (internal JS, CSS, and idk what else). In that case, Firefox can't open new tabs because you're still running the old binary, which doesn't work with the new assets which have been installed, or which is looking for old assets that it opens dynamically at runtime that are simply no longer present on your disk.


> On Windows, Firefox can't be updated while it's running because the files that comprise it are locked by the running application.

I don't know how the "behind the scenes" work but you can run an update while Firefox is running. We do it all the time. We push security updates to our clients via an agent. It runs the official installer in silent mode. It is like OP described: You can't open new tabs (ok you can but they will not work) until you restart the browser, but the existing tabs keep working.


A side effect from UNIX vs VMS school of OS design, in relation to how files should be handled.


IME Firefox does this when the OS updates packages that Firefox depends on and/or changes FF version. I can't speak to Ubuntu specifically but I've seen the same behavior on Arch and Fedora and it's always around OS updates that I've triggered manually.


Ubuntu (at least pre-snap) has Firefox in unattended-upgrades so apt can update Firefox in the background even if the user never runs updates themselves.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: