So here’s the thing.
Ubuntu, following Debian, changed to Systemd as an init system in recent releases.
The shutdown sequence under Systemd now function like this:
- When the shutdown is initiated, every running service is sent a SIGTERM signal.
There are many different signals you can send to processes under Linux, and the main two you have to understand for the issue at hand are SIGTERM and SIGKILL.
SIGTERM and SIGKILL usually produce the same results: the process that receive those signals terminates.
The difference between the two is that SIGTERM can be intercepted by the process. Any correctly-implemented process is supposed to use this as a chance to do some cleanup work, and then exit once the cleanup is complete.
- There is a 90s timeout after the wave of SIGTERM is sent. Once it expires, every process still alive is sent a SIGKILL.
The problem we’re experiencing with slow shutdown comes from the fact that some processes aren’t handling the SIGTERM like we would want them to. (or, according to the latest comments on @anon42388993’s link to other bug above, some processes are not receiving the SIGTERM to begin with)
It’s not always the same process that causes the hangup either. See this other thread.
I think a lot of those processes are waiting from some kind of response from the network (like CUPS, Apport and Networkmanager for instance) which is why manually killing the interfaces beforehand makes them die faster.
That behavior was first described here: Bug #1457400
If you read down the comments, it is possible to change that timeout value, and a number of users here have done exactly that without encountering adverse side-effects.
Now we’ve discussed it with one of the systemd maintainers for Ubuntu and we can’t expect the value to be changed because it wouldn’t be right by the SRU guidelines. The maintainer made a good argument too. Database engines sometime take a while to shut down.
So basically I agree with you that it’s a pain, but sadly other than editing that config file there’s not a lot we can do.