As noted in (forwarded) github issue, this "fix" is totally bogus and
(likely) breaks things.
ExecStop command is expected to kill daemon (in a friendly way), while
(default handler for) kill(SIGSTOP) pauses/freezes/suspends process
execution (and transmission-daemon does not override default SIGSTOP
handler).
If ExecStop is not specified, systemd sends SIGTERM (which is handled by
transmission-daemon, and should do right thing), and then (if process is
still alive) SIGKILL.
If ExecStop is specified, but does not actually finish process (and kill
-STOP does NOT finish transmission-daemon process), systemd waits for
TimeoutStopSec, then sends SIGTERM (but as kill -STOP just suspended
process, it will NOT be handled by transmission-daemon), and then (as
process is still alive) sends SIGKILL.
So, as a result of this patch, transmission-daemon is killed in VERY
unfriendly way (and very *slowly* - after waiting for 2*TimeoutStopSec).
As pointed in github issue, original poster log indicates that
transmission-daemon dies by SIGSEGV, which is NOT signal that was
(possibly) sent by systemd. That is, it is some transmission-daemon bug
that was just triggered during "clean" process termination, and NOT
systemd interaction issue.
Obviously, when daemon is hard-killed, this SIGSEGV is not (immediately)
triggered, but it does not really fix issue, only hides it.
P.S. from first look at sources, transmission-daemon handles termination
signals synchronously, so this is (probably) not
async-signal-unsafe-function-in-signal-handler kind of bug.
