Comment # 58 on bug 906900 from Thomas Blume

(In reply to Andrei Borzenkov from comment #57)
> > Unfortunately, it doesn't help, since the processes are killed directly at
> > session logout, not by a timeout (see comment#24).
> 
> a) by default processes are *NOT* killed on session logout. Cf. logind.conf:
> 
> #KillUserProcesses=no
> 
> b) The problem happens on system shutdown which calls Stop for user.scope
> unit. Stop will then kill all processes that are part of scope according to
> KillMode of *scope*. What my patch does, is to allow turning off killing on
> stop.

Hm, the manpage tells for KillMode:

-->--
Processes will first be terminated via SIGTERM (unless the signal to send is
changed via KillSignal=). Optionally, this is immediately followed by a SIGHUP
(if enabled with SendSIGHUP=). If then, after a delay (configured via the
TimeoutStopSec= option), processes still remain, the termination request is
repeated with the SIGKILL signal (unless this is disabled via the SendSIGKILL=
option). See kill(2) for more information.
--<--

I didn't see an initial SIGTERM and after a delay a SIGKILL to the processes. 
I only saw a SIGKILL immediately at session termination.
Is the KillMode behaviour different for scope units?

However, Andrej, I respect your great systemd experience, but I don't think
your approach is the best one.
Using su - in the init script was IMHO done, because it was not possible to run
the init script directly as postgres user.
We now have provided a solution that runs the whole init script as postgres
user. This makes the su - command in the init script redundant and appears to
be the better solution than trying to deal with a session created by su -.
Furthermore why would you want to disable the process cleanup at scope level?
IMHO, this is a quite important feature and shouldn't be disabled.

Still, you might know better than me.
Please explain what is the advantage of your solution versus the one that we
have provided in comment#47 and comment#48.