Re: Kill Process ERROR !!! - Mailing list pgsql-admin
From | scott.marlowe |
---|---|
Subject | Re: Kill Process ERROR !!! |
Date | |
Msg-id | Pine.LNX.4.33.0307090933350.8686-100000@css120.ihs.com Whole thread Raw |
In response to | Re: Kill Process ERROR !!! (Terry Hampton <thampton@limacorp.com>) |
List | pgsql-admin |
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.
pgsql-admin by date: