Hello TDE users/developers:
First, let me take this opportunity to state, once again, TDE is by far, my favorite desktop. I have used it for many years, and continue to support it financially and encourage all users to do likewise.
I am using debian/buster now since it's release. I am also using the "preliminary stable builds" of TDE using the following location:
deb http://mirror.ppa.trinitydesktop.org/trinity-sb buster deps-r14 main-r14
I am having 2 problems. The first is with TDM, which I will describe here. I will ask for help on the 2nd problem later.
In addition to tdm-trinity, I also have 2 other login managers installed: lightdm and lxdm. Both of these are working fine. Only TDM has this problem. I would much prefer to use TDM.
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted. The TDM session appears to run fine, and I can login and run TDE fine. However, because the vt1 console is never ending waiting to complete, I have no other VT consoles. Essentially, I have NO virtual consoles at all. Further, computer resources are always wasted and never ends waiting for the the startup to completely finish. This ONLY happens when booting up with TDM.
I can bootup with LXDM or LIGHTDM and this does not happen. Further, I can issue a "systemctl stop lightdm" or "systemctl stop lxdm" (depending on which is running from the boot), then issue a "systemctl start tdm-trinity" and TDM runs fine and there is not a never ending startjob waiting to complete. So, it appears that TDM does not start in the same order of the boot sequence as LXDM and/or LIGHTDM which is causing this problem.
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course. I hope I can help get his bug fixed before the final release of TDE for buster.
Thanks again.
Jim Freels, PhD (retired)
On Saturday 21 December 2019 00.52:35 James D Freels wrote: (...)
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted.
(...)
Essentially, I have NO virtual consoles at all.
(...)
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course.
Hello,
I am running Buster with the preliminary builds too and I am not having this issue. I have set the timout to 5s however.
What is the startjob that hangs?
Thierry
Anno domini 2019 Sat, 21 Dec 08:37:32 +0100 Thierry de Coulon scripsit:
On Saturday 21 December 2019 00.52:35 James D Freels wrote: (...)
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted.
(...)
Essentially, I have NO virtual consoles at all.
(...)
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course.
Hello,
I am running Buster with the preliminary builds too and I am not having this issue. I have set the timout to 5s however.
What is the startjob that hangs?
May not be of much use (Devuan here) but RND takes an eternity to create entropy and blocks anthing with network written on it (ssh, ...). "haveged" lightens the burden a bit (takes ~ 1 minute to start), but I had to modify the sysv scripts to send all offending processes to the background. Now I'm back to 15 sec. boottime.
Thierry
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
I could certainly try this if you give me the specifics of how you did it. Thanks for the feedback.
On 12/21/19 3:00 AM, Dr. Nikolaus Klepp wrote:
Anno domini 2019 Sat, 21 Dec 08:37:32 +0100 Thierry de Coulon scripsit:
On Saturday 21 December 2019 00.52:35 James D Freels wrote: (...)
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted.
(...)
Essentially, I have NO virtual consoles at all.
(...)
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course.
Hello,
I am running Buster with the preliminary builds too and I am not having this issue. I have set the timout to 5s however.
What is the startjob that hangs?
May not be of much use (Devuan here) but RND takes an eternity to create entropy and blocks anthing with network written on it (ssh, ...). "haveged" lightens the burden a bit (takes ~ 1 minute to start), but I had to modify the sysv scripts to send all offending processes to the background. Now I'm back to 15 sec. boottime.
Thierry
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Anno domini 2019 Sat, 21 Dec 12:14:33 -0500 James D Freels scripsit:
I could certainly try this if you give me the specifics of how you did it. Thanks for the feedback
#apt-get install haveged
... might be sufficient. The rest of my post contains info on how to get it done on sysv - don't know how to do it on systemd.
Nik
On 12/21/19 3:00 AM, Dr. Nikolaus Klepp wrote:
Anno domini 2019 Sat, 21 Dec 08:37:32 +0100 Thierry de Coulon scripsit:
On Saturday 21 December 2019 00.52:35 James D Freels wrote: (...)
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted.
(...)
Essentially, I have NO virtual consoles at all.
(...)
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course.
Hello,
I am running Buster with the preliminary builds too and I am not having this issue. I have set the timout to 5s however.
What is the startjob that hangs?
May not be of much use (Devuan here) but RND takes an eternity to create entropy and blocks anthing with network written on it (ssh, ...). "haveged" lightens the burden a bit (takes ~ 1 minute to start), but I had to modify the sysv scripts to send all offending processes to the background. Now I'm back to 15 sec. boottime.
Thierry
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Turns out I already have haveged installed. I must have tried this in my previous attempt to fix this problem by systemd hacking.
On 12/21/19 12:18 PM, Nikolaus Klepp wrote:
#apt-get install haveged
... might be sufficient. The rest of my post contains info on how to get it done on sysv - don't know how to do it on systemd.
Nik
On Saturday 21 December 2019 09:18:53 Nikolaus Klepp wrote:
Anno domini 2019 Sat, 21 Dec 12:14:33 -0500
James D Freels scripsit:
I could certainly try this if you give me the specifics of how you did it. Thanks for the feedback
#apt-get install haveged
... might be sufficient. The rest of my post contains info on how to get it done on sysv - don't know how to do it on systemd.
Nik
On 12/21/19 3:00 AM, Dr. Nikolaus Klepp wrote:
Anno domini 2019 Sat, 21 Dec 08:37:32 +0100
Thierry de Coulon scripsit:
On Saturday 21 December 2019 00.52:35 James D Freels wrote: (...)
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted.
(...)
Essentially, I have NO virtual consoles at all.
(...)
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course.
Hello,
I am running Buster with the preliminary builds too and I am not having this issue. I have set the timout to 5s however.
What is the startjob that hangs?
May not be of much use (Devuan here) but RND takes an eternity to create entropy and blocks anthing with network written on it (ssh, ...). "haveged" lightens the burden a bit (takes ~ 1 minute to start), but I had to modify the sysv scripts to send all offending processes to the background. Now I'm back to 15 sec. boottime.
Thierry
Most who have had problems with the system hanging would seem to blame it on systemd, and have switched from Debian to Devuan. If your hardware is old, and your resources limited, this might be a good choice. I have had no system hangups whatsoever since making the move to Devuan.
However, it may not be everybody's way; and what really matters, for the actual user, is what works, because we have other things to do besides wrestling with our machines to get them to behave.
Michele Calgaro gave a solution that works for her; look under these headings: "Re: [trinity-users] Has systemd broken Debian this time?" (15 July 2019) "Re: [trinity-users] Systemd" (27 July 2019).
I quote her solution from the latter email:
**** You can uncomment the line with DefaultTimeoutStartSec and DefaultTimeoutStopSec in /etc/systemd/system.conf
DefaultTimeoutStartSec=5s DefaultTimeoutStopSec=5s
Works like a charm.
Cheers Michele
****
I hope this may be of some help. This assumes, of course, that the problem may be with systemd, and not with tdm.
Bill
On Saturday 21 December 2019 18.14:33 James D Freels wrote:
I could certainly try this if you give me the specifics of how you did it. Thanks for the feedback.
in /etc/systemd/system.conf:
(...) #DefaultStandardOutput=journal #DefaultStandardError=inherit DefaultTimeoutStartSec=5s DefaultTimeoutStopSec=5s #DefaultRestartSec=100ms #DefaultStartLimitIntervalSec=10s (...)
Thierry
The startjob that hangs is "Hold".
A start job is running for Hold unt… finishes up (7min 23s / no limit)
I have tried setting the timout to a low number to address this issue, but it does not seem to fix this problem. Perhaps I did not set it in the right way/place.
On 12/21/19 2:37 AM, Thierry de Coulon wrote:
On Saturday 21 December 2019 00.52:35 James D Freels wrote: (...)
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted.
(...)
Essentially, I have NO virtual consoles at all.
(...)
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course.
Hello,
I am running Buster with the preliminary builds too and I am not having this issue. I have set the timout to 5s however.
What is the startjob that hangs?
Thierry
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Fri, 20 Dec 2019 18:52:35 -0500 James D Freels freelsjd@gmail.com wrote:
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted. The TDM session appears to run fine, and I can login and run TDE fine. However, because the vt1 console is never ending waiting to complete, I have no other VT consoles. Essentially, I have NO virtual consoles at all. Further, computer resources are always wasted and never ends waiting for the the startup to completely finish. This ONLY happens when booting up with TDM.
I can bootup with LXDM or LIGHTDM and this does not happen. Further, I can issue a "systemctl stop lightdm" or "systemctl stop lxdm" (depending on which is running from the boot), then issue a "systemctl start tdm-trinity" and TDM runs fine and there is not a never ending startjob waiting to complete. So, it appears that TDM does not start in the same order of the boot sequence as LXDM and/or LIGHTDM which is causing this problem.
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course. I hope I can help get his bug fixed before the final release of TDE for buster.
I dont think its a bug in TDE, this looks like some systemd problem, so a steps to deal with systemd problems has to be followed. Starting with 'systemd-analyze blame' and 'systemd-analyze critical-chain'.
This is a great suggestion. I will give it a try and report back later.
On 12/21/19 3:02 AM, Nick Koretsky wrote:
On Fri, 20 Dec 2019 18:52:35 -0500 James D Freels freelsjd@gmail.com wrote:
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted. The TDM session appears to run fine, and I can login and run TDE fine. However, because the vt1 console is never ending waiting to complete, I have no other VT consoles. Essentially, I have NO virtual consoles at all. Further, computer resources are always wasted and never ends waiting for the the startup to completely finish. This ONLY happens when booting up with TDM.
I can bootup with LXDM or LIGHTDM and this does not happen. Further, I can issue a "systemctl stop lightdm" or "systemctl stop lxdm" (depending on which is running from the boot), then issue a "systemctl start tdm-trinity" and TDM runs fine and there is not a never ending startjob waiting to complete. So, it appears that TDM does not start in the same order of the boot sequence as LXDM and/or LIGHTDM which is causing this problem.
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course. I hope I can help get his bug fixed before the final release of TDE for buster.
I dont think its a bug in TDE, this looks like some systemd problem, so a steps to deal with systemd problems has to be followed. Starting with 'systemd-analyze blame' and 'systemd-analyze critical-chain'.
OK. Had to reboot with TDM active to uncover this issue.
When I issue systemd-analyze blame , I get:
systemd-analyze blame Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs
Of course later never comes since this step continuously hangs. So taking the suggestion, the output from systemctl list-jobs is:
JOB UNIT TYPE STATE 147 getty@tty1.service start waiting 2 multi-user.target start waiting 1 graphical.target start waiting 129 systemd-update-utmp-runlevel.service start waiting 105 plymouth-quit-wait.service start running 146 getty.target start waiting
6 jobs listed.
So, it appears related to plymouth. Is plymouth used in TDM?
Also tried systemd-analyze critical-chain, and get identical output
Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs
On 12/21/19 12:18 PM, James D Freels wrote:
This is a great suggestion. I will give it a try and report back later.
On 12/21/19 3:02 AM, Nick Koretsky wrote:
On Fri, 20 Dec 2019 18:52:35 -0500 James D Freels freelsjd@gmail.com wrote:
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted. The TDM session appears to run fine, and I can login and run TDE fine. However, because the vt1 console is never ending waiting to complete, I have no other VT consoles. Essentially, I have NO virtual consoles at all. Further, computer resources are always wasted and never ends waiting for the the startup to completely finish. This ONLY happens when booting up with TDM.
I can bootup with LXDM or LIGHTDM and this does not happen. Further, I can issue a "systemctl stop lightdm" or "systemctl stop lxdm" (depending on which is running from the boot), then issue a "systemctl start tdm-trinity" and TDM runs fine and there is not a never ending startjob waiting to complete. So, it appears that TDM does not start in the same order of the boot sequence as LXDM and/or LIGHTDM which is causing this problem.
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course. I hope I can help get his bug fixed before the final release of TDE for buster.
I dont think its a bug in TDE, this looks like some systemd problem, so a steps to deal with systemd problems has to be followed. Starting with 'systemd-analyze blame' and 'systemd-analyze critical-chain'.
Anno domini 2019 Sat, 21 Dec 12:30:53 -0500 James D Freels scripsit:
OK. Had to reboot with TDM active to uncover this issue.
When I issue systemd-analyze blame , I get:
systemd-analyze blame Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs
Of course later never comes since this step continuously hangs. So taking the suggestion, the output from systemctl list-jobs is:
JOB UNIT TYPE STATE 147 getty@tty1.service start waiting 2 multi-user.target start waiting 1 graphical.target start waiting 129 systemd-update-utmp-runlevel.service start waiting 105 plymouth-quit-wait.service start running 146 getty.target start waiting
6 jobs listed.
So, it appears related to plymouth. Is plymouth used in TDM?
You can saferly purge all plymouth* packages. It's just eyecandy and a source of interestring problems.
Nik
Also tried systemd-analyze critical-chain, and get identical output
Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs
On 12/21/19 12:18 PM, James D Freels wrote:
This is a great suggestion. I will give it a try and report back later.
On 12/21/19 3:02 AM, Nick Koretsky wrote:
On Fri, 20 Dec 2019 18:52:35 -0500 James D Freels freelsjd@gmail.com wrote:
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted. The TDM session appears to run fine, and I can login and run TDE fine. However, because the vt1 console is never ending waiting to complete, I have no other VT consoles. Essentially, I have NO virtual consoles at all. Further, computer resources are always wasted and never ends waiting for the the startup to completely finish. This ONLY happens when booting up with TDM.
I can bootup with LXDM or LIGHTDM and this does not happen. Further, I can issue a "systemctl stop lightdm" or "systemctl stop lxdm" (depending on which is running from the boot), then issue a "systemctl start tdm-trinity" and TDM runs fine and there is not a never ending startjob waiting to complete. So, it appears that TDM does not start in the same order of the boot sequence as LXDM and/or LIGHTDM which is causing this problem.
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course. I hope I can help get his bug fixed before the final release of TDE for buster.
I dont think its a bug in TDE, this looks like some systemd problem, so a steps to deal with systemd problems has to be followed. Starting with 'systemd-analyze blame' and 'systemd-analyze critical-chain'.
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
This fixed the problem. I think I recall plymouth is needed for kde>3.5 ?
Also, I tried the faster DefaultTimeout times, and that was not the issue here.
Still not sure if this is a bug, but it certainly appears that if plymouth is in the system, it will cause tdm to behave like this ?
On 12/21/19 12:46 PM, Dr. Nikolaus Klepp wrote:
You can saferly purge all plymouth* packages. It's just eyecandy and a source of interestring problems.
Nik
James D Freels composed on 2019-12-21 13:26 (UTC-0500):
This fixed the problem. I think I recall plymouth is needed for kde>3.5 ?
IME, Plymouth is never needed except if running TDE on Mageia, where it's required only because of Mageia's own broken mandatory theming dependencies.
I don't know if it is a TDM bug or not. I DO know that if I boot with lightdm or lxdm and NOT tdm, then this problem does not occur.
My guess is that perhaps tdm is starting at a different "level" then lxdm or lightdm, and causes a conflict of some kind with something else?
On 12/21/19 3:02 AM, Nick Koretsky wrote:
I dont think its a bug in TDE, this looks like some systemd problem, so a steps to deal with systemd problems has to be followed. Starting with 'systemd-analyze blame' and 'systemd-analyze critical-chain'.
James D Freels wrote:
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course. I hope I can help get his bug fixed before the final release of TDE for buster.
Thanks again.
Jim Freels, PhD (retired)
I am amazed that no one suggested following:
There is a known bug related to systemd in /lib/systemd/system/tdm.service Just comment out the Conflicts line
$ cat /lib/systemd/system/tdm.service [Unit] Description=Trinity Display Manager Documentation=man:tdm-trinity(1) #Conflicts=getty@tty7.service plymouth-quit.service After=systemd-user-sessions.service getty@tty7.service plymouth-quit.service
[Service] # temporary safety check until all DMs are converted to correct # display-manager.service symlink handling ExecStartPre=/bin/sh -c '[ "$(basename $(cat /etc/X11/default-display-manager 2>/dev/null))" = "tdm" ]' ExecStart=/opt/trinity/bin/tdm Restart=always
regards
On Sat, 21 Dec 2019 22:33:22 +0100 deloptes deloptes@gmail.com wrote:
James D Freels wrote:
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course. I hope I can help get his bug fixed before the final release of TDE for buster.
Thanks again.
Jim Freels, PhD (retired)
I am amazed that no one suggested following:
There is a known bug related to systemd in /lib/systemd/system/tdm.service Just comment out the Conflicts line
$ cat /lib/systemd/system/tdm.service [Unit] Description=Trinity Display Manager Documentation=man:tdm-trinity(1) #Conflicts=getty@tty7.service plymouth-quit.service After=systemd-user-sessions.service getty@tty7.service plymouth-quit.service
[Service] # temporary safety check until all DMs are converted to correct # display-manager.service symlink handling ExecStartPre=/bin/sh -c '[ "$(basename $(cat /etc/X11/default-display-manager 2>/dev/null))" = "tdm" ]' ExecStart=/opt/trinity/bin/tdm Restart=always
This a hacky solution that can theoretically led to problems (afaik depending on video drivers used plymouth could prevent Xorg from starting). The source of the problem here is that tdm doesn't correctly signal to plymouth to quit. So correct action is to disable/uninstall plymouth, not to edit tdm.service
Nick Koretsky wrote:
This a hacky solution that can theoretically led to problems (afaik depending on video drivers used plymouth could prevent Xorg from starting). The source of the problem here is that tdm doesn't correctly signal to plymouth to quit. So correct action is to disable/uninstall plymouth, not to edit tdm.service
Interesting - what should tdm do to signal to plymouth to quit? I don't want to uninstall it.
Nick Koretsky wrote:
This a hacky solution that can theoretically led to problems (afaik depending on video drivers used plymouth could prevent Xorg from starting). The source of the problem here is that tdm doesn't correctly signal to plymouth to quit. So correct action is to disable/uninstall plymouth, not to edit tdm.service
Also why after commenting out this line tdm starts and plymouth is not running anymore?
deloptes composed on 2019-12-22 01:20 (UTC+0100):
Also why after commenting out this line tdm starts and plymouth is not running anymore?
The After line still applies.
Well, this has turned out to be a rather fruitful discussion. My attitude about TDE is a bit like the history of TeX. If you recall Knuth made a long-standing offer to pay people to find errors in his software and he would pay them if he agreed that it was a bug, and it got fixed. He did not add many new features, but instead, concentrated on getting all the errors out. As a result, TeX has not changed in feature set, but is still used by many people worldwide as one of the most error-free and powerful typesetting tools available.
I am not suggested any monetary reward, but I do think that one of the benefits of TDE may be that eventually it could become error-free. Many bugs, like this one, are caused by software interfaces outside TDE, and I suspect this will go on forever. But, internally, we have a chance to have an error-free desktop for Linux that could live for the ages. I do think TDE is becoming more popular now than ever, perhaps for that reason.
I will sign off now that we think we have gotten this "bug" at least defined. I will leave it to the experts to decide how best to fix it for the ages.
Thank you to all for your help and wisdom.
Merry Christmas.
On 12/20/19 6:52 PM, James D Freels wrote:
Hello TDE users/developers:
First, let me take this opportunity to state, once again, TDE is by far, my favorite desktop. I have used it for many years, and continue to support it financially and encourage all users to do likewise.
I am using debian/buster now since it's release. I am also using the "preliminary stable builds" of TDE using the following location:
deb http://mirror.ppa.trinitydesktop.org/trinity-sb buster deps-r14 main-r14
I am having 2 problems. The first is with TDM, which I will describe here. I will ask for help on the 2nd problem later.
In addition to tdm-trinity, I also have 2 other login managers installed: lightdm and lxdm. Both of these are working fine. Only TDM has this problem. I would much prefer to use TDM.
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first to initiate TDM into the boot sequence), it starts fine, but continuously hangs in the main console with one of the infamous systemd problems wherein we get the "a startjob is running ..." and it NEVER ends until rebooted. The TDM session appears to run fine, and I can login and run TDE fine. However, because the vt1 console is never ending waiting to complete, I have no other VT consoles. Essentially, I have NO virtual consoles at all. Further, computer resources are always wasted and never ends waiting for the the startup to completely finish. This ONLY happens when booting up with TDM.
I can bootup with LXDM or LIGHTDM and this does not happen. Further, I can issue a "systemctl stop lightdm" or "systemctl stop lxdm" (depending on which is running from the boot), then issue a "systemctl start tdm-trinity" and TDM runs fine and there is not a never ending startjob waiting to complete. So, it appears that TDM does not start in the same order of the boot sequence as LXDM and/or LIGHTDM which is causing this problem.
It is at this point, where I need some help in how to fix it, and I suspect that all debian/buster users may have the same issue, but not sure of course. I hope I can help get his bug fixed before the final release of TDE for buster.
Thanks again.
Jim Freels, PhD (retired)
-
deloptes -
Dr. Nikolaus Klepp -
Felix Miata -
James D Freels -
Nick Koretsky -
Nikolaus Klepp
-
Thierry de Coulon -
William Morder via trinity-users