I think that depends on the setting, I had situations where one of my docker containers took ages to shutdown and it would just say 00/02 00s but when it reached that limit, it would just go up.
Thanks, I usually know what it is tho. Most often it’s VMs I was using for testing stuff, which I forgot to shutdown. It takes a while for them to cleanly shutdown, which is what the wait is for. I have a shortcut on my desktop to a script that checks for any running VMs still and shuts them down. But I forget to click it sometimes and then I have to wait. No big deal, except I like to switch off the power bar that powers the computer and everything attached to it. An old habit from when such a thing mattered, these days standby power is probably nothing to worry about. But still I wait patiently for the computer to shut down till I switch off the power strip.
If your script somehow shuts them down faster than plain old SIGTERM, putting it under /usr/lib/systemd/system-shutdown/ might be a good idea. Check man 8 systemd-shutdown for more info on that.
At least it tells you how long it’ll take before it decides to SIGKILL whatever is holding the shutdown sequence.
I think that depends on the setting, I had situations where one of my docker containers took ages to shutdown and it would just say 00/02 00s but when it reached that limit, it would just go up.
Individual services can override the default 90 seconds timeout. But then you can override their override if you think you are smarter, of course.
Well you say that, but I’ve seen the countdown go past and then reset to a higher number often.
I entrust you with this horror, go figure out what to blame.
shutdown-analyze.sh
#! /usr/bin/env bash shutdown_start=$(journalctl -b -1 -u systemd-logind --grep="System is (powering down|rebooting)" --output=cat --no-pager --output-fields=_SOURCE_REALTIME_TIMESTAMP) shutdown_start=$((shutdown_start / 1000000)) units=$(journalctl -b -1 --since=@$shutdown_start --output=cat --no-pager --output-fields=UNIT JOB_TYPE=stop CODE_FUNC=job_emit_start_message) for u in $units; do stopping_start=$(journalctl -b -1 --since=@$shutdown_start -u "$u" --output=cat --no-pager --output-fields=_SOURCE_REALTIME_TIMESTAMP JOB_TYPE=stop CODE_FUNC=job_emit_start_message _SYSTEMD_UNIT=init.scope) stopping_end=$(journalctl -b -1 --since=@$shutdown_start -u "$u" --output=cat --no-pager --output-fields=_SOURCE_REALTIME_TIMESTAMP JOB_TYPE=stop CODE_FUNC=job_emit_done_message _SYSTEMD_UNIT=init.scope) duration_human=$(systemd-analyze timespan $((stopping_end - stopping_start))us | tail -1 | sed 's/.*: //') printf "%s\t%10s %s\n" $((stopping_end - stopping_start)) "$duration_human" "$u" done | sort -rn | cut -f 2Thanks, I usually know what it is tho. Most often it’s VMs I was using for testing stuff, which I forgot to shutdown. It takes a while for them to cleanly shutdown, which is what the wait is for. I have a shortcut on my desktop to a script that checks for any running VMs still and shuts them down. But I forget to click it sometimes and then I have to wait. No big deal, except I like to switch off the power bar that powers the computer and everything attached to it. An old habit from when such a thing mattered, these days standby power is probably nothing to worry about. But still I wait patiently for the computer to shut down till I switch off the power strip.
If your script somehow shuts them down faster than plain old SIGTERM, putting it under
/usr/lib/systemd/system-shutdown/might be a good idea. Checkman 8 systemd-shutdownfor more info on that.Similar to angry parents.