Traditional Unix shutdown scripts send these signals once, when the entire system is about to be (forcibly) rebooted, and it no longer matters what processes are still running because the kernel is going to stop soon anyway.
Individual init.d-style scripts might send signals to specific processes, but that's usually ad-hoc behavior that makes sense for each daemon (i.e. Apache or Postgres send signals to all their children, while sshd only signals the master process and leaves child sessions alone). While I appreciate that it might be useful to refactor to a single implementation, it makes no sense for that single implementation to do something new and surprising by default.
systemd sends SIGKILL in many new situations, such as when a login session ends, or a service is restarted, or a TCP connection is lost. None of these imply even SIGTERM, let alone SIGKILL, and certainly not for processes that are many generations removed from the initial service process.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds