18 Apr
2025
18 Apr
'25
10:31 p.m.
I can't put my finger on anything. About a third of the time when I log
out of my TDE session there is a notable (and irritating) delay. Almost
like a freeze.
Nothing in the .xsession-errors log.
I start TDE from the console with startx.
My first guess is some process not responding. Whether that process is
TDE or other I do not know.
I have seen this oddball event throughout my years of using TDE. Could
well be I have configured something to cause the issue.
I am open to suggestions to debug.
Thanks.
19 Apr
19 Apr
12:07 a.m.
Darrell Anderson via tde-users wrote:
My first guess is some process not responding. Whether
that process is
TDE or other I do not know.
I have seen this oddball event throughout my years of using TDE. Could
well be I have configured something to cause the issue.
I am open to suggestions to debug.
surely you are using systemd and one of the units is not stopping properly.
Look in this direction. Helpful is when you press ESC or you boot in
verbose mode. When you identify the unit take care of it appropriately.
12:37 a.m.
On 4/18/25 3:07 PM, deloptes via tde-users wrote:
surely you are using systemd and one of the units is
not stopping properly.
Look in this direction. Helpful is when you press ESC or you boot in
verbose mode. When you identify the unit take care of it appropriately.
No systemd here. :)
But what you shared agrees what I stated originally -- that likely some
process was not responding to the request to end the session.
The oddity is I tend to be orderly about logging out. When I end a
session I always manually close everything running on the desktop such
as the web browser, text editor, etc. So nominally that implies a
background or TDE process not responding or taking a long time to respond.
2:34 a.m.
Darrell Anderson via tde-users wrote:
No systemd here. :)
(no comment)
But what you shared agrees what I stated originally --
that likely some
process was not responding to the request to end the session.
don't you see anything on the screen?
The oddity is I tend to be orderly about logging out.
When I end a
session I always manually close everything running on the desktop such
as the web browser, text editor, etc. So nominally that implies a
background or TDE process not responding or taking a long time to respond.
usually a popup with progress bar is displayed that says notifying
applications etc etc and you can choose to kill them all or to wait.
3:20 a.m.
On 4/18/25 5:34 PM, deloptes via tde-users wrote:
don't you see anything on the screen?
usually a popup with progress bar is displayed that says notifying
applications etc etc and you can choose to kill them all or to wait.
Nothing like that. I never would have posted if there was some kind of
feedback.
6:39 a.m.
On 4/18/25 6:20 PM, Darrell Anderson via tde-users wrote:
On 4/18/25 5:34 PM, deloptes via tde-users wrote:
I believe I found the root cause.
I long have suspected Firefox taking a long to fully terminate because
many times I have closed Firefox and within a few seconds later
attempted to launch again. I always receive an error dialog that Firefox
is busy. Busy? Busy doing what? I don't know.
I mentioned previously I tend to manually ensure everything is closed
before logging out, but with a few keystrokes that is a quick routine. I
then logout with the keyboard. But Firefox is not done whistling and
farting around.
I looked into that and confirmed Firefox takes about 10 to 12 seconds to
fully terminate. On a 4-core system with an nvme disk.
If I wait 10 to 12 seconds after closing Firefox then I don't see the
logout delay. At least so far I am not seeing the delay.
I long had forgotten about the TDE session logout status dialog. I
enabled that feature and confirmed Firefox is causing the delay.
With the logout status dialog enabled, attempting to logout before
Firefox fully terminates results in a kdebug crash. The backtrace is not
useful because I don't have symbols enabled.
I have no idea why Firefox takes 10 to 12 seconds to fully terminate.
That is WTF territory. Truly.
don't you see anything on the screen?
usually a popup with progress bar is displayed that says notifying
applications etc etc and you can choose to kill them all or to wait.
Nothing like that. I never would have posted if there was some kind of
feedback. 
8:38 a.m.
On Friday 18 April 2025 19:39:29 Darrell Anderson via tde-users wrote:
On 4/18/25 6:20 PM, Darrell Anderson via tde-users
wrote:
I am inclined to do everything manually, as well, but maybe a little
differently than most. I use a terminal command, pkill <whatever process> for
most internet-related programs. Browsers can be problematic, as it may be
that some connections just won't let go.
Generally I use browsers over Tor, and tork-trinity allows me to watch my
connections in real time; when I (rarely) use a direct connection, for some
kind of business, paying bills or whatever, I don't have anything to show
that information in real time. I used to use firestarter firewall, but that
has been dropped from the repositories. If anybody knows of such a program,
that would be helpful, but I only use direct connections for those few
occasions during the month when I must pay for something online. Otherwise, I
my browsing and other internet activities are always conducted over Tor, and
I can watch those connections with tork-trinity.
Maybe others will tell me that this is "wrong"; but I've been doing it like
this for about 20 years, and my machines (usually) obey me. The same goes
with controlling my internet connection; tdenetworkmanager is there, and I
choose from open connection using it, but for actually turning my wifi on and
off, I use iwconfig and ifconfig, and a series of other commands, to be sure
that I know who is in control.
Stone tools are still the best. Everything since then has been downhill.
Bill
On 4/18/25 5:34 PM, deloptes via tde-users
wrote:
I believe I found the root cause.
I long have suspected Firefox taking a long to fully terminate because
many times I have closed Firefox and within a few seconds later
attempted to launch again. I always receive an error dialog that Firefox
is busy. Busy? Busy doing what? I don't know.
I mentioned previously I tend to manually ensure everything is closed
before logging out, but with a few keystrokes that is a quick routine. I
then logout with the keyboard. But Firefox is not done whistling and
farting around.
I looked into that and confirmed Firefox takes about 10 to 12 seconds to
fully terminate. On a 4-core system with an nvme disk.
If I wait 10 to 12 seconds after closing Firefox then I don't see the
logout delay. At least so far I am not seeing the delay.
I long had forgotten about the TDE session logout status dialog. I
enabled that feature and confirmed Firefox is causing the delay.
With the logout status dialog enabled, attempting to logout before
Firefox fully terminates results in a kdebug crash. The backtrace is not
useful because I don't have symbols enabled.
I have no idea why Firefox takes 10 to 12 seconds to fully terminate.
That is WTF territory. Truly. don't you see anything on the screen?
usually a popup with progress bar is displayed that says notifying
applications etc etc and you can choose to kill them all or to wait.
Nothing like that. I never would have posted if there was some kind of
feedback. 
2:25 p.m.
-------- Original Message --------
On 4/19/25 12:38 AM, William Morder via tde-users <users(a)trinitydesktop.org> wrote:
Stone tools are still the best. Everything since then has been downhill.
Bill
😆🤣
This has got to be the funniest and most memorable quote I've seen yet on the TDE
mailing list. Bill is my/our spirit animal apparently.
Just yesterday I was thinking that I should do a programming project without ever using
even single function name autocomplete, as a retro stunt to metaphorically poke my finger
in the eyes of people who think they need lots of bloated tools to get things done, like
an embodiment of the *exact opposite* of the trend of some people using AI to
"write"/plagiarize much of their code, heh.
Likewise, I also look down on copy-pasting code from forums without understanding it,
usually.
Crutches breed weakness and dispowerment and reduced freedom over time. Nowhere is that
more evident than in recent times in our society.
4:27 p.m.
On 4/19/25 06:27, WraithGlade via tde-users wrote:
-------- Original Message --------
On 4/19/25 12:38 AM, William Morder via tde-users <users(a)trinitydesktop.org>
wrote:
This above statement is as
truthful, clear and concise an understanding
of the last century's effect on humanity I've seen written in my 90 years.
Stone tools are still the best. Everything since then has been downhill.
Bill
😆🤣
This has got to be the funniest and most memorable quote I've seen yet on the TDE
mailing list. Bill is my/our spirit animal apparently.
Just yesterday I was thinking that I should do a programming project without ever using
even single function name autocomplete, as a retro stunt to metaphorically poke my finger
in the eyes of people who think they need lots of bloated tools to get things done, like
an embodiment of the *exact opposite* of the trend of some people using AI to
"write"/plagiarize much of their code, heh.
Likewise, I also look down on copy-pasting code from forums without understanding it,
usually.
Crutches breed weakness and dispowerment and reduced freedom over time. Nowhere is that
more evident than in recent times in our society. ____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
4:47 p.m.
Darrell Anderson via tde-users wrote:
I looked into that and confirmed Firefox takes about
10 to 12 seconds to
fully terminate. On a 4-core system with an nvme disk.
It sounds great, that you narrowed down the issue. Firefox is writing a lot
of things to disk and/or internal database, so that you can restore the
session the next time you start. I usually never close it before exit
because on next start/login it is spawned automatically by TDE and it asks
me to restore the previous session or it just restores all windows
automatically.
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 :-)
6:50 p.m.
On Sat, Apr 19, 2025 at 14:47 (+0200), deloptes via tde-users wrote:
Darrell Anderson via tde-users wrote:
> I looked into that and confirmed Firefox takes
about 10 to 12 seconds to
> fully terminate. On a 4-core system with an nvme disk.
It sounds great, that you narrowed down the issue.
Firefox is writing a lot
of things to disk and/or internal database, so that you can restore the
session the next time you start. I usually never close it before exit
because on next start/login it is spawned automatically by TDE and it asks
me to restore the previous session or it just restores all windows
automatically.
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.
Jim
8:47 p.m.
On 4/19/25 9:50 AM, Jim via tde-users wrote:
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.
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.
11:02 p.m.
On 4/19/25 11:47 AM, Darrell Anderson via tde-users wrote:
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.
I found the cause of the delay with Firefox not terminating in a timely
manner.
I have a shell script that runs when logging out. I've had the script
for 20+ years. The script is executed by all users. In that script are
housekeeping commands to delete garbage files and directories that tend
to accumulate in any computer operating system because some developers
have to defend their geek creds and sloppy programming.
This cleanup and scrubbing strategy has worked well for me for 30+
years, going back to my DOS days. Only the commands have changed.
In that housekeeping sweep are commands to scrub the user's Firefox
profile. In the current scheme, one of the commands was converting the
Firefox profile 'datareporting' directory into a zero-byte file. This
has been in place for years, immediately after the Firefox devs decided
to join the world of data mining and tracking -- oops -- telemetry.
The idea is with a zero-byte file in place no "data reporting" data can
be collected. Using zero-byte files like this is an old trick.
The delay was caused by Firefox being unable to modify files in the
'datareporting' directory, which no longer existed and is a zero-byte file.
I have just about every known avenue of data mining, tracking, and
so-called telemetry disabled, but seems upon closing Firefox the code
remains designed to do something related to that directory.
The new solution is to allow the directory but have the cleanup sweep
delete all files in the directory. Not that the files can be used in any
way since I have blocked all known avenues of telemetry. But deleting
the files makes me feel warm and fuzzy. Just because.
Firefox now fully terminates in less than a second. No more delay.
Interesting little FUBAR.
Feel free to call me paranoid or too damn zealous about protecting my
privacy. I am not going to change my habits. And at least for the time
being I remain triumphant. :)
4:50 p.m.
On Fri, 18 Apr 2025 21:39:29 -0500
Darrell Anderson via tde-users <users(a)trinitydesktop.org> wrote:
I long have suspected Firefox taking a long to fully
terminate because
many times I have closed Firefox and within a few seconds later
attempted to launch again. I always receive an error dialog that Firefox
is busy. Busy? Busy doing what? I don't know.
At a guess, it's running umpteen bazillion poorly-written Javascript
destructors, saving session information, and possibly preening its on-disk
webpage cache. It's always taken a while to shut down.
E. Liddell
0
days inactive
1
days old
13 comments
7 participants
participants (7)
-
Darrell Anderson -
deloptes -
E. Liddell -
gene heskett -
Jim -
William Morder -
WraithGlade