By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 2806 - tdm fails to shutdown plymouth/ no tty
Summary: tdm fails to shutdown plymouth/ no tty
Status: REOPENED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdebase (show other bugs)
Version: R14.0.x [Trinity]
Hardware: amd64 Linux
: P5 blocker
Assignee: Michele Calgaro
URL:
Depends on:
Blocks: R14.0.12
  Show dependency treegraph
 
Reported: 2017-08-21 04:58 CDT by wofgdkncxojef
Modified: 2023-07-31 03:56 CDT (History)
8 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name: tdm


Attachments
allow systemd to call plymouth-quit.service (471 bytes, patch)
2019-05-13 10:23 CDT, Bastien Mourgues
Details | Diff
tdm_ServiceAsSDM.patch (978 bytes, patch)
2021-11-24 05:24 CST, Roman Savochenko
Details | Diff
tdm_ServiceAsSDM.patch (763 bytes, patch)
2022-07-30 00:55 CDT, Roman Savochenko
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description wofgdkncxojef 2017-08-21 04:58:28 CDT
Like the title sais, when logged in with tdm, they are no tty.
ctrl+alt+F1 etc have no loggin screen for the terminals.
There's the boot splash, and going back to the desktop, can crash it.

Linux mint 18.2 Mate 64bits
Comment 1 wofgdkncxojef 2017-11-03 01:48:15 CDT
the problem was with plymouth!!!

tdm and plymouth (boot splash screen, in ubuntu) are in conflict.
plymouth doesn't shutdown, blocks the ttys and consumes ~5% of CPU (on my machine). plymouth hasn't crashed.

the command, responds that it's running.
sudo plymouth --ping && echo plymouth is running || echo plymouth NOT running

you can stop it in a normal session with this command
sudo plymouth --quit

you can also, deactivate the splash option in grub

edit /etc/default/grub
change this line
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to
GRUB_CMDLINE_LINUX_DEFAULT=""
save
and run
sudo update-grub

(Linux mint 18.2 Mate 64bits)
Comment 2 deloptes 2017-12-09 19:54:20 CST
but it looks like it is not a TDE problem - correct?

can this be closed please?
Comment 3 wofgdkncxojef 2017-12-10 03:58:22 CST
.... yea, my previous comment was a bit unclear.

tdm fails to shutdown plymouth...
It's indeed a bug in tdm.
Comment 4 deloptes 2017-12-10 06:08:34 CST
I have observed similar behavior, when processes at startup do not complete.
After going back from systemd to init behavior is normal.

Can you verify all processes are completed  at startup - I am sure you are using systemd, so try journalctl.

IMO it is problem between systemd and perhaps tde, perhaps not

regards
Comment 5 wofgdkncxojef 2017-12-10 07:52:50 CST
It seamed to work fine with lightDM with TDE and MATE.

login in MATE with tdm gives the same behavior.
plymouth is still running and messes things up.

I don't think that's a systemd issue
(this time :p)
Comment 6 Q4OS Team 2017-12-10 11:40:38 CST
"TDM fails to shutdown plymouth" - I can confirm this issue, I guess it's a TDM issue. Debian 9 Stretch, TDE 14.0.5 testing.
Comment 7 deloptes 2017-12-10 11:49:05 CST
OK, but I use Stretch with plymouth and TDE (I use the dev branch 14.1 and no systemd as init proc) and I do not have this issue.
I had it twice when using systemd, because startup processes get delayed by systemd. After waiting for some time (systemd times out the startup processes) the rest of the startup actions complete and login prompt on console comes back.

It might be TDE, so could you please provide a way to reproduce it also try alternatively without systemd

ii  systemd                               232-25+deb9u1                               amd64        system and service manager
ii  systemd-shim                          10-3                                        amd64        shim for systemd
ii  sysv-rc                               2.88dsf-59.9                                all          System-V-like runlevel change mechanism
ii  sysvinit-core                         2.88dsf-59.9                                amd64        System-V-like init utilities
ii  sysvinit-utils                        2.88dsf-59.9                                amd64        System-V-like utilities


ii  libplymouth4:amd64                    0.9.2-4                                     amd64        graphical boot animation and logger - shared libraries
ii  plymouth                              0.9.2-4                                     amd64        boot animation, logger and I/O multiplexer
ii  plymouth-themes                       0.9.2-4                                     amd64        boot animation, logger and I/O multiplexer - themes
ii  plymouth-x11                          0.9.2-4                                     amd64        boot animation, logger and I/O multiplexer - X11 renderer


ii  tdebase-trinity                       4:14.1.0-0debian8.0.5+eko3                  all          base components from the official TDE release
Comment 8 Q4OS Team 2017-12-10 14:39:21 CST
".. could you please provide a way to reproduce it also try alternatively without systemd"

@deloptes@yahoo.com
Just proceed a fresh Debian 9 Stretch, TDE 14.0.5 testing, and Plymouth installation and set a Plymouth theme.

It's obviously systemd related, as it appears to be a conflict of TDM and Plymouth systemd service. As mentioned above, other display managers, for ex. lightDM, work fine with Plymouth.
Comment 9 deloptes 2017-12-10 16:41:38 CST
Thanks,

I have experienced the same. I don't recall how it was solved, but there was simple solution to it.

Anyway thank you for the information, if you have a solution, post a patch here.

regards
Comment 10 Michele Calgaro 2018-05-16 16:13:10 CDT
Added to R14.0.6 bug list
Comment 11 Bastien Mourgues 2019-05-13 10:23:22 CDT
Created attachment 2916 [details]
allow systemd to call plymouth-quit.service

Hello,

Conflicts line in /lib/systemd/system/tdm.service prevents sytemd to call  plymouth-quit.service

Removing or commenting it allows plymouth to terminate, and system to behave as expected.
Tested on debian stretch.

Hope this can help
Comment 12 deloptes 2019-05-13 12:38:05 CDT
Indeed I agree because the "After" directive tells systemd to quit the tde.service after getty@tty7.service and plymouth-quit.service, which are mentioned in the "Conflict" directive.
Comment 13 Kevin Bhasi 2019-06-10 09:44:12 CDT
I'm on Debian 10 beta with Plymouth disabled and showing all startup messages through kernel boot arguments, and Trinity R14.0.7 preliminary stable builds, and am able to see that systemd is "waiting for boot process to finish" or something along those lines. I too get no text mode consoles, only blinking cursors.

My only other Debian 10 installation (which I can't currently access as of posting this comment) uses either SDDM or GDM, but not TDM, so I decided to look through the source code for SDDM and found some extra things in their systemd service file (compared to the patch submitted by Bastien) which can be found here: https://github.com/sddm/sddm/blob/v0.18.1/services/sddm.service.in

However, based on the Debian edit of the same source file that I saw, I believe that the Debian version of SDDM starts up on tty7 instead of the upstream setting of tty1, however, it's easier for me to link to the upstream file rather than the Debian file.
Comment 14 Roman Savochenko 2021-11-24 05:24:25 CST
Created attachment 3026 [details]
tdm_ServiceAsSDM.patch

The patch of switching TDM in the SDDM mode and I have no conflicts with Plymouth here.

The patch also fixes of Plymouth freeze in waiting of the finish when the file /var/log/boot.log can grow and devour all available disk space on systems with small disks and working 24/7.
Comment 15 Michele Calgaro 2021-11-27 23:03:12 CST
I am trying to reproduce this problem but I can't.
Debian boookworm, systemd, plymounth and some theme selected.
Can anyone point me what else is required to reproduce it?
Comment 16 Michele Calgaro 2021-12-10 01:25:20 CST
https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/247

This is a proposed fix. Could someone help verifying it works fine? I occasionally have the system to hangup during shutdown, but I can't do that systematically, so on my side I can only wait for a couple of weeks and check I don't have any more hang up. If someone can reproduce the issues systematically, it would be great if he/she could test the above proposed fix.
Comment 17 Michele Calgaro 2021-12-10 01:25:49 CST
By the way, thanks all the people in this bug report for comments and suggestions.
Comment 18 Michele Calgaro 2021-12-11 20:45:33 CST
I found a way to test it systematically. PR has been merged.
Comment 19 Roman Savochenko 2022-07-30 00:55:03 CDT
Created attachment 3046 [details]
tdm_ServiceAsSDM.patch

The problem is actual one for Debian 9, then I again have  updated the SDM mode patch for that!
Comment 20 Roman Savochenko 2023-07-14 01:07:00 CDT
In TDE14.1 the bug became even worse, that is the system often hangs at the exit on the black screen even with the SDM patch!!!
Comment 21 deloptes 2023-07-14 10:33:03 CDT
Shat is SDM BTW.
I've been using 14.1 for the past 3 years on several machines and with the fix in the systemd service file it never caused a problem.
Are you sure it is caused by tdm.service? Are you running X on tty1/7?

generally speaking the systemd issue of hanging system is caused by various services that do not stop properly. The default timeout for systemd AFAIR is 1,5min. You can reduce the value and will have the system shut down faster.

BR
Comment 22 Roman Savochenko 2023-07-14 11:09:31 CDT
(In reply to deloptes from comment #21)
> Shat is SDM BTW.

I have applied the SDM patch after get the first hang.

> I've been using 14.1 for the past 3 years on several machines and with the
> fix in the systemd service file it never caused a problem.
> Are you sure it is caused by tdm.service? Are you running X on tty1/7?

The problem was appeared for me just after updating to 14.1 of two fine working Debian 11 system on 14.0.13 and on different hardware.

> generally speaking the systemd issue of hanging system is caused by various
> services that do not stop properly. The default timeout for systemd AFAIR is
> 1,5min. You can reduce the value and will have the system shut down faster.

Today I have seen already a dead hang, not at typical 1 ... 1.5 minutes.
Comment 23 deloptes 2023-07-14 15:10:07 CDT
did you press ESC and had a look where it hangs?

I mean I am not sure what exactly are the steps to reproduce
 1. you shut down
 2. TDE exits 
 3. it hangs in plymouth
 4. press ESC and see what service is causing the issue

or have a look at the journal
Comment 24 Roman Savochenko 2023-07-20 10:27:54 CDT
(In reply to deloptes from comment #23)
> did you press ESC and had a look where it hangs?
There is no reaction at pressing ESC and if with the SDM patch I see the kernel messages, without the patch I see only blinking cursor.

> I mean I am not sure what exactly are the steps to reproduce
I have had reproduction of the problem only two times after your last comment, when after the first reproduction I removed the SDM patch for see the blinking cursor.
Comment 25 Roman Savochenko 2023-07-21 00:02:29 CDT
(In reply to deloptes from comment #23)
> did you press ESC and had a look where it hangs?
And the sequence is:
1. shut down
2. TDE exits
3. the completely black screen is appeared with blinking cursor in the top left angle, where ESC doesn't work and what can last from 20 seconds and up to infinity  (one time).
4. the plymoth splash screen is appeared after from 20 seconds or never and power off
Comment 26 Roman Savochenko 2023-07-23 11:38:12 CDT
For example see this file — http://ftp.oscada.org/Misc/VID_20230723_161513.mp4
Comment 27 deloptes 2023-07-31 02:13:17 CDT
Your access to the server resources is FORBIDDEN, due to you are detected as an attacker!!!
If that is wrong, please write a claim EMail for removing your IP from the black list.
Sorry for the inconvenience!
Comment 28 Roman Savochenko 2023-07-31 03:56:05 CDT
(In reply to deloptes from comment #27)
> Your access to the server resources is FORBIDDEN, due to you are detected as
> an attacker!!!
Sorry, I have opened the access!