I encounter this highly annoying message and 90 second shutdown delay too often. Why does TDM object to cmdline shutdown or reboot commands from login on the vttys? How can it be stopped? The immediate inducement to write this comes from Buster, but it happens in Stretch and openSUSE too, both in UEFI and legacy contexts.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2018/07/19 05:08 PM, Felix Miata wrote:
I encounter this highly annoying message and 90 second shutdown delay too often. Why does TDM object to cmdline shutdown or reboot commands from login on the vttys? How can it be stopped? The immediate inducement to write this comes from Buster, but it happens in Stretch and openSUSE too, both in UEFI and legacy contexts.
Thanks systemd........... The best you can do is to reduce the timeout from 90 s to small value. Cheers Michele
On Thursday 19 July 2018 07:11:52 am Michele Calgaro wrote:
On 2018/07/19 05:08 PM, Felix Miata wrote:
I encounter this highly annoying message and 90 second shutdown delay too often. Why does TDM object to cmdline shutdown or reboot commands from login on the vttys? How can it be stopped? The immediate inducement to write this comes from Buster, but it happens in Stretch and openSUSE too, both in UEFI and legacy contexts.
Thanks systemd........... The best you can do is to reduce the timeout from 90 s to small value.
Not sure what exact command you're running, but do also add a halt flag if it's available.
"option to halt services before rebooting. "shutdown -h now" is a graceful shutdown, and "reboot -h now" is a graceful reboot." --Source unknown (CentOS)
MySQL likes to break tables otherwise...
Best, Michael
Michael composed on 2018-07-19 10:47 (UTC-0500):
Michele Calgaro wrote:
Felix Miata wrote:
I encounter this highly annoying message and 90 second shutdown delay too often. Why does TDM object to cmdline shutdown or reboot commands from login on the vttys? How can it be stopped? The immediate inducement to write this comes from Buster, but it happens in Stretch and openSUSE too, both in UEFI and legacy contexts.
Thanks systemd........... The best you can do is to reduce the timeout from 90 s to small value.
Reduce the timeout of exactly what/where? This happens with the openSUSEes and the Debians.
Continuous Ctrl-Alt-Delete should force immediate response, but not unusually it makes the situation worse, freezing after 90 seconds instead of the expectation, necessitating power or reset button.
Not sure what exact command you're running, but do also add a halt flag if it's available.
"option to halt services before rebooting. "shutdown -h now" is a graceful shutdown, and "reboot -h now" is a graceful reboot." --Source unknown (CentOS)
# alias | egrep 'boo|ff' alias Off='cd; umount -a; shutdown -h now' alias Reboot='cd; umount -a; shutdown -r now'
These I do whilst logged out of the TDM greeter, so it shouldn't be doing anything but waiting. It shouldn't matter what it's waiting for, whether an attempt to log in or a direction to reboot or shutdown.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Reduce the timeout of exactly what/where? This happens with the openSUSEes and the Debians./etc/systemd/system.comf
Uncomment and change like this: DefaultTimeoutStartSec=5s DefaultTimeoutStopSec=5s This should reduce the wait time to 5 seconds.
"option to halt services before rebooting. "shutdown -h now" is a graceful shutdown, and "reboot -h now" is a graceful reboot."
The problem is after this point and I have not been able to understand what triggers it. If you google, you will find a lot of similar complains for whatever other job..... cheers Michele
Michele Calgaro composed on 2018-07-20 10:16 (UTC+0800):
Reduce the timeout of exactly what/where? This happens with the openSUSEes and the Debians./etc/systemd/system.comf
Uncomment and change like this: DefaultTimeoutStartSec=5s DefaultTimeoutStopSec=5s This should reduce the wait time to 5 seconds.
Bad idea. This system has no SDD. I did exactly that, and bunches of startup units failed
# journalctl -b -1 | grep ailed | wc -l 14
among which local-fs.target/start, leaving me in emergency mode. I switched Start to 15 and it seems to have booted normally, even though
# journalctl -b | grep ailed | wc -l
returned 12. I switched it to 75, and still got 12. So I switched it back to its original 90, and it still got 12. So I switched back to 5. Next boot produced 15, but all seemed totally normal.
Oh what fun is systemd. :-p
(but no reboot/shutdown delays since playing with system.conf either)
Am Dienstag, 24. Juli 2018 schrieb Felix Miata:
Michele Calgaro composed on 2018-07-20 10:16 (UTC+0800):
Reduce the timeout of exactly what/where? This happens with the openSUSEes and the Debians./etc/systemd/system.comf
Uncomment and change like this: DefaultTimeoutStartSec=5s DefaultTimeoutStopSec=5s This should reduce the wait time to 5 seconds.
Bad idea. This system has no SDD. I did exactly that, and bunches of startup units failed
# journalctl -b -1 | grep ailed | wc -l 14
among which local-fs.target/start, leaving me in emergency mode. I switched Start to 15 and it seems to have booted normally, even though
# journalctl -b | grep ailed | wc -l
returned 12. I switched it to 75, and still got 12. So I switched it back to its original 90, and it still got 12. So I switched back to 5. Next boot produced 15, but all seemed totally normal.
Oh what fun is systemd. :-p
Oh well ... have you seen this? English: https://translate.google.de/translate?sl=de&tl=en&js=y&prev=_t&a... Deutsch: http://www.danisch.de/blog/2018/07/10/systemd-war-eine-massive-fehlentscheid...
Nik
(but no reboot/shutdown delays since playing with system.conf either)
Felix Miata composed on 2018-07-23 22:23 (UTC-0400):
Michele Calgaro composed on 2018-07-20 10:16 (UTC+0800):
Reduce the timeout of exactly what/where? This happens with the openSUSEes and the Debians./etc/systemd/system.comf
Uncomment and change like this: DefaultTimeoutStartSec=5s DefaultTimeoutStopSec=5s This should reduce the wait time to 5 seconds.
Bad idea. This system has no SDD. I did exactly that, and bunches of startup units failed
# journalctl -b -1 | grep ailed | wc -l 14
among which local-fs.target/start, leaving me in emergency mode. I switched Start to 15 and it seems to have booted normally, even though
# journalctl -b | grep ailed | wc -l
returned 12. I switched it to 75, and still got 12. So I switched it back to its original 90, and it still got 12. So I switched back to 5. Next boot produced 15, but all seemed totally normal.
Oh what fun is systemd. :-p
(but no reboot/shutdown delays since playing with system.conf either)
Spoke too soon. It just sat there 90 seconds reporting "watchdog did not stop!" before it rebooted.
Felix Miata wrote:
These I do whilst logged out of the TDM greeter, so it shouldn't be doing anything but waiting. It shouldn't matter what it's waiting for, whether an attempt to log in or a direction to reboot or shutdown.
I had same experience - it just arbitrary decides to wait forever. Most of the time it was waiting for cryptsetup to close encrypted volume or mount to umount nfs share. After some time I switched to sysv init and all troubles are gone. Now systemd is sitting ashamed in the corner waiting to do something and it is good so.
regards
-
deloptes -
Dr. Nikolaus Klepp -
Felix Miata -
Michael -
Michele Calgaro