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.


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to