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.
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.
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.
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.
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.
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:
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.
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.
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:
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.
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.
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
-------- Original Message -------- On 4/19/25 12:38 AM, William Morder via tde-users users@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.
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@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.
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.
tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
Cheers, Gene Heskett, CET.
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 :-)
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
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.
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. :)
Darrell Anderson via tde-users wrote:
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. :)
I know some more like you. I personally am 50/50 But in any case respect for dealing with this - useful information for people who do not have time to trace all data mining tactics.
On Fri, 18 Apr 2025 21:39:29 -0500 Darrell Anderson via tde-users users@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
-
Darrell Anderson -
deloptes -
E. Liddell -
gene heskett -
Jim -
William Morder -
WraithGlade