Why are we using kill -9 always

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












-3














I would like to know the kill stages. We always use kill-9 and not any other numbers. Can anyone explain the reason.










share|improve this question



















  • 2




    How can we explain your reasons?
    – Jeff Schaller
    Jul 8 '17 at 15:55






  • 9




    I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
    – jlliagre
    Jul 8 '17 at 16:24










  • kill -9 is numeric shorthand for kill -KILL: use kill to send the SIGKILL signal. On many systems you can use kill -l to list available signals.
    – user4556274
    Jul 8 '17 at 17:22










  • Don't use kill -9. Start with just kill.
    – roaima
    Jul 8 '17 at 17:24






  • 1




    There is a theory that says if a prog can not be killed by kill -15 which is the normal way to terminate normally a prog, then remove this prog since it misbehaves and does not follow the common programming rules and potentially might misbehave in other cases also.
    – George Vasiliou
    Jul 8 '17 at 20:46















-3














I would like to know the kill stages. We always use kill-9 and not any other numbers. Can anyone explain the reason.










share|improve this question



















  • 2




    How can we explain your reasons?
    – Jeff Schaller
    Jul 8 '17 at 15:55






  • 9




    I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
    – jlliagre
    Jul 8 '17 at 16:24










  • kill -9 is numeric shorthand for kill -KILL: use kill to send the SIGKILL signal. On many systems you can use kill -l to list available signals.
    – user4556274
    Jul 8 '17 at 17:22










  • Don't use kill -9. Start with just kill.
    – roaima
    Jul 8 '17 at 17:24






  • 1




    There is a theory that says if a prog can not be killed by kill -15 which is the normal way to terminate normally a prog, then remove this prog since it misbehaves and does not follow the common programming rules and potentially might misbehave in other cases also.
    – George Vasiliou
    Jul 8 '17 at 20:46













-3












-3








-3







I would like to know the kill stages. We always use kill-9 and not any other numbers. Can anyone explain the reason.










share|improve this question















I would like to know the kill stages. We always use kill-9 and not any other numbers. Can anyone explain the reason.







kill signals






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 9 '17 at 23:34









Gilles

529k12810601586




529k12810601586










asked Jul 8 '17 at 15:47









Athiri

3110




3110







  • 2




    How can we explain your reasons?
    – Jeff Schaller
    Jul 8 '17 at 15:55






  • 9




    I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
    – jlliagre
    Jul 8 '17 at 16:24










  • kill -9 is numeric shorthand for kill -KILL: use kill to send the SIGKILL signal. On many systems you can use kill -l to list available signals.
    – user4556274
    Jul 8 '17 at 17:22










  • Don't use kill -9. Start with just kill.
    – roaima
    Jul 8 '17 at 17:24






  • 1




    There is a theory that says if a prog can not be killed by kill -15 which is the normal way to terminate normally a prog, then remove this prog since it misbehaves and does not follow the common programming rules and potentially might misbehave in other cases also.
    – George Vasiliou
    Jul 8 '17 at 20:46












  • 2




    How can we explain your reasons?
    – Jeff Schaller
    Jul 8 '17 at 15:55






  • 9




    I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
    – jlliagre
    Jul 8 '17 at 16:24










  • kill -9 is numeric shorthand for kill -KILL: use kill to send the SIGKILL signal. On many systems you can use kill -l to list available signals.
    – user4556274
    Jul 8 '17 at 17:22










  • Don't use kill -9. Start with just kill.
    – roaima
    Jul 8 '17 at 17:24






  • 1




    There is a theory that says if a prog can not be killed by kill -15 which is the normal way to terminate normally a prog, then remove this prog since it misbehaves and does not follow the common programming rules and potentially might misbehave in other cases also.
    – George Vasiliou
    Jul 8 '17 at 20:46







2




2




How can we explain your reasons?
– Jeff Schaller
Jul 8 '17 at 15:55




How can we explain your reasons?
– Jeff Schaller
Jul 8 '17 at 15:55




9




9




I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
– jlliagre
Jul 8 '17 at 16:24




I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
– jlliagre
Jul 8 '17 at 16:24












kill -9 is numeric shorthand for kill -KILL: use kill to send the SIGKILL signal. On many systems you can use kill -l to list available signals.
– user4556274
Jul 8 '17 at 17:22




kill -9 is numeric shorthand for kill -KILL: use kill to send the SIGKILL signal. On many systems you can use kill -l to list available signals.
– user4556274
Jul 8 '17 at 17:22












Don't use kill -9. Start with just kill.
– roaima
Jul 8 '17 at 17:24




Don't use kill -9. Start with just kill.
– roaima
Jul 8 '17 at 17:24




1




1




There is a theory that says if a prog can not be killed by kill -15 which is the normal way to terminate normally a prog, then remove this prog since it misbehaves and does not follow the common programming rules and potentially might misbehave in other cases also.
– George Vasiliou
Jul 8 '17 at 20:46




There is a theory that says if a prog can not be killed by kill -15 which is the normal way to terminate normally a prog, then remove this prog since it misbehaves and does not follow the common programming rules and potentially might misbehave in other cases also.
– George Vasiliou
Jul 8 '17 at 20:46










4 Answers
4






active

oldest

votes


















10














Actually, I quite like Bob's answer.



The signals I use are:




  • -1 (-HUP) - restart a process


  • -2 (-INT) - terminate a process


  • -9 (-KILL) - let the kernel kick the process out


  • -11 (-SEGV) - have the program crash brutally


  • -15 (-TERM) - the default, ask the program kindly to terminate.

Kill without signal will send -15 (-TERM).



All the above signal names can be specified the SIG prefix (e.g. -SIGKILL), this, however, is optional.



Note, kill -11 will force the program to exit with a segmentation fault, I use it sometimes, when kill -9 won't terminate a process. (You might lose data if you issue kill -9 or kill -11 on a process, so beware!)



You use ps -ef | grep <program> to inspect the process. To get rid of a process (which has parent PID 1), you have to kill -HUP 1 or kill -1 1 (both as root). Note that PID 1 is you init system.



So, to terminate a process, issue kill <pid> (the exact same as kill -15 <pid>), if that fails I try these others (you could lose data!), kill -2 <pid> (akin to doing Ctrl+c), if that fails kill -9 <pid>, if that fails kill -11 <pid>, if that fails the process is most likely a zombie process, ensure that is the case using ps -ef | grep <program_name> or ps -ef | grep <pid>, it should mention "defunct" after the process. This is when you issue kill -1 1.



Hope that helps ;-)



Some programs, such as Java JVM's, can be configured to dump threads/heap (for troubleshooting) when they receive a signal, in these cases I use kill as well ...






share|improve this answer






























    9














    Originally, the kill command/system call just killed a process. This was done by the kernel and the process just disappeared, never being notified about it.
    That stopped around Third Edition, I think.
    kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process and handled in any way. A kinder way to stop a process is kill -15 (or kill -TERM) which tells the process it is being terminated, but gives it a chance to perform cleanup.



    Use of kill -9 is a 'guaranteed' way to kill a process; if it's stuck, kill -15 might not always work. Hence, many people still use kill -9 as a 'first resort'.



    The reason the 'ultimate' kill signal is number 9 is just the way they did it. There were at least another eight different signals at that time, and I guess the numbers were assigned by the person who programmed that part of the kernel (probably Ken Thompson). Some of the lower numbers are now largely historical, as they map onto hardware instructions and/or events in the PDP-11 hardware. And there are also many others above 9.



    Note that the actual numbers have no levels or hierarchy in them; in no sense is signal 8 'less' than signal 9 or 'greater' than signal 7.






    share|improve this answer






















    • Why are we not using 1 or 2 or 3 etc.. we just using 9 always. Is there a stages in between?
      – Athiri
      Jul 8 '17 at 16:06






    • 5




      @Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
      – Fox
      Jul 8 '17 at 16:14










    • I've added an expanded explanation of signal numbers.
      – Bob Eager
      Jul 8 '17 at 16:19










    • Of course the process is notified: if it wants to, it can set up a signal handler and catch the signal. If it wants not to die, it can do so. It's only by default that most signals kill the process. But SIGKILL (9) cannot be caught or ignored, which is why people think that kill -9 is necessary: it is not - it depends on what you want to do (and BTW, if the process is sleeping uninterruptibly in the kernel, it cannot be killed: it will only disappear after a reboot). Also all of the "hardware" signals can be generated on modern hardware: which ones do you think are obsolete?
      – NickD
      Jul 8 '17 at 17:10










    • That's what I said: kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process. I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
      – Bob Eager
      Jul 8 '17 at 17:15



















    4














    Well... everyone's programming style is different, I suppose. Personally, I try to avoid sending a kill -9 if I can because it tends to create zombie processes, as it does not allow the process it kills to execute any clean up actions that may or may not exist in the program the user wants to kill.



    It is the 'last resort' signal, so while it's seldom the preferred way to terminate a program, it is commonly used, (particular in poorly written programs) because it "always works", so to speak...



    If a process is ignoring SIGINT or SIGTERM, than there should be a reason for that-- perhaps the process is supposed to release a lock file, delete some temporary file(s), and/or perform some other 'clean up' actions before termination. Of course, programs do misbehave, and thus we do need SIGKILL for those (hopefully rare) scenarios.



    The only truly appropriate uses of SIGKILL are when a process is misbehaving for some reason and thus will not properly terminate, or when the user needs to kill the process immediately for some other reason (for example, if you accidentally execute a trojan and than freak out, you may want to make sure that you kill the program quickly, and entirely).



    The reason why you may see it often is because it is the only signal the kernel cannot ignore. In the shell you can play around with the trap command to see for yourself, but this a very good explanation of what kill -9 does:




    Signal 9 From Outer Space



    There is one signal that you cannot trap: SIGKILL or signal 9. The
    kernel immediately terminates any process sent this signal and no
    signal handling is performed. Since it will always terminate a program
    that is stuck, hung, or otherwise screwed up, it is tempting to think
    that it's the easy way out when you have to get something to stop and
    go away. Often you will see references to the following command which
    sends the SIGKILL signal: kill -9



    However, despite its apparent ease, you must remember that when you
    send this signal, no processing is done by the application. Often this
    is OK, but with many programs it's not. In particular, many complex
    programs (and some not-so-complex) create lock files to prevent
    multiple copies of the program from running at the same time. When a
    program that uses a lock file is sent a SIGKILL, it doesn't get the
    chance to remove the lock file when it terminates. The presence of the
    lock file will prevent the program from restarting until the lock file
    is manually removed.



    Be warned. Use SIGKILL as a last resort.




    Source






    share|improve this answer






















    • fuser -ck and kill -9 are does the same process?.
      – Athiri
      Aug 14 '17 at 15:20


















    0














    I love this thread as it echoes back to the days I used to help my Dad on-site (during the early 80s) working on old Burroughs/Unisys systems... all the way to the present where kill has slightly evolved (for various reasons).



    First, credit to @thecarpy and Bob for their responses.



    Secondly, kill can take on different meanings based on the Unix/Unix-like system (or shell) implementation. Originally, kill was a direct system call to module-based/monolithic-based kernels to allow a user to delete an active process from memory. The point is, this command was a means for the kernel space (ring0), ring3 (user space), or higher-level users to destroy greedy/run-away processes from absorbing resources on old, main/mid-frame systems.



    Third, the whole purpose of kill is to ensure a PID has a handle for SIGKILL to be sent -- per process/per terminal/per run-level.



    With Unix-like systems, kill -9 is used too frequently, IMHO, as it has been stated it can leave zombie processes. This is due to the Parent->Child Process PID relationships based on forking, pipe-lining, and other reasons where the initial PID/Process spawns children, etc.



    The command is quite useful as it is dangerous, but knowing the options (as mentioned above) and the PID in question (from a shell script to a core DB process) should be investigated first:



    ps -aef | grep -i



    Once identified, kill -15 was what I used to prevent zombies and run-away processes, such as in the early days of MySQL, to conserve system resources, however knowing the right SIGnal to send a process is important, too: https://en.wikipedia.org/wiki/Kill_(command)



    When in doubt, try to use the pkill command for named-processes, such as mariadb/httpd or kill -15 to immediately nuke a process.






    share|improve this answer




















      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "106"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f377191%2fwhy-are-we-using-kill-9-always%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      10














      Actually, I quite like Bob's answer.



      The signals I use are:




      • -1 (-HUP) - restart a process


      • -2 (-INT) - terminate a process


      • -9 (-KILL) - let the kernel kick the process out


      • -11 (-SEGV) - have the program crash brutally


      • -15 (-TERM) - the default, ask the program kindly to terminate.

      Kill without signal will send -15 (-TERM).



      All the above signal names can be specified the SIG prefix (e.g. -SIGKILL), this, however, is optional.



      Note, kill -11 will force the program to exit with a segmentation fault, I use it sometimes, when kill -9 won't terminate a process. (You might lose data if you issue kill -9 or kill -11 on a process, so beware!)



      You use ps -ef | grep <program> to inspect the process. To get rid of a process (which has parent PID 1), you have to kill -HUP 1 or kill -1 1 (both as root). Note that PID 1 is you init system.



      So, to terminate a process, issue kill <pid> (the exact same as kill -15 <pid>), if that fails I try these others (you could lose data!), kill -2 <pid> (akin to doing Ctrl+c), if that fails kill -9 <pid>, if that fails kill -11 <pid>, if that fails the process is most likely a zombie process, ensure that is the case using ps -ef | grep <program_name> or ps -ef | grep <pid>, it should mention "defunct" after the process. This is when you issue kill -1 1.



      Hope that helps ;-)



      Some programs, such as Java JVM's, can be configured to dump threads/heap (for troubleshooting) when they receive a signal, in these cases I use kill as well ...






      share|improve this answer



























        10














        Actually, I quite like Bob's answer.



        The signals I use are:




        • -1 (-HUP) - restart a process


        • -2 (-INT) - terminate a process


        • -9 (-KILL) - let the kernel kick the process out


        • -11 (-SEGV) - have the program crash brutally


        • -15 (-TERM) - the default, ask the program kindly to terminate.

        Kill without signal will send -15 (-TERM).



        All the above signal names can be specified the SIG prefix (e.g. -SIGKILL), this, however, is optional.



        Note, kill -11 will force the program to exit with a segmentation fault, I use it sometimes, when kill -9 won't terminate a process. (You might lose data if you issue kill -9 or kill -11 on a process, so beware!)



        You use ps -ef | grep <program> to inspect the process. To get rid of a process (which has parent PID 1), you have to kill -HUP 1 or kill -1 1 (both as root). Note that PID 1 is you init system.



        So, to terminate a process, issue kill <pid> (the exact same as kill -15 <pid>), if that fails I try these others (you could lose data!), kill -2 <pid> (akin to doing Ctrl+c), if that fails kill -9 <pid>, if that fails kill -11 <pid>, if that fails the process is most likely a zombie process, ensure that is the case using ps -ef | grep <program_name> or ps -ef | grep <pid>, it should mention "defunct" after the process. This is when you issue kill -1 1.



        Hope that helps ;-)



        Some programs, such as Java JVM's, can be configured to dump threads/heap (for troubleshooting) when they receive a signal, in these cases I use kill as well ...






        share|improve this answer

























          10












          10








          10






          Actually, I quite like Bob's answer.



          The signals I use are:




          • -1 (-HUP) - restart a process


          • -2 (-INT) - terminate a process


          • -9 (-KILL) - let the kernel kick the process out


          • -11 (-SEGV) - have the program crash brutally


          • -15 (-TERM) - the default, ask the program kindly to terminate.

          Kill without signal will send -15 (-TERM).



          All the above signal names can be specified the SIG prefix (e.g. -SIGKILL), this, however, is optional.



          Note, kill -11 will force the program to exit with a segmentation fault, I use it sometimes, when kill -9 won't terminate a process. (You might lose data if you issue kill -9 or kill -11 on a process, so beware!)



          You use ps -ef | grep <program> to inspect the process. To get rid of a process (which has parent PID 1), you have to kill -HUP 1 or kill -1 1 (both as root). Note that PID 1 is you init system.



          So, to terminate a process, issue kill <pid> (the exact same as kill -15 <pid>), if that fails I try these others (you could lose data!), kill -2 <pid> (akin to doing Ctrl+c), if that fails kill -9 <pid>, if that fails kill -11 <pid>, if that fails the process is most likely a zombie process, ensure that is the case using ps -ef | grep <program_name> or ps -ef | grep <pid>, it should mention "defunct" after the process. This is when you issue kill -1 1.



          Hope that helps ;-)



          Some programs, such as Java JVM's, can be configured to dump threads/heap (for troubleshooting) when they receive a signal, in these cases I use kill as well ...






          share|improve this answer














          Actually, I quite like Bob's answer.



          The signals I use are:




          • -1 (-HUP) - restart a process


          • -2 (-INT) - terminate a process


          • -9 (-KILL) - let the kernel kick the process out


          • -11 (-SEGV) - have the program crash brutally


          • -15 (-TERM) - the default, ask the program kindly to terminate.

          Kill without signal will send -15 (-TERM).



          All the above signal names can be specified the SIG prefix (e.g. -SIGKILL), this, however, is optional.



          Note, kill -11 will force the program to exit with a segmentation fault, I use it sometimes, when kill -9 won't terminate a process. (You might lose data if you issue kill -9 or kill -11 on a process, so beware!)



          You use ps -ef | grep <program> to inspect the process. To get rid of a process (which has parent PID 1), you have to kill -HUP 1 or kill -1 1 (both as root). Note that PID 1 is you init system.



          So, to terminate a process, issue kill <pid> (the exact same as kill -15 <pid>), if that fails I try these others (you could lose data!), kill -2 <pid> (akin to doing Ctrl+c), if that fails kill -9 <pid>, if that fails kill -11 <pid>, if that fails the process is most likely a zombie process, ensure that is the case using ps -ef | grep <program_name> or ps -ef | grep <pid>, it should mention "defunct" after the process. This is when you issue kill -1 1.



          Hope that helps ;-)



          Some programs, such as Java JVM's, can be configured to dump threads/heap (for troubleshooting) when they receive a signal, in these cases I use kill as well ...







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jul 27 '17 at 9:45

























          answered Jul 8 '17 at 17:24









          thecarpy

          2,275825




          2,275825























              9














              Originally, the kill command/system call just killed a process. This was done by the kernel and the process just disappeared, never being notified about it.
              That stopped around Third Edition, I think.
              kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process and handled in any way. A kinder way to stop a process is kill -15 (or kill -TERM) which tells the process it is being terminated, but gives it a chance to perform cleanup.



              Use of kill -9 is a 'guaranteed' way to kill a process; if it's stuck, kill -15 might not always work. Hence, many people still use kill -9 as a 'first resort'.



              The reason the 'ultimate' kill signal is number 9 is just the way they did it. There were at least another eight different signals at that time, and I guess the numbers were assigned by the person who programmed that part of the kernel (probably Ken Thompson). Some of the lower numbers are now largely historical, as they map onto hardware instructions and/or events in the PDP-11 hardware. And there are also many others above 9.



              Note that the actual numbers have no levels or hierarchy in them; in no sense is signal 8 'less' than signal 9 or 'greater' than signal 7.






              share|improve this answer






















              • Why are we not using 1 or 2 or 3 etc.. we just using 9 always. Is there a stages in between?
                – Athiri
                Jul 8 '17 at 16:06






              • 5




                @Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
                – Fox
                Jul 8 '17 at 16:14










              • I've added an expanded explanation of signal numbers.
                – Bob Eager
                Jul 8 '17 at 16:19










              • Of course the process is notified: if it wants to, it can set up a signal handler and catch the signal. If it wants not to die, it can do so. It's only by default that most signals kill the process. But SIGKILL (9) cannot be caught or ignored, which is why people think that kill -9 is necessary: it is not - it depends on what you want to do (and BTW, if the process is sleeping uninterruptibly in the kernel, it cannot be killed: it will only disappear after a reboot). Also all of the "hardware" signals can be generated on modern hardware: which ones do you think are obsolete?
                – NickD
                Jul 8 '17 at 17:10










              • That's what I said: kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process. I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
                – Bob Eager
                Jul 8 '17 at 17:15
















              9














              Originally, the kill command/system call just killed a process. This was done by the kernel and the process just disappeared, never being notified about it.
              That stopped around Third Edition, I think.
              kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process and handled in any way. A kinder way to stop a process is kill -15 (or kill -TERM) which tells the process it is being terminated, but gives it a chance to perform cleanup.



              Use of kill -9 is a 'guaranteed' way to kill a process; if it's stuck, kill -15 might not always work. Hence, many people still use kill -9 as a 'first resort'.



              The reason the 'ultimate' kill signal is number 9 is just the way they did it. There were at least another eight different signals at that time, and I guess the numbers were assigned by the person who programmed that part of the kernel (probably Ken Thompson). Some of the lower numbers are now largely historical, as they map onto hardware instructions and/or events in the PDP-11 hardware. And there are also many others above 9.



              Note that the actual numbers have no levels or hierarchy in them; in no sense is signal 8 'less' than signal 9 or 'greater' than signal 7.






              share|improve this answer






















              • Why are we not using 1 or 2 or 3 etc.. we just using 9 always. Is there a stages in between?
                – Athiri
                Jul 8 '17 at 16:06






              • 5




                @Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
                – Fox
                Jul 8 '17 at 16:14










              • I've added an expanded explanation of signal numbers.
                – Bob Eager
                Jul 8 '17 at 16:19










              • Of course the process is notified: if it wants to, it can set up a signal handler and catch the signal. If it wants not to die, it can do so. It's only by default that most signals kill the process. But SIGKILL (9) cannot be caught or ignored, which is why people think that kill -9 is necessary: it is not - it depends on what you want to do (and BTW, if the process is sleeping uninterruptibly in the kernel, it cannot be killed: it will only disappear after a reboot). Also all of the "hardware" signals can be generated on modern hardware: which ones do you think are obsolete?
                – NickD
                Jul 8 '17 at 17:10










              • That's what I said: kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process. I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
                – Bob Eager
                Jul 8 '17 at 17:15














              9












              9








              9






              Originally, the kill command/system call just killed a process. This was done by the kernel and the process just disappeared, never being notified about it.
              That stopped around Third Edition, I think.
              kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process and handled in any way. A kinder way to stop a process is kill -15 (or kill -TERM) which tells the process it is being terminated, but gives it a chance to perform cleanup.



              Use of kill -9 is a 'guaranteed' way to kill a process; if it's stuck, kill -15 might not always work. Hence, many people still use kill -9 as a 'first resort'.



              The reason the 'ultimate' kill signal is number 9 is just the way they did it. There were at least another eight different signals at that time, and I guess the numbers were assigned by the person who programmed that part of the kernel (probably Ken Thompson). Some of the lower numbers are now largely historical, as they map onto hardware instructions and/or events in the PDP-11 hardware. And there are also many others above 9.



              Note that the actual numbers have no levels or hierarchy in them; in no sense is signal 8 'less' than signal 9 or 'greater' than signal 7.






              share|improve this answer














              Originally, the kill command/system call just killed a process. This was done by the kernel and the process just disappeared, never being notified about it.
              That stopped around Third Edition, I think.
              kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process and handled in any way. A kinder way to stop a process is kill -15 (or kill -TERM) which tells the process it is being terminated, but gives it a chance to perform cleanup.



              Use of kill -9 is a 'guaranteed' way to kill a process; if it's stuck, kill -15 might not always work. Hence, many people still use kill -9 as a 'first resort'.



              The reason the 'ultimate' kill signal is number 9 is just the way they did it. There were at least another eight different signals at that time, and I guess the numbers were assigned by the person who programmed that part of the kernel (probably Ken Thompson). Some of the lower numbers are now largely historical, as they map onto hardware instructions and/or events in the PDP-11 hardware. And there are also many others above 9.



              Note that the actual numbers have no levels or hierarchy in them; in no sense is signal 8 'less' than signal 9 or 'greater' than signal 7.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Jul 8 '17 at 16:18

























              answered Jul 8 '17 at 15:58









              Bob Eager

              1,8861421




              1,8861421











              • Why are we not using 1 or 2 or 3 etc.. we just using 9 always. Is there a stages in between?
                – Athiri
                Jul 8 '17 at 16:06






              • 5




                @Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
                – Fox
                Jul 8 '17 at 16:14










              • I've added an expanded explanation of signal numbers.
                – Bob Eager
                Jul 8 '17 at 16:19










              • Of course the process is notified: if it wants to, it can set up a signal handler and catch the signal. If it wants not to die, it can do so. It's only by default that most signals kill the process. But SIGKILL (9) cannot be caught or ignored, which is why people think that kill -9 is necessary: it is not - it depends on what you want to do (and BTW, if the process is sleeping uninterruptibly in the kernel, it cannot be killed: it will only disappear after a reboot). Also all of the "hardware" signals can be generated on modern hardware: which ones do you think are obsolete?
                – NickD
                Jul 8 '17 at 17:10










              • That's what I said: kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process. I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
                – Bob Eager
                Jul 8 '17 at 17:15

















              • Why are we not using 1 or 2 or 3 etc.. we just using 9 always. Is there a stages in between?
                – Athiri
                Jul 8 '17 at 16:06






              • 5




                @Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
                – Fox
                Jul 8 '17 at 16:14










              • I've added an expanded explanation of signal numbers.
                – Bob Eager
                Jul 8 '17 at 16:19










              • Of course the process is notified: if it wants to, it can set up a signal handler and catch the signal. If it wants not to die, it can do so. It's only by default that most signals kill the process. But SIGKILL (9) cannot be caught or ignored, which is why people think that kill -9 is necessary: it is not - it depends on what you want to do (and BTW, if the process is sleeping uninterruptibly in the kernel, it cannot be killed: it will only disappear after a reboot). Also all of the "hardware" signals can be generated on modern hardware: which ones do you think are obsolete?
                – NickD
                Jul 8 '17 at 17:10










              • That's what I said: kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process. I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
                – Bob Eager
                Jul 8 '17 at 17:15
















              Why are we not using 1 or 2 or 3 etc.. we just using 9 always. Is there a stages in between?
              – Athiri
              Jul 8 '17 at 16:06




              Why are we not using 1 or 2 or 3 etc.. we just using 9 always. Is there a stages in between?
              – Athiri
              Jul 8 '17 at 16:06




              5




              5




              @Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
              – Fox
              Jul 8 '17 at 16:14




              @Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
              – Fox
              Jul 8 '17 at 16:14












              I've added an expanded explanation of signal numbers.
              – Bob Eager
              Jul 8 '17 at 16:19




              I've added an expanded explanation of signal numbers.
              – Bob Eager
              Jul 8 '17 at 16:19












              Of course the process is notified: if it wants to, it can set up a signal handler and catch the signal. If it wants not to die, it can do so. It's only by default that most signals kill the process. But SIGKILL (9) cannot be caught or ignored, which is why people think that kill -9 is necessary: it is not - it depends on what you want to do (and BTW, if the process is sleeping uninterruptibly in the kernel, it cannot be killed: it will only disappear after a reboot). Also all of the "hardware" signals can be generated on modern hardware: which ones do you think are obsolete?
              – NickD
              Jul 8 '17 at 17:10




              Of course the process is notified: if it wants to, it can set up a signal handler and catch the signal. If it wants not to die, it can do so. It's only by default that most signals kill the process. But SIGKILL (9) cannot be caught or ignored, which is why people think that kill -9 is necessary: it is not - it depends on what you want to do (and BTW, if the process is sleeping uninterruptibly in the kernel, it cannot be killed: it will only disappear after a reboot). Also all of the "hardware" signals can be generated on modern hardware: which ones do you think are obsolete?
              – NickD
              Jul 8 '17 at 17:10












              That's what I said: kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process. I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
              – Bob Eager
              Jul 8 '17 at 17:15





              That's what I said: kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process. I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
              – Bob Eager
              Jul 8 '17 at 17:15












              4














              Well... everyone's programming style is different, I suppose. Personally, I try to avoid sending a kill -9 if I can because it tends to create zombie processes, as it does not allow the process it kills to execute any clean up actions that may or may not exist in the program the user wants to kill.



              It is the 'last resort' signal, so while it's seldom the preferred way to terminate a program, it is commonly used, (particular in poorly written programs) because it "always works", so to speak...



              If a process is ignoring SIGINT or SIGTERM, than there should be a reason for that-- perhaps the process is supposed to release a lock file, delete some temporary file(s), and/or perform some other 'clean up' actions before termination. Of course, programs do misbehave, and thus we do need SIGKILL for those (hopefully rare) scenarios.



              The only truly appropriate uses of SIGKILL are when a process is misbehaving for some reason and thus will not properly terminate, or when the user needs to kill the process immediately for some other reason (for example, if you accidentally execute a trojan and than freak out, you may want to make sure that you kill the program quickly, and entirely).



              The reason why you may see it often is because it is the only signal the kernel cannot ignore. In the shell you can play around with the trap command to see for yourself, but this a very good explanation of what kill -9 does:




              Signal 9 From Outer Space



              There is one signal that you cannot trap: SIGKILL or signal 9. The
              kernel immediately terminates any process sent this signal and no
              signal handling is performed. Since it will always terminate a program
              that is stuck, hung, or otherwise screwed up, it is tempting to think
              that it's the easy way out when you have to get something to stop and
              go away. Often you will see references to the following command which
              sends the SIGKILL signal: kill -9



              However, despite its apparent ease, you must remember that when you
              send this signal, no processing is done by the application. Often this
              is OK, but with many programs it's not. In particular, many complex
              programs (and some not-so-complex) create lock files to prevent
              multiple copies of the program from running at the same time. When a
              program that uses a lock file is sent a SIGKILL, it doesn't get the
              chance to remove the lock file when it terminates. The presence of the
              lock file will prevent the program from restarting until the lock file
              is manually removed.



              Be warned. Use SIGKILL as a last resort.




              Source






              share|improve this answer






















              • fuser -ck and kill -9 are does the same process?.
                – Athiri
                Aug 14 '17 at 15:20















              4














              Well... everyone's programming style is different, I suppose. Personally, I try to avoid sending a kill -9 if I can because it tends to create zombie processes, as it does not allow the process it kills to execute any clean up actions that may or may not exist in the program the user wants to kill.



              It is the 'last resort' signal, so while it's seldom the preferred way to terminate a program, it is commonly used, (particular in poorly written programs) because it "always works", so to speak...



              If a process is ignoring SIGINT or SIGTERM, than there should be a reason for that-- perhaps the process is supposed to release a lock file, delete some temporary file(s), and/or perform some other 'clean up' actions before termination. Of course, programs do misbehave, and thus we do need SIGKILL for those (hopefully rare) scenarios.



              The only truly appropriate uses of SIGKILL are when a process is misbehaving for some reason and thus will not properly terminate, or when the user needs to kill the process immediately for some other reason (for example, if you accidentally execute a trojan and than freak out, you may want to make sure that you kill the program quickly, and entirely).



              The reason why you may see it often is because it is the only signal the kernel cannot ignore. In the shell you can play around with the trap command to see for yourself, but this a very good explanation of what kill -9 does:




              Signal 9 From Outer Space



              There is one signal that you cannot trap: SIGKILL or signal 9. The
              kernel immediately terminates any process sent this signal and no
              signal handling is performed. Since it will always terminate a program
              that is stuck, hung, or otherwise screwed up, it is tempting to think
              that it's the easy way out when you have to get something to stop and
              go away. Often you will see references to the following command which
              sends the SIGKILL signal: kill -9



              However, despite its apparent ease, you must remember that when you
              send this signal, no processing is done by the application. Often this
              is OK, but with many programs it's not. In particular, many complex
              programs (and some not-so-complex) create lock files to prevent
              multiple copies of the program from running at the same time. When a
              program that uses a lock file is sent a SIGKILL, it doesn't get the
              chance to remove the lock file when it terminates. The presence of the
              lock file will prevent the program from restarting until the lock file
              is manually removed.



              Be warned. Use SIGKILL as a last resort.




              Source






              share|improve this answer






















              • fuser -ck and kill -9 are does the same process?.
                – Athiri
                Aug 14 '17 at 15:20













              4












              4








              4






              Well... everyone's programming style is different, I suppose. Personally, I try to avoid sending a kill -9 if I can because it tends to create zombie processes, as it does not allow the process it kills to execute any clean up actions that may or may not exist in the program the user wants to kill.



              It is the 'last resort' signal, so while it's seldom the preferred way to terminate a program, it is commonly used, (particular in poorly written programs) because it "always works", so to speak...



              If a process is ignoring SIGINT or SIGTERM, than there should be a reason for that-- perhaps the process is supposed to release a lock file, delete some temporary file(s), and/or perform some other 'clean up' actions before termination. Of course, programs do misbehave, and thus we do need SIGKILL for those (hopefully rare) scenarios.



              The only truly appropriate uses of SIGKILL are when a process is misbehaving for some reason and thus will not properly terminate, or when the user needs to kill the process immediately for some other reason (for example, if you accidentally execute a trojan and than freak out, you may want to make sure that you kill the program quickly, and entirely).



              The reason why you may see it often is because it is the only signal the kernel cannot ignore. In the shell you can play around with the trap command to see for yourself, but this a very good explanation of what kill -9 does:




              Signal 9 From Outer Space



              There is one signal that you cannot trap: SIGKILL or signal 9. The
              kernel immediately terminates any process sent this signal and no
              signal handling is performed. Since it will always terminate a program
              that is stuck, hung, or otherwise screwed up, it is tempting to think
              that it's the easy way out when you have to get something to stop and
              go away. Often you will see references to the following command which
              sends the SIGKILL signal: kill -9



              However, despite its apparent ease, you must remember that when you
              send this signal, no processing is done by the application. Often this
              is OK, but with many programs it's not. In particular, many complex
              programs (and some not-so-complex) create lock files to prevent
              multiple copies of the program from running at the same time. When a
              program that uses a lock file is sent a SIGKILL, it doesn't get the
              chance to remove the lock file when it terminates. The presence of the
              lock file will prevent the program from restarting until the lock file
              is manually removed.



              Be warned. Use SIGKILL as a last resort.




              Source






              share|improve this answer














              Well... everyone's programming style is different, I suppose. Personally, I try to avoid sending a kill -9 if I can because it tends to create zombie processes, as it does not allow the process it kills to execute any clean up actions that may or may not exist in the program the user wants to kill.



              It is the 'last resort' signal, so while it's seldom the preferred way to terminate a program, it is commonly used, (particular in poorly written programs) because it "always works", so to speak...



              If a process is ignoring SIGINT or SIGTERM, than there should be a reason for that-- perhaps the process is supposed to release a lock file, delete some temporary file(s), and/or perform some other 'clean up' actions before termination. Of course, programs do misbehave, and thus we do need SIGKILL for those (hopefully rare) scenarios.



              The only truly appropriate uses of SIGKILL are when a process is misbehaving for some reason and thus will not properly terminate, or when the user needs to kill the process immediately for some other reason (for example, if you accidentally execute a trojan and than freak out, you may want to make sure that you kill the program quickly, and entirely).



              The reason why you may see it often is because it is the only signal the kernel cannot ignore. In the shell you can play around with the trap command to see for yourself, but this a very good explanation of what kill -9 does:




              Signal 9 From Outer Space



              There is one signal that you cannot trap: SIGKILL or signal 9. The
              kernel immediately terminates any process sent this signal and no
              signal handling is performed. Since it will always terminate a program
              that is stuck, hung, or otherwise screwed up, it is tempting to think
              that it's the easy way out when you have to get something to stop and
              go away. Often you will see references to the following command which
              sends the SIGKILL signal: kill -9



              However, despite its apparent ease, you must remember that when you
              send this signal, no processing is done by the application. Often this
              is OK, but with many programs it's not. In particular, many complex
              programs (and some not-so-complex) create lock files to prevent
              multiple copies of the program from running at the same time. When a
              program that uses a lock file is sent a SIGKILL, it doesn't get the
              chance to remove the lock file when it terminates. The presence of the
              lock file will prevent the program from restarting until the lock file
              is manually removed.



              Be warned. Use SIGKILL as a last resort.




              Source







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Jul 8 '17 at 22:31

























              answered Jul 8 '17 at 22:10









              Chev_603

              23128




              23128











              • fuser -ck and kill -9 are does the same process?.
                – Athiri
                Aug 14 '17 at 15:20
















              • fuser -ck and kill -9 are does the same process?.
                – Athiri
                Aug 14 '17 at 15:20















              fuser -ck and kill -9 are does the same process?.
              – Athiri
              Aug 14 '17 at 15:20




              fuser -ck and kill -9 are does the same process?.
              – Athiri
              Aug 14 '17 at 15:20











              0














              I love this thread as it echoes back to the days I used to help my Dad on-site (during the early 80s) working on old Burroughs/Unisys systems... all the way to the present where kill has slightly evolved (for various reasons).



              First, credit to @thecarpy and Bob for their responses.



              Secondly, kill can take on different meanings based on the Unix/Unix-like system (or shell) implementation. Originally, kill was a direct system call to module-based/monolithic-based kernels to allow a user to delete an active process from memory. The point is, this command was a means for the kernel space (ring0), ring3 (user space), or higher-level users to destroy greedy/run-away processes from absorbing resources on old, main/mid-frame systems.



              Third, the whole purpose of kill is to ensure a PID has a handle for SIGKILL to be sent -- per process/per terminal/per run-level.



              With Unix-like systems, kill -9 is used too frequently, IMHO, as it has been stated it can leave zombie processes. This is due to the Parent->Child Process PID relationships based on forking, pipe-lining, and other reasons where the initial PID/Process spawns children, etc.



              The command is quite useful as it is dangerous, but knowing the options (as mentioned above) and the PID in question (from a shell script to a core DB process) should be investigated first:



              ps -aef | grep -i



              Once identified, kill -15 was what I used to prevent zombies and run-away processes, such as in the early days of MySQL, to conserve system resources, however knowing the right SIGnal to send a process is important, too: https://en.wikipedia.org/wiki/Kill_(command)



              When in doubt, try to use the pkill command for named-processes, such as mariadb/httpd or kill -15 to immediately nuke a process.






              share|improve this answer

























                0














                I love this thread as it echoes back to the days I used to help my Dad on-site (during the early 80s) working on old Burroughs/Unisys systems... all the way to the present where kill has slightly evolved (for various reasons).



                First, credit to @thecarpy and Bob for their responses.



                Secondly, kill can take on different meanings based on the Unix/Unix-like system (or shell) implementation. Originally, kill was a direct system call to module-based/monolithic-based kernels to allow a user to delete an active process from memory. The point is, this command was a means for the kernel space (ring0), ring3 (user space), or higher-level users to destroy greedy/run-away processes from absorbing resources on old, main/mid-frame systems.



                Third, the whole purpose of kill is to ensure a PID has a handle for SIGKILL to be sent -- per process/per terminal/per run-level.



                With Unix-like systems, kill -9 is used too frequently, IMHO, as it has been stated it can leave zombie processes. This is due to the Parent->Child Process PID relationships based on forking, pipe-lining, and other reasons where the initial PID/Process spawns children, etc.



                The command is quite useful as it is dangerous, but knowing the options (as mentioned above) and the PID in question (from a shell script to a core DB process) should be investigated first:



                ps -aef | grep -i



                Once identified, kill -15 was what I used to prevent zombies and run-away processes, such as in the early days of MySQL, to conserve system resources, however knowing the right SIGnal to send a process is important, too: https://en.wikipedia.org/wiki/Kill_(command)



                When in doubt, try to use the pkill command for named-processes, such as mariadb/httpd or kill -15 to immediately nuke a process.






                share|improve this answer























                  0












                  0








                  0






                  I love this thread as it echoes back to the days I used to help my Dad on-site (during the early 80s) working on old Burroughs/Unisys systems... all the way to the present where kill has slightly evolved (for various reasons).



                  First, credit to @thecarpy and Bob for their responses.



                  Secondly, kill can take on different meanings based on the Unix/Unix-like system (or shell) implementation. Originally, kill was a direct system call to module-based/monolithic-based kernels to allow a user to delete an active process from memory. The point is, this command was a means for the kernel space (ring0), ring3 (user space), or higher-level users to destroy greedy/run-away processes from absorbing resources on old, main/mid-frame systems.



                  Third, the whole purpose of kill is to ensure a PID has a handle for SIGKILL to be sent -- per process/per terminal/per run-level.



                  With Unix-like systems, kill -9 is used too frequently, IMHO, as it has been stated it can leave zombie processes. This is due to the Parent->Child Process PID relationships based on forking, pipe-lining, and other reasons where the initial PID/Process spawns children, etc.



                  The command is quite useful as it is dangerous, but knowing the options (as mentioned above) and the PID in question (from a shell script to a core DB process) should be investigated first:



                  ps -aef | grep -i



                  Once identified, kill -15 was what I used to prevent zombies and run-away processes, such as in the early days of MySQL, to conserve system resources, however knowing the right SIGnal to send a process is important, too: https://en.wikipedia.org/wiki/Kill_(command)



                  When in doubt, try to use the pkill command for named-processes, such as mariadb/httpd or kill -15 to immediately nuke a process.






                  share|improve this answer












                  I love this thread as it echoes back to the days I used to help my Dad on-site (during the early 80s) working on old Burroughs/Unisys systems... all the way to the present where kill has slightly evolved (for various reasons).



                  First, credit to @thecarpy and Bob for their responses.



                  Secondly, kill can take on different meanings based on the Unix/Unix-like system (or shell) implementation. Originally, kill was a direct system call to module-based/monolithic-based kernels to allow a user to delete an active process from memory. The point is, this command was a means for the kernel space (ring0), ring3 (user space), or higher-level users to destroy greedy/run-away processes from absorbing resources on old, main/mid-frame systems.



                  Third, the whole purpose of kill is to ensure a PID has a handle for SIGKILL to be sent -- per process/per terminal/per run-level.



                  With Unix-like systems, kill -9 is used too frequently, IMHO, as it has been stated it can leave zombie processes. This is due to the Parent->Child Process PID relationships based on forking, pipe-lining, and other reasons where the initial PID/Process spawns children, etc.



                  The command is quite useful as it is dangerous, but knowing the options (as mentioned above) and the PID in question (from a shell script to a core DB process) should be investigated first:



                  ps -aef | grep -i



                  Once identified, kill -15 was what I used to prevent zombies and run-away processes, such as in the early days of MySQL, to conserve system resources, however knowing the right SIGnal to send a process is important, too: https://en.wikipedia.org/wiki/Kill_(command)



                  When in doubt, try to use the pkill command for named-processes, such as mariadb/httpd or kill -15 to immediately nuke a process.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Dec 24 '18 at 5:14









                  Xenfomation

                  1




                  1



























                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Unix & Linux Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.





                      Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                      Please pay close attention to the following guidance:


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f377191%2fwhy-are-we-using-kill-9-always%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown






                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Displaying single band from multi-band raster using QGIS

                      How many registers does an x86_64 CPU actually have?