On 4/19/25 9:50 AM, Jim via tde-users wrote:
It is a beast that takes it's time. My bet is that it takes 10-12sec to
write to the internal sqlite database. You can use strace -fp <firefox pid>
to see what it is doing (of course you must login on the console outside
TDE :-)
I'm not sure what you guys have going on, my firefox (with 40 or 50 open
tabs) takes a second or three to shut down.
I just timed it as follows, after using ps to determine that the main
firefox process' PID was 24402:
date +%s.%N ; kill -TERM 24402; while ls /proc/24402 > /dev/null 2>&1 ; do ; date +%s.%N ; done
The output was
1745073214.695149607
1745073214.704957548
1745073214.710325927
1745073214.721915419
1745073214.730364874
1745073214.740190648
1745073214.749773235
1745073214.756865326
1745073214.763335939
1745073214.774071905
1745073214.789571122
1745073214.801696883
1745073214.859510512
which I interpret as meaning that firefox took about 0.164360905 seconds to
shut down on my computer. (This was shortly after starting it up, I tried
another way of timing it after it had been running for days, and in that
case it took about 2 second to shut down.)
So what's different between my system and yours? I can think of two
possible things.
(1) While I use some TDE programs, I don't use TDE as my desktop
environment (I use fvwm3 as my window manager), so maybe there is some
long-winded interaction going on between firefox and TDE as firefox
shuts down.
(2) I also don't have firefox store my session (and other info) in the
"cloud", so that is another possibility of what is taking long.
Perhaps one of you with long shutdown times could do an
ifconfig -a
before starting the shutdown and another
ifconfig -a
after, to see how much network activity happened. (Of course, shut
down anything else likely using much network bandwidth before shutting
down firefox.)
Other than that, I don't know. FWIW, my laptop is reasonably fast but not
a killer machine (Ryzen 4700U CPU with a NVME "disk"). Running
while date +%s.%N ; do ; done
from a terminal window shows that loop takes about 0.0047 seconds per
iteration, using
while date +%s.%N ; do ; done | head -1001
and then dividing the difference between the first and last outputs by 1000.
Your mileage will no doubt vary. To avoid scrolling back, try this:
while date +%s.%N ; do ; done | (read l ; echo $l ; head -1000 | tail -1)
and then do the arithmetic.
I made some progress finding a cause of the delay.
For anybody browsing this thread so others can benefit:
I don't use open tabs as bookmarks. I don't have week long surfing
sessions. Anything worthy of preserving gets bookmarked with real
bookmarks and tabs get closed. I don't suspend computers to save desktop
sessions. I rarely leave tabs open when closing. I am not a news junkie
and don't use social media. My Firefox session is empty when I close.
I'm a simple user in that respect -- when my day is done everything gets
shut down.
I disabled session restore (about:config), enabled
MOZ_CRASHREPORTER_DISABLE=1 (don't know if that is still supported), and
tested launching with '-safe-mode' to temporarily disable addons. No
change in delay.
I tested closing Firefox in KDE and Xfce. Doesn't seem to be DE related
-- same delay. I tested launching and one second later closing. No
change in delay.
I am adverse to storing my data outside my LAN. No cloud bullshittery
here and not a possible cause.
I am zealous about disabling any external service Firefox might be
trying to contact and disable all known telemetry. There is nothing for
Firefox to contact. The lack of being able to phone home might be
causing the delays. I don't think so but need to investigate further.
I am not a complex Firefox user. There just isn't enough user data to
update on shutdown. With no open tabs on closing one has to wonder WTF
needs to be saved? Nothing, so the cause of the delay is elsewhere.
I thought perhaps there is something corrupted in my profile databases.
I long have detested the developers tendency to hide my data in their
precious sqlite databases because geek creds. Troubleshooting is so much
easier with text files. That rant aside, I don't think that is the cause.
My most recent effort was to log into one of my testing accounts. There
I created a new Firefox profile. Closing Firefox saw all processes
terminated in less than two seconds.
Next I enabled all of the same addons as my normal accounts. Same quick
termination.
When I restored the testing account's previous Firefox profile I again
saw about 10 seconds to terminate all processes. I haven't had time to
dig further but two things I need to check: custom css files and
user.js. I doubt css files play a role but with the custom user.js, who
knows what might be confusing the developer's code. Especially since I
disable a boat load of nonsense.
For the short term I know the cause of the logout delay. That is a good
start. I now have some nominal clues about the cause of the slow process
terminations. When I find time I'll report further.
____________________________________________________
tde-users mailing list -- users@xxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxx
Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@xxxxxxxxxxxxxxxxxx
