The short answer "you can't", the description is: after sending a termination signal - it's wise to let the network find another chains, so that's why there's a delay in order, and there's absolutely nothing wrong with it. To reduce the delay - it does not works all the times - you can set via ControlPort "DisableNetwork 1" and give Tor 5-10 seconds, then you'll shut it down. But it does not works faster all the times, so - as my advise - just let it finish itself in a regular way, there's no hurry.
But as a side note - you should script the 2nd interrupt shutdown for emergency shutdown cases, like your UPS battery is almost gone: the faster the shutdown is in that cases - the better, because it will prevent the filesystem corruption. Usual shutdown timings for tor are about 10-15 seconds as for me, so - thats' the strategy I'm proposing for your "fast shutdown case":
- If you're using SystemD - then you have nothing to worry about, as I've switched on it on some of my VMs, it's not a problem at all in case of Debian stretch - VM shuts itself down in 2-5 seconds more time than just a blank one.
- If you're using daemontools and/or init.d scripts - just send a "DisableNetwork 1" a 2-3 seconds before sending the shutdown machine-wide via
shutdown command, that's how it working in my old-style setups I was talking about in original answer. a good workaround here can be the next trick: rename the original shutdown-commands binaries to something like
shutdown.orig, make your own scripts with the original command names - and in that scripts before calling "the orig's" do the telnetting "disablenetwork 1" and sleep for 3 seconds. That's exactly how I'm doing it. So all of your previous machine management scripts will be working as usual, no need to patch every of them - just put scripts at the exact place of the old binaries.