This type of delay trying to restart or shutdown often happens here on far more than a single installation. The instant case is 14.0.12 on host ab560 running Bullseye. Notable slices from journalctl -b -1:
Dec 14 20:55:56 ab560 systemd[1]: dev-hugepages.mount: Succeeded. Dec 14 20:55:56 ab560 systemd[1]: proc-sys-fs-binfmt_misc.automount: Got hangup/error on autofs pipe from kernel. Likely our automount point has been unmounted by someone or something else? Dec 14 20:55:56 ab560 systemd[1]: proc-sys-fs-binfmt_misc.automount: Failed with result 'unmounted'. Dec 14 20:55:56 ab560 systemd-logind[532]: System is rebooting. Dec 14 20:55:56 ab560 systemd[1]: Stopping Session 3 of user root. Dec 14 20:55:56 ab560 systemd[1]: Removed slice system-modprobe.slice. ... Dec 14 20:55:56 ab560 watchdog[773]: stopping daemon (5.16) Dec 14 20:55:56 ab560 systemd[1]: Stopping watchdog daemon... Dec 14 20:55:56 ab560 systemd[1]: nfs-blkmap.service: Main process exited, code=exited, status=1/FAILURE Dec 14 20:55:56 ab560 systemd[1]: nfs-blkmap.service: Failed with result 'exit-code'. Dec 14 20:55:56 ab560 systemd[1]: Stopped pNFS block layout mapping daemon. Dec 14 20:55:56 ab560 systemd[1]: session-3.scope: Succeeded. ... Dec 14 20:55:56 ab560 systemd[1]: Reached target Unmount All Filesystems. Dec 14 20:55:56 ab560 systemd[1]: user-runtime-dir@0.service: Succeeded. Dec 14 20:55:56 ab560 systemd[1]: Stopped User Runtime Directory /run/user/0. Dec 14 20:55:56 ab560 systemd[1]: Removed slice User Slice of UID 0. Dec 14 20:55:56 ab560 systemd[1]: user-0.slice: Consumed 10.876s CPU time. Dec 14 20:55:56 ab560 systemd[1]: watchdog.service: Control process exited, code=exited, status=1/FAILURE Dec 14 20:55:56 ab560 systemd[1]: watchdog.service: Failed with result 'exit-code'. Dec 14 20:55:56 ab560 systemd[1]: Stopped watchdog daemon. Dec 14 20:55:56 ab560 systemd[1]: watchdog.service: Triggering OnFailure= dependencies. Dec 14 20:55:56 ab560 systemd[1]: Requested transaction contradicts existing jobs: Transaction for wd_keepalive.service/start is destructive (systemd-sysctl.service has 'stop' job queued, > Dec 14 20:55:56 ab560 systemd[1]: watchdog.service: Failed to enqueue OnFailure= job, ignoring: Transaction for wd_keepalive.service/start is destructive (systemd-sysctl.service has 'stop'> Dec 14 20:55:56 ab560 systemd[1]: Stopped target Multi-User System. ... Dec 14 20:55:56 ab560 systemd[1]: smbd.service: Succeeded. Dec 14 20:55:56 ab560 systemd[1]: Stopped Samba SMB Daemon. Dec 14 20:55:56 ab560 nmbd[528]: [2021/12/14 20:55:56.728880, 0] ../../source3/nmbd/nmbd.c:59(terminate) Dec 14 20:55:56 ab560 nmbd[528]: Got SIGTERM: going down... Dec 14 20:55:56 ab560 systemd[1]: Stopping Samba NMB Daemon... Dec 14 20:55:56 ab560 systemd[1]: hddtemp.service: Succeeded. Dec 14 20:55:56 ab560 systemd[1]: Stopped LSB: disk temperature monitoring daemon. Dec 14 20:55:56 ab560 systemd[1]: nmbd.service: Succeeded. Dec 14 20:55:56 ab560 systemd[1]: Stopped Samba NMB Daemon. Dec 14 20:55:56 ab560 systemd[1]: Stopped target Network is Online. Dec 14 20:56:06 ab560 systemd-logind[532]: Failed to stop user service 'user@0.service', ignoring: Transport endpoint is not connected Dec 14 20:57:26 ab560 systemd[1]: tdm.service: State 'stop-sigterm' timed out. Killing. Dec 14 20:57:26 ab560 systemd[1]: tdm.service: Killing process 732 (tdm) with signal SIGKILL. Dec 14 20:57:26 ab560 systemd[1]: tdm.service: Killing process 1119 (tdm) with signal SIGKILL. Dec 14 20:57:26 ab560 systemd[1]: tdm.service: Killing process 1120 (tdm_greet) with signal SIGKILL. Dec 14 20:57:26 ab560 systemd[1]: tdm.service: Killing process 1138 (tdm_greet) with signal SIGKILL. Dec 14 20:57:26 ab560 systemd[1]: tdm.service: Main process exited, code=killed, status=9/KILL Dec 14 20:57:27 ab560 systemd[1]: tdm.service: Failed with result 'timeout'. Dec 14 20:57:27 ab560 systemd[1]: Stopped Trinity Display Manager. Dec 14 20:57:27 ab560 systemd[1]: tdm.service: Consumed 5.134s CPU time. Dec 14 20:57:27 ab560 systemd[1]: Stopping User Login Management... ... Dec 14 20:57:27 ab560 systemd[1]: Reached target Reboot. Dec 14 20:57:27 ab560 systemd[1]: Shutting down. Dec 14 20:57:27 ab560 systemd[1]: Using hardware watchdog 'iTCO_wdt', version 0, device /dev/watchdog Dec 14 20:57:27 ab560 systemd[1]: Set hardware watchdog to 10min. Dec 14 20:57:27 ab560 kernel: watchdog: watchdog0: watchdog did not stop! Dec 14 20:57:27 ab560 systemd-shutdown[1]: Syncing filesystems and block devices. Dec 14 20:57:27 ab560 systemd-shutdown[1]: Sending SIGTERM to remaining processes... Dec 14 20:57:27 ab560 systemd-journald[288]: Journal stopped
On 2021/12/15 11:16 AM, Felix Miata wrote:
This type of delay trying to restart or shutdown often happens here on far more than a single installation. The instant case is 14.0.12 on host ab560 running Bullseye. Notable slices from journalctl -b -1:
Hi Felix, What I do almost immediately in a new system with systemd is to edit its config file and set a timeout of 5s for job startup and shutdown. No more 90 seconds waits :-)
Cheers Michele
Michele Calgaro via tde-devels composed on 2021-12-16 22:01 (UTC+0900):
Felix Miata wrote:
This type of delay trying to restart or shutdown often happens here on far more than a single installation. The instant case is 14.0.12 on host ab560 running Bullseye. Notable slices from journalctl -b -1:
What I do almost immediately in a new system with systemd is to edit its config file and set a timeout of 5s for job startup and shutdown. No more 90 seconds waits :-)
Logic says something is wrong with TDM that needs repair if it needs 5 or more seconds to shut down when from it is selected to either reboot or shut down on some systems, but as little as a mere blink of an eye gets the whole OS shut down on others (Fedora typically is super fast to exit).
On Friday, 17. December 2021, Michael Howard via tde-devels wrote:
On 17/12/2021 13:17, Michele Calgaro via tde-devels wrote:
On 2021/12/17 01:51 PM, Felix Miata wrote:
Logic says something is wrong with TDM that needs repair
We could very well argue that "Logic says something is wrong with *systemd* that needs repair"
+1
If you don´t mind, you can use my changes. This changes worked for me in ubuntu 16.04 and 20.04. I have proposed the change some years ago... If I remember, I have used the sddm.service file as template.
Stef
If you don´t mind, you can use my changes. This changes worked for me in ubuntu 16.04 and 20.04. I have proposed the change some years ago... If I remember, I have used the sddm.service file as template.
Stef
Hi Stef, not sure what changes you proposed in the past, but if you can point us to them we will take a look. Is it something similar to what is found here https://bugs.pearsoncomputing.net/show_bug.cgi?id=2806? Or something different?
Cheers Michele
On Friday, 17. December 2021, Michele Calgaro via tde-devels wrote:
If you don´t mind, you can use my changes. This changes worked for me in ubuntu 16.04 and 20.04. I have proposed the change some years ago... If I remember, I have used the sddm.service file as template.
Stef
Hi Stef, not sure what changes you proposed in the past, but if you can point us to them we will take a look. Is it something similar to what is found here https://bugs.pearsoncomputing.net/show_bug.cgi?id=2806? Or something different?
Cheers Michele
No it was a mail on the trinty-users mailing list in Aug. 2016. At the moment I have this service file placed in /etc/systemd/system/, so that it survives updates.
Stef
On Tuesday, 21. December 2021, update wrote:
On Friday, 17. December 2021, Michele Calgaro via tde-devels wrote:
If you don´t mind, you can use my changes. This changes worked for me in ubuntu 16.04 and 20.04. I have proposed the change some years ago... If I remember, I have used the sddm.service file as template.
Stef
Hi Stef, not sure what changes you proposed in the past, but if you can point us to them we will take a look. Is it something similar to what is found here https://bugs.pearsoncomputing.net/show_bug.cgi?id=2806? Or something different?
Cheers Michele
No it was a mail on the trinty-users mailing list in Aug. 2016. At the moment I have this service file placed in /etc/systemd/system/, so that it survives updates.
Stef
Sorry but I have missed the "a stop job". My Problem was at startup: "a start job"... So maybe the problems are not directly related...
Best Stef
Hi Stef, not sure what changes you proposed in the past, but if you can point us to them we will take a look. Is it something similar to what is found here https://bugs.pearsoncomputing.net/show_bug.cgi?id=2806? Or something different?
Cheers Michele
No it was a mail on the trinty-users mailing list in Aug. 2016. At the moment I have this service file placed in /etc/systemd/system/, so that it survives updates.
Stef
Sorry but I have missed the "a stop job". My Problem was at startup: "a start job"... So maybe the problems are not directly related...
Best Stef ____________________________________________________
Thanks Stef, I traced the email and found your suggestion. https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
The file is now pretty similar to the tdm.service in master code. The "OnFailure" is interesting, although in current code of sddm it has been commented out.
Cheers Michele