24 Jul
2019
24 Jul
'19
4:41 p.m.
I'm encountering this shutdown delay too frequently. What causes it? Current
instance is on Buster, host fi965.
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
24 Jul
24 Jul
4:57 p.m.
On Wed July 24 2019 09:41:18 Felix Miata wrote:
I'm encountering this shutdown delay too
frequently. What causes it?
Current instance is on Buster, host fi965.
FWIW I'm not seeing that with several sysvinit Busters - mostly amd64
or multiarch but also at least one very very slow 192MB i386 test box.
--Mike
5:41 p.m.
On Wed, Jul 24, 2019 at 12:57 PM Mike Bird <mgb-trinity(a)yosemite.net> wrote:
On Wed July 24 2019 09:41:18 Felix Miata wrote:
Hi Mike the stop jobs are almost always caused by systemd services so you
should not get them on systems using sysvinit. Tracking them down is
sometimes a real pain the other option is to change the time out on systemd
to force it to terminate sonner than 90 seconds.
I'm encountering this shutdown delay too
frequently. What causes it?
Current instance is on Buster, host fi965.
FWIW I'm not seeing that with several sysvinit Busters - mostly amd64
or multiarch but also at least one very very slow 192MB i386 test box.
--Mike
5:55 p.m.
Anno domini 2019 Wed, 24 Jul 09:57:40 -0700
Mike Bird scripsit:
On Wed July 24 2019 09:41:18 Felix Miata wrote:
I have seen it, too, on beowulf and ascii. My workaround was just to kill tde the hard way
when I shut down my computers (over acpi hooks)
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
I'm encountering this shutdown delay too
frequently. What causes it?
Current instance is on Buster, host fi965.
FWIW I'm not seeing that with several sysvinit Busters - mostly amd64
or multiarch but also at least one very very slow 192MB i386 test box.
--Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)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
6 p.m.
New subject: A stop job is running for Trinity Display Manager (## / 1min 30s)
Mike Bird wrote:
FWIW I'm not seeing that with several sysvinit
Busters - mostly amd64
or multiarch but also at least one very very slow 192MB i386 test box.
It is a known bug - I do not recall which one, but the essence is that in
/lib/systemd/system/tdm.service
you should remove
Conflicts=getty(a)tty7.service plymouth-quit.service
or just comment it out. Then systemd will shutdown tdm properly
regards
6:53 p.m.
deloptes composed on 2019-07-24 20:00 (UTC+0200):
Mike Bird wrote:
> FWIW I'm not seeing that with several sysvinit
Busters - mostly amd64
> or multiarch but also at least one very very slow 192MB i386 test box.
It is a known bug -
Trinity bug? Systemd? Debian?
# grep RETT /etc/os-release
PRETTY_NAME="Debian GNU/Linux bullseye/sid"
# dpkg -l | grep outh
# systemctl list-unit-files | egrep 'outh|tty7'
# systemctl list-units | egrep 'outh|tty7'
# grep outh /lib/systemd/system/tdm.service
Conflicts=getty(a)tty7.service plymouth-quit.service
After=systemd-user-sessions.service getty(a)tty7.service plymouth-quit.service
#
Nothing should ever wait on something that does not exist.
I do not recall which one, but the essence is that in
/lib/systemd/system/tdm.service
you should remove
Conflicts=getty(a)tty7.service plymouth-quit.service
or just comment it out. Then systemd will shutdown tdm
properly
Instead, I tried two versions of /etc/systemd/system/tdm.service, both of which worked:
First try:
**********
[Unit]
Description=Trinity Display Manager
Documentation=man:tdm-trinity(1)
Conflicts=
After=
[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
Second try:
***********
[Unit]
Conflicts=
After=
[Service]
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
25 Jul
25 Jul
8:43 a.m.
New subject: [trinity-users] A stop job is running for Trinity Display Manager
On Wednesday 24 July 2019 20:53:57 Felix Miata wrote:
/etc/systemd/system/tdm.service
If I change to that :
Conflicts=
After=
The X server doesn't start.
If I remove this line :
"Conflicts=getty(a)tty7.service plymouth-quit.service"
It seems better, no wait when I stop the computer.
Have a good day,
André
9:01 a.m.
New subject: [trinity-users] A stop job is running for Trinity Display Manager
andre_debian(a)numericable.fr composed on 2019-07-25 10:43 (UTC+0200):
Felix Miata wrote:
> /etc/systemd/system/tdm.service
If I change to that :
> Conflicts=
> After=
The X server doesn't start.
If I remove this line :
"Conflicts=getty(a)tty7.service plymouth-quit.service"
It seems better, no wait when I stop the computer.
Whether what I did might work for others may depend on the distro used and/or
whether or how plymouth is configured and/or installed. None of my installations
have plymouth installed except for Mageia, which is unusable if plymouth
installation is disallowed. In Mageia I include plymouth.enable=0 or noplymouth on
Grub's kernel cmdline and/or disable plymouth with systemctl.
For purposes of this thread, /etc/systemd/system/tdm.service did not exist. I
copied it from /lib/systemd/system/ and then modified it. IIRC, I was using
Bullseye only, not Buster as I wrote in OP.
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
11:30 a.m.
New subject: A stop job is running for Trinity Display Manager
Felix Miata wrote:
Whether what I did might work for others may depend on
the distro used
and/or whether or how plymouth is configured and/or installed. None of my
installations have plymouth installed except for Mageia, which is unusable
if plymouth installation is disallowed. In Mageia I include
plymouth.enable=0 or noplymouth on Grub's kernel cmdline and/or disable
plymouth with systemctl.
For purposes of this thread, /etc/systemd/system/tdm.service did not
exist. I copied it from /lib/systemd/system/ and then modified it. IIRC, I
was using Bullseye only, not Buster as I wrote in OP.
Always better to test on default setup - I am not sure if plymouth is
installed by default, but I tested on a fresh installed Debian and this
exactly solved the problem. It was also confirmed in the original bug
report. No need to further muddy the waters.
What I understand is perhaps it is a plymouth related. If I have the time I
would do some testing, find the bug and update there.
regards
11:27 a.m.
New subject: A stop job is running for Trinity Display Manager (## / 1min 30s)
Felix Miata wrote:
Instead, I tried two versions of
/etc/systemd/system/tdm.service, both of
which worked:
It is enough to remove the conflicts for now - there will be a patch at some
point of time in the future. The After part is OK and IMO it is important
as it says when this is to be executed - obviously it contradicts to
Conflicts and systemd stays waiting for something that never happens. But
thank you for your testing - if you find the bug put it there.
Yes, I am on debian.
regards
1748
days inactive
1749
days old
9 comments
6 participants
participants (6)
-
andre_debian＠numericable.fr -
deloptes -
Dr. Nikolaus Klepp -
Felix Miata -
Mike Bird -
Pisini, John