Since firefox 145 I'm unable to turn off my PC due to two "firefox-bin" processes in background

[ivan-hc]

Hi, I developed an AppImage of Firefox I was happy to use until 2-3 days ago.

In fact, since I updated to 145.0.2 I am unable to turn off my system due to two "firefox-bin" processes running in the background.

I have tried various solutions for my AppRun script inside the AppImage, including detecting and kill the processes via PID detection or directly on any firefox-bin process open.

No way.

In this moment I'm using the official portable archive you provide on your site and I have not tested yet if this is an issue of the release or of my AppImage. I'll give you more details later.

Any though?

Thanks in advance.

EDIT: I can confirm that this happens also with your portable build.

I tried to turn off my PC again, and two firefox-bin processes running in the background were preventing me to do that. I had to kill them.

[mkaply]

This probably belongs in bugzilla, not here (bugzilla.mozilla.org)

[ivan-hc]

This probably belongs in bugzilla, not here (bugzilla.mozilla.org)

Sorry, I was not sure on where to report this behavior.

[mkaply]

Can you run

ps aux|grep firefox-bin

So we can see which they are?

[ivan-hc]

ivan       12640  1.2  0.5 3569340 93752 ?       Sl   16:15   0:00 /tmp/.mount_firefoGCLfba/firefox-bin --backgroundtask removeDirectory /home/ivan/.mozilla/firefox/apzxxvh6.Default User/storage/to-be-removed  0 * --metrics-id Quota
ivan       12758  0.0  0.1 3569356 17656 ?       S    16:15   0:00 /tmp/.mount_firefoGCLfba/firefox-bin --backgroundtask removeDirectory /home/ivan/.mozilla/firefox/apzxxvh6.Default User/storage/to-be-removed  0 * --metrics-id Quota
ivan       12760  0.0  0.0   6536  2260 pts/0    S+   16:15   0:00 grep firefox-bin

[mkaply]

No problem at all. It is a unique situation,

[ivan-hc]

Have you got a suspect on what happens?

[mkaply]

We think it's related to some privacy cleanup. did you let it run a while and they never closed?

[ivan-hc]

privacy cleanup

What this means?

However, not, the processes are still running when I close the browser. I have to kill them to shut down or reboot or even exit from session.

[mkaply]

Sorry, I didn't mean to close.

Do you have the browser configured to clear history on shutdown?

"Yeah, that background task is Quota Manager cleaning up what almost certainly is the result of a privacy setting to forget history at shutdown. We use a background task for this intentionally to avoid creating shutdown hangs / blocking shutdown because those privacy settings absolutely had been causing shutdown hang problems. (And prevent the user from restarting Firefox after quitting, potentially, since the profile would still be locked in those cases.)"

We're wondering if those tasks go away eventually?

How long did you wait before giving up and ending them?

(we're checking with another engineer to see if there could be a bug)

[ivan-hc]

Do you have the browser configured to clear history on shutdown?

Yes, have this from years.

We're wondering if those tasks go away eventually?

How long did you wait before giving up and ending them?

Sadly, too much. I have tried a whole session of Librewolf only, after I have closed Firefox... and the two processes were still there.

[mkaply]

how long was Firefox stuck before you ran the ps command?

[ivan-hc]

To much, to "solve" I use this workaround (among the processes on "xfce4-session" to execute on exit/reboot/shut down):

sh -c 'if ! ps aux | grep -i firefox$; then killall firefox-bin; fi'

[mkaply]

and did this definitely start with Firefox 145?

[ivan-hc]

Yes

[mkaply]

and does it only happen with the app image? I wasn't sure from your original post

[ivan-hc]

I have tried with both the AppImage and the official portable archive. I also tried with new profiles. Same behavior.

[mkaply]

and does it only happen with the app image? I wasn't sure from your original post

[asutherland]

The fact that it spins forever makes me wonder if the to-be-removed directory might not actually be there and triggers this logic to want to wait for it to be there. Can you confirm if the /home/ivan/.mozilla/firefox/apzxxvh6.Default User/storage/to-be-removed directory actually seems to exist and double-check that there aren't any weird permissions problems (wrong owner, wrong access bits) for the profile directory or the "storage" subdir or the to-be-removed directory?

[ivan-hc]

This time the "ghost" directories are not appeared, maybe because the session was clear... but processes in background are many more

simplescreenrecorder-2025-12-09_17.19.56.mp4

[ivan-hc]

NOTE, this only happens after a normal usage of 2 or more tabs opened together.

[asutherland]

Thank you for checking that! So the background task code does emit a bunch of logging that we suppress by default, but I see here that if the environment variable MOZ_BACKGROUNDTASKS_IGNORE_NO_OUTPUT is defined and is non-empty (so I think a value of "1" should work), then the background task should start emit logging to stdout/stderr. So if you do export MOZ_BACKGROUNDTASKS_IGNORE_NO_OUTPUT=1 and then run Firefox from the command line, I think there should end being some useful output (I hope!)!

[asutherland]

Relatedly, I definitely could imagine that bad things could happen if the processes stack up so that one is still trying to run when Firefox is already shutting down. For getting logging above, it definitely seems desirable to at least terminate them all before a first run.

[ivan-hc]

Thank you for checking that! So the background task code does emit a bunch of logging that we suppress by default, but I see here that if the environment variable MOZ_BACKGROUNDTASKS_IGNORE_NO_OUTPUT is defined and is non-empty (so I think a value of "1" should work), then the background task should start emit logging to stdout/stderr. So if you do export MOZ_BACKGROUNDTASKS_IGNORE_NO_OUTPUT=1 and then run Firefox from the command line, I think there should end being some useful output (I hope!)!

Relatedly, I definitely could imagine that bad things could happen if the processes stack up so that one is still trying to run when Firefox is already shutting down. For getting logging above, it definitely seems desirable to at least terminate them all before a first run.

I have closed Firefox and killed the processes as you said.

I opened the terminal and executed

export MOZ_BACKGROUNDTASKS_IGNORE_NO_OUTPUT=1

then

firefox

and opened random tabs and videos.

I closed Firefox, I still have the two processes in background.

[ivan-hc]

@asutherland This is the whole log of the terminal session

ivan@debian:~$ firefox 
[Parent 59026, Main Thread] WARNING: ../../../gobject/gsignal.c:3648: signal name 'text-insert::system' is invalid for instance '0x7f61191c02f0' of type 'MaiAtkType21': 'glib warning', file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:201

(firefox:59026): GLib-GObject-CRITICAL **: 17:36:17.279: ../../../gobject/gsignal.c:3648: signal name 'text-insert::system' is invalid for instance '0x7f61191c02f0' of type 'MaiAtkType21'
*** You are running in background task mode. ***
*** You are running in headless mode.
console.error: "/home/ivan/.mozilla/firefox/apzxxvh6.Default User/storage/to-be-removed" "" 0 "*" "Quota"
console.error: "Deletion of folder 01958e3e-0cf7-49e3-9a26-50334d079396 - success=true"
console.error: "Deletion of folder 4c11b380-b2fa-46f4-be51-bd021e70abf9 - success=true"
console.error: "Pinged glean, waiting for submission."
[ERROR glean_core::core] Attempted to submit unknown ping 'fx-accounts'
[ERROR glean_core::core] Attempted to submit unknown ping 'usage-reporting'
ivan@debian:~$ ExceptionHandler::GenerateDump attempting to generate:/tmp/MozillaBackgroundTask-554C9DA0491E4067-removeDirectory/minidumps/76503eda-be7f-a691-fd7f-103db85b2013.dmp
ExceptionHandler::GenerateDump cloned child 60768
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
RunWatchdog: Mainthread nested event loops during hang: 
 --- (no nested event loop active)

[saschanaz]

Hmm. Looks like something fails when trying to send telemetry about the result. If you disable telemetry and try again, does the same thing happen?

[ivan-hc]

Hi @saschanaz , same behavior, just tested.

[saschanaz]

Is there any change in the log?

[ivan-hc]

Is there any change in the log?

@saschanaz

ivan@debian:~$ export MOZ_BACKGROUNDTASKS_IGNORE_NO_OUTPUT=1
ivan@debian:~$ firefox 
[Parent 82834, Main Thread] WARNING: ../../../gobject/gsignal.c:3648: signal name 'text-insert::system' is invalid for instance '0x7f11a63b73b0' of type 'MaiAtkType27': 'glib warning', file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:201

(firefox:82834): GLib-GObject-CRITICAL **: 19:02:37.112: ../../../gobject/gsignal.c:3648: signal name 'text-insert::system' is invalid for instance '0x7f11a63b73b0' of type 'MaiAtkType27'
*** You are running in background task mode. ***
*** You are running in headless mode.
console.error: "/home/ivan/.mozilla/firefox/apzxxvh6.Default User/storage/to-be-removed" "" 0 "*" ""
console.error: "Deletion of folder 68815668-ada7-43de-9c97-66a5fc55937c - success=true"
console.error: "Deletion of folder c2562204-108d-4a10-9571-a6df7d20a217 - success=true"
console.error: "Deletion of folder 713af343-af3d-404b-91bf-771d5228eb6d - success=true"
console.warn: "Skipping Glean as no metrics id is passed"
ivan@debian:~$ ExceptionHandler::GenerateDump attempting to generate:/tmp/MozillaBackgroundTask-E52AD5B4DE6114CD-removeDirectory/minidumps/4cc93fdb-e32a-20b8-e7ff-4e52ce2aaf53.dmp
ExceptionHandler::GenerateDump cloned child 84275
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

Processes are still running in the background.

[saschanaz]

Thanks! That helps us to remove glean from the list of the potential causes.

[ivan-hc]

Folks, I have just updated to Firefox 146, and I don't see the strange behavior (for now). I'll keep using it and I'll let you updated.

OFF TOPIC: @mkaply , I still have that issue with translations in Firefox AppImage. Maybe if you redirect me to an archive that includes all language packs (like you have done with the Flatpak), I would solve completely this #1250 my package is only 100 MB, so I think that few MB bigger is not the end of the world after all. Thanks.

[ivan-hc]

@saschanaz in 2 hours of intense usage, nothing happens anymore.

NOTE, I have Telemetry disabled as you suggested, so I don't know if the two things were related or something is changed upstream.

[ivan-hc]

After one day of usage, the issue is disappeared.

I don't know how, but thanks to all of you for the support @asutherland @mkaply @saschanaz

I would like to close this discussion... but first I'd like to know what was this bug exactly. I don't want that this would happen again to me or others.

[asutherland]

Yes, this is a fairly important component and its misbehavior is definitely concerning. Many thanks for your willingness to help investigate this, even after the problem seems to have been mooted somehow!

The logs involved some crashes (specifically the reference to /tmp/MozillaBackgroundTask-E52AD5B4DE6114CD-removeDirectory/minidumps/4cc93fdb-e32a-20b8-e7ff-4e52ce2aaf53.dmp seemed interesting); by any chance if you browse to about:crashes in Firefox do you see crashes in there that might relate to the background task and that you can provide the crash-stats links? Alternately, do you have any of those minidump files around from the tmp dir that you could upload?

[ivan-hc]

The logs involved some crashes (specifically the reference to /tmp/MozillaBackgroundTask-E52AD5B4DE6114CD-removeDirectory/minidumps/4cc93fdb-e32a-20b8-e7ff-4e52ce2aaf53.dmp seemed interesting); by any chance if you browse to about:crashes in Firefox do you see crashes in there that might relate to the background task and that you can provide the crash-stats links? Alternately, do you have any of those minidump files around from the tmp dir that you could upload?

Sorry, nothing of this is available. about:crashes doesn't contain anything, and no .dmp reference as file or txt files containing this into a line is available, not in /tmp, nor in my $HOME