Score:4

Why is my Firefox so unstable on Ubuntu LTS 22.04?

fr flag

Four days ago I upgraded my laptop from Ubuntu 20.04 LTS to 22.04 LTS. While this upgrade generally went very smoothly, a pop-up paused the process to tell me that henceforth Firefox would be packaged via snap rather than apt. When I rebooted after the upgrade, the Firefox icon had disappeared from the Favorites dock, so I had to go into Activities to launch it. I am now using Firefox 105.0.2 (64-bit), Mozilla Firefox Snap for Ubuntu canonical-002-1.0.

Unfortunately Firefox has been very unstable since this upgrade. It has shut down without explanation at least 6 times over the past 4 days. Previously, if Firefox (or any other application) shut down unexpectedly, I would expect to get a pop-up stating that the application had shut down unexpectedly and asking me if I want to send a bug report to Canonical. In none of these shutdowns did I get that bug-report prompt.

One -- but only one -- of these shutdowns may have been associated with the need to do a sudo snap refresh. Internet search brought me to several web pages which explain that a sudden shutdown of Firefox when I need to do a refresh is a consequence of the move from apt to snap for which the end-user experience is terrible. I was able to do the refresh and re-open Firefox.

However, all my other Firefox shutdowns over the past several days have not been associated with a snap refresh being needed. Firefox has offered no pop-ups explaining these sudden shutdowns. They are more likely to happen when I am right-clicking on multiple links within a given page in order to open linked sites in new tabs. But if I've opened several new tabs and they're loading simultaneously, I might expect some of them to load slowly, but I don't expect them to crash the application.

I typically have 2 or 3 windows open, with 3 to 8 tabs in each window. I have been using Firefox like this on Ubuntu since 2006 and have never had such severe stability problems with this browser.

  1. Are others experiencing similar instability in Firefox now that it's implemented via snap?

  2. Where on my computer can I find logs that might explain this problem?

guiverc avatar
cn flag
Have you explored systemd journal to ensure you're not just experiencing lack of memory issues, and `firefox` is being killed by `systemd-oomd` to create RAM as it's lacking? The process tends to *favor* snap packages in my experience. (view `journalctl`)
guiverc avatar
cn flag
Viewing https://askubuntu.com/questions/1404888/how-do-i-disable-the-systemd-oom-process-killer-in-ubuntu-22-04 maybe helpful to avoiding firefox close if what I suggest is your issue, but firstly work out the actual issue I suggest and I'd avoid using it that if you can. For clues on what to look for https://ubuntu-mate.community/t/what-all-is-inbound-with-22-04/25130/3 but note that's old (*newer posts will exist; I've just not found them sorry, as `systemd-oomd` is a more tweaked to back then*)
user535733 avatar
cn flag
Question #1: Try the Search box at the top of the page; see if you find any like descriptions. That's the closest we have to issue tracking at AskUbuntu.
Terrance avatar
id flag
You can always go with the traditional deb package if you want. One day they may stop making it, but for now it is what I am doing. https://askubuntu.com/questions/1399383/how-to-install-firefox-as-a-traditional-deb-package-without-snap-in-ubuntu-22
codeinthehole avatar
in flag
I'm experiencing exactly the same. I assumed it was a problem with snap, so I ended up removing that version and setup the standard APT based version .. but still have stability issues. I don't want to move back to Chrome, but I might be forced to soon!
Score:0
cn flag

For Firefox log events, look in /var/log/syslog.

Also check your /var/crash directory for .crash files, of course.

  • Firefox generates a lot of log activity that is NOT crash-related, so compare timestamps with the times of actual crashes.

  • Also look for other applications that might be crashing around the same time, like gnome-shell. It's possible that Firefox is crashing due to a bug elsewhere in the desktop stack.

James E Keenan avatar
fr flag
There were no .crash files in /var/crash. There were, however, many pairs of entries in /var/log/syslog like this: 15410:Oct 7 19:54:07 zareason systemd-oomd[1208]: Killed /user.slice/user-1000.slice/user@1000.service/app.slice/snap.firefox.firefox.762ce323-1752-4134-abc1-125b4e567041.scope due to memory pressure for /user.slice/user-1000.slice/user@1000.service being 69.81% > 50.00% for > 20s with reclaim activity 15411:Oct 7 19:54:08 zareason systemd[6607]: snap.firefox.firefox.762ce323-1752-4134-abc1-125b4e567041.scope: systemd-oomd killed 510 process(es) in this unit.
James E Keenan avatar
fr flag
I understand from pages like https://techhq.com/2022/07/ubuntu-22-oomd-app-killer-memory-pressure/ that this is a known problem. As a first step toward mitigating the problem, I have reset vm.swappiness to 60. When using 20.04 LTS I had encountered problems that led me to reduce vm.swappiness to 20. During the upgrade process a pop-up noticed this and I elected to retain that setting. I will see whether restoring that to its customary value helps to avoid the OOM killer.
James E Keenan avatar
fr flag
On the basis of these 2 web pages: https://www.cjjackson.dev/posts/what-is-systemd-oomd-how-to-disable-it/ https://askubuntu.com/questions/1404888/how-do-i-disable-the-systemd-oom-process-killer-in-ubuntu-22-04 -- I am going with the following for the time being: ```$ sudo systemctl mask systemd-oomd Created symlink /etc/systemd/system/systemd-oomd.service → /dev/null.```
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.