Tom Lane wrote:
> However, with an explicit kill level that doesn't happen: you get one
> signal of the specified value, no more. Possibly it would be better for
> the init script to send SIGINT (forcibly disconnect clients) instead of
> SIGTERM, however. So I'm now leaning to "killproc postmaster -INT".
Ok, since I can't seem to count on killproc's exact behavior, istm that
I can:
killproc postmaster -INT
wait some number of seconds
if postmaster still up killproc postmaster -TERM
wait some number of seconds
if postmaster STILL up killproc postmaster #and let the grim reaper do its dirty work.
After all, the system shutdown is relying on this script to properly and
thoroughly shut things down, or it WILL do the 'kill -9
pid-of-postmaster' for you.
Now, what's a good delay here? Or is there a better metric that a
simple delay? After all, I want to avoid the kill -9 unless we have an
emergency hard lock situation -- what's a good indicator of the backend
fleet of processes actually _doing_ something? Or should I key on an
indicator of processor speed (Linux does provide a nice bogus metric
known as BogoMIPS for such a purpose)? The last thing I want to do is
wait too long on some platforms and not long enough on others.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11