Re: Kill Process ERROR !!!

On Wed, 9 Jul 2003, Terry Hampton wrote:

> Andrew Sullivan wrote:
> > On Wed, Jul 09, 2003 at 09:52:38AM +0000, aris wendy wrote:
> >
> >>I want to kill process no 582, I use kill -9 582 but all user become
> >>disconnect look at below
> >
> >
> > Try kill -2.
> >
>
> The " kill -2 " is much better advice.
>
> Might I suggest to all - AVOID the " classic " kill -9 !
> Never use it, unless nothing else works. It's curious why
> " kill -9 " is such a part of " common " UNIX practice.
>
> Yes it works, but it's messy and often leads to problems as
> Andrew experienced. The "9" signal is too brute force,
> and should only be used as a LAST resort.
>
> Your first command to kill a process is simple: kill <pid>
>
> Notice - NO signal value. By default UNIX sends a signal 15
> with the kill command. Signal 15 is the default because
> it is the normal termination signal. ( I don't have a manual in
> handy to give you the exact name of the signal ). Signal 15
> should ALWAYS be used first since it tells the process to
> terminate as if the process was terminating on its own. This
> means, the process will more likely clean up after itself,
> regarding file descriptors, child processes, etc.

What amazes me is how many people don't try 'kill pid' first.

> Speaking of child processes, ALWAYS kill any child processe
> first - and more specifically from high to low PID value. Basically,
> the higher the PID value, the newer or younger the child. Why
> kill child processes first ? - UNIX processes are very signal
> driven. The parent of any processes looks for signals from its
> children, and acts accordingly. Processes always have a parent.
> Child processes that are orphaned, are sometimes " adopted " by
> another process - and that is always process 1 Usually,
> this is the story behind " zombies " - those processes you can't
> kill or will go away. Next time you see a <zombie>, notice its
> parent PID is 1.

Please note that this is not necessarily true. If my server has been up a
while and I stop/restart the postmaster, it may have a fairly high id
number and it is quite possible that in x number of days time, the
children will be created with a wrapped pid which is lower than the
postmasters. Just look for the - switches that make it obvious. In fact,
this IS currently the case right now on my server:

13081 ? S 2:30 /usr/local/pgsql/bin/postmaster
13082 ? S 0:19 postgres: stats buffer process
13083 ? S 0:28 postgres: stats collector process
5600 ? S 0:00 postgres: marlowe phone [local] idle

In this case 13081 is my postmaster.

Notice that kill -9 to any postgresql backend results in all backend
connections flushing their buffers. kill -9 to the postmaster results in
a dirty shutdown and the database server has to go through the WAL and
clean things up. It's not the same as hitting the Big Red Switch, but
it's close.