How can I stop a docker container running sleep?












0















sleep is a stand-in for most complex processes of course.



This Dockerfile (as you can see using the exec form so that there is only one process running and no children of bash):



FROM busybox
CMD ["/bin/sleep", "100000"]


creates an uninterruptible container:



docker build -t kill-sleep .
docker run --rm --name kill-sleep kill-sleep


When I try to stop it:



time docker stop kill-sleep

kill-sleep
real 0m10.449s
user 0m0.021s
sys 0m0.027s


the command times out at 10 seconds before the container is killed.



The problem isn't that sleep doesn't handle signals, because if I run it on the host:



sleep 100000
# in another shell
ps faxww | grep sleep
kill -TERM 31333 # the PID


the process stops immediately.



The problem may have to do with the fact that this is running as PID 1 in the container, but I have yet to see a reference documentation for that.










share|improve this question



























    0















    sleep is a stand-in for most complex processes of course.



    This Dockerfile (as you can see using the exec form so that there is only one process running and no children of bash):



    FROM busybox
    CMD ["/bin/sleep", "100000"]


    creates an uninterruptible container:



    docker build -t kill-sleep .
    docker run --rm --name kill-sleep kill-sleep


    When I try to stop it:



    time docker stop kill-sleep

    kill-sleep
    real 0m10.449s
    user 0m0.021s
    sys 0m0.027s


    the command times out at 10 seconds before the container is killed.



    The problem isn't that sleep doesn't handle signals, because if I run it on the host:



    sleep 100000
    # in another shell
    ps faxww | grep sleep
    kill -TERM 31333 # the PID


    the process stops immediately.



    The problem may have to do with the fact that this is running as PID 1 in the container, but I have yet to see a reference documentation for that.










    share|improve this question

























      0












      0








      0








      sleep is a stand-in for most complex processes of course.



      This Dockerfile (as you can see using the exec form so that there is only one process running and no children of bash):



      FROM busybox
      CMD ["/bin/sleep", "100000"]


      creates an uninterruptible container:



      docker build -t kill-sleep .
      docker run --rm --name kill-sleep kill-sleep


      When I try to stop it:



      time docker stop kill-sleep

      kill-sleep
      real 0m10.449s
      user 0m0.021s
      sys 0m0.027s


      the command times out at 10 seconds before the container is killed.



      The problem isn't that sleep doesn't handle signals, because if I run it on the host:



      sleep 100000
      # in another shell
      ps faxww | grep sleep
      kill -TERM 31333 # the PID


      the process stops immediately.



      The problem may have to do with the fact that this is running as PID 1 in the container, but I have yet to see a reference documentation for that.










      share|improve this question














      sleep is a stand-in for most complex processes of course.



      This Dockerfile (as you can see using the exec form so that there is only one process running and no children of bash):



      FROM busybox
      CMD ["/bin/sleep", "100000"]


      creates an uninterruptible container:



      docker build -t kill-sleep .
      docker run --rm --name kill-sleep kill-sleep


      When I try to stop it:



      time docker stop kill-sleep

      kill-sleep
      real 0m10.449s
      user 0m0.021s
      sys 0m0.027s


      the command times out at 10 seconds before the container is killed.



      The problem isn't that sleep doesn't handle signals, because if I run it on the host:



      sleep 100000
      # in another shell
      ps faxww | grep sleep
      kill -TERM 31333 # the PID


      the process stops immediately.



      The problem may have to do with the fact that this is running as PID 1 in the container, but I have yet to see a reference documentation for that.







      docker






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Mar 1 '18 at 11:16









      giorgiosironigiorgiosironi

      208148




      208148






















          1 Answer
          1






          active

          oldest

          votes


















          3














          When you run docker stop ..., some things will happen:





          1. docker sends a SIGTERM to the main process of the container.
            The process is able to mask/ignore a SIGTERM, and if it does so (or handles it without terminating) "nothing" will happen.

          2. After a timeout (default 10 seconds), docker sends a SIGKILL to the main process. This signal cannot be masked by a process, and thus it dies immediately with no opportunity for executing a shutdown prodedure.


          Ideally, processes run within docker will respond to the SIGTERM in a timely fashion, taking care of any housekeeping before terminating.



          If you know that the process either doesn't have any housekeeping to perform (e.g: sleep), or will not respond properly to SIGTERM, you can specify a shorter (or longer) timeout with the -t flag:




          -t, --time=10
          Seconds to wait for stop before killing it



          For example, in your case, you may like to run docker stop -t 0 ${CONTAINER}.





          The reason that this signal behaviour is different is due to the sleep running with PID = 1.



          Typically (e.g: running with PID != 1), any signal that the process doesn't explicitly deal with leads to the process being terminated - try sending a sleep a SIGUSR1.



          However, when running with PID = 1, unhandled signals are ignored, otherwise you'd end up with a kernel panic:



          Kernel panic - not syncing: Attempted to kill init!




          You can send a signal to the docker container using docker tools, for example:



          docker kill -s TERM kill-sleep


          As we can see, this doesn't have the desired effect, whereas this does:



          docker kill -s KILL kill-sleep




          An Experiment



          Dockerfile



          FROM busybox
          COPY run.sh /run.sh
          RUN chmod +x /run.sh
          CMD "/run.sh"


          run.sh



          #!/bin/sh

          echo "sleeping"
          sleep 100000


          Now, run



          docker build -t kill-sleep .
          docker run --rm --name kill-sleep kill-sleep


          And this in a different terminal:



          docker stop kill-sleep


          We observe the same 10 second delay / timeout.



          A Solution



          Now let's handle the SIGTERM. Backgrounding and waiting for sleep are due to how a POSIX shell handles signals (see this for more).



          run.sh



          #!/bin/sh

          die_func() {
          echo "oh no"
          sleep 2
          exit 1
          }
          trap die_func TERM

          echo "sleeping"
          sleep 100000 &
          wait


          Run the commands again, and we see what we are after!



          $ time docker stop kill-sleep
          kill-sleep

          real 0m2.515s
          user 0m0.008s
          sys 0m0.044s





          share|improve this answer

























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "3"
            };
            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: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            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%2fsuperuser.com%2fquestions%2f1299461%2fhow-can-i-stop-a-docker-container-running-sleep%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            3














            When you run docker stop ..., some things will happen:





            1. docker sends a SIGTERM to the main process of the container.
              The process is able to mask/ignore a SIGTERM, and if it does so (or handles it without terminating) "nothing" will happen.

            2. After a timeout (default 10 seconds), docker sends a SIGKILL to the main process. This signal cannot be masked by a process, and thus it dies immediately with no opportunity for executing a shutdown prodedure.


            Ideally, processes run within docker will respond to the SIGTERM in a timely fashion, taking care of any housekeeping before terminating.



            If you know that the process either doesn't have any housekeeping to perform (e.g: sleep), or will not respond properly to SIGTERM, you can specify a shorter (or longer) timeout with the -t flag:




            -t, --time=10
            Seconds to wait for stop before killing it



            For example, in your case, you may like to run docker stop -t 0 ${CONTAINER}.





            The reason that this signal behaviour is different is due to the sleep running with PID = 1.



            Typically (e.g: running with PID != 1), any signal that the process doesn't explicitly deal with leads to the process being terminated - try sending a sleep a SIGUSR1.



            However, when running with PID = 1, unhandled signals are ignored, otherwise you'd end up with a kernel panic:



            Kernel panic - not syncing: Attempted to kill init!




            You can send a signal to the docker container using docker tools, for example:



            docker kill -s TERM kill-sleep


            As we can see, this doesn't have the desired effect, whereas this does:



            docker kill -s KILL kill-sleep




            An Experiment



            Dockerfile



            FROM busybox
            COPY run.sh /run.sh
            RUN chmod +x /run.sh
            CMD "/run.sh"


            run.sh



            #!/bin/sh

            echo "sleeping"
            sleep 100000


            Now, run



            docker build -t kill-sleep .
            docker run --rm --name kill-sleep kill-sleep


            And this in a different terminal:



            docker stop kill-sleep


            We observe the same 10 second delay / timeout.



            A Solution



            Now let's handle the SIGTERM. Backgrounding and waiting for sleep are due to how a POSIX shell handles signals (see this for more).



            run.sh



            #!/bin/sh

            die_func() {
            echo "oh no"
            sleep 2
            exit 1
            }
            trap die_func TERM

            echo "sleeping"
            sleep 100000 &
            wait


            Run the commands again, and we see what we are after!



            $ time docker stop kill-sleep
            kill-sleep

            real 0m2.515s
            user 0m0.008s
            sys 0m0.044s





            share|improve this answer






























              3














              When you run docker stop ..., some things will happen:





              1. docker sends a SIGTERM to the main process of the container.
                The process is able to mask/ignore a SIGTERM, and if it does so (or handles it without terminating) "nothing" will happen.

              2. After a timeout (default 10 seconds), docker sends a SIGKILL to the main process. This signal cannot be masked by a process, and thus it dies immediately with no opportunity for executing a shutdown prodedure.


              Ideally, processes run within docker will respond to the SIGTERM in a timely fashion, taking care of any housekeeping before terminating.



              If you know that the process either doesn't have any housekeeping to perform (e.g: sleep), or will not respond properly to SIGTERM, you can specify a shorter (or longer) timeout with the -t flag:




              -t, --time=10
              Seconds to wait for stop before killing it



              For example, in your case, you may like to run docker stop -t 0 ${CONTAINER}.





              The reason that this signal behaviour is different is due to the sleep running with PID = 1.



              Typically (e.g: running with PID != 1), any signal that the process doesn't explicitly deal with leads to the process being terminated - try sending a sleep a SIGUSR1.



              However, when running with PID = 1, unhandled signals are ignored, otherwise you'd end up with a kernel panic:



              Kernel panic - not syncing: Attempted to kill init!




              You can send a signal to the docker container using docker tools, for example:



              docker kill -s TERM kill-sleep


              As we can see, this doesn't have the desired effect, whereas this does:



              docker kill -s KILL kill-sleep




              An Experiment



              Dockerfile



              FROM busybox
              COPY run.sh /run.sh
              RUN chmod +x /run.sh
              CMD "/run.sh"


              run.sh



              #!/bin/sh

              echo "sleeping"
              sleep 100000


              Now, run



              docker build -t kill-sleep .
              docker run --rm --name kill-sleep kill-sleep


              And this in a different terminal:



              docker stop kill-sleep


              We observe the same 10 second delay / timeout.



              A Solution



              Now let's handle the SIGTERM. Backgrounding and waiting for sleep are due to how a POSIX shell handles signals (see this for more).



              run.sh



              #!/bin/sh

              die_func() {
              echo "oh no"
              sleep 2
              exit 1
              }
              trap die_func TERM

              echo "sleeping"
              sleep 100000 &
              wait


              Run the commands again, and we see what we are after!



              $ time docker stop kill-sleep
              kill-sleep

              real 0m2.515s
              user 0m0.008s
              sys 0m0.044s





              share|improve this answer




























                3












                3








                3







                When you run docker stop ..., some things will happen:





                1. docker sends a SIGTERM to the main process of the container.
                  The process is able to mask/ignore a SIGTERM, and if it does so (or handles it without terminating) "nothing" will happen.

                2. After a timeout (default 10 seconds), docker sends a SIGKILL to the main process. This signal cannot be masked by a process, and thus it dies immediately with no opportunity for executing a shutdown prodedure.


                Ideally, processes run within docker will respond to the SIGTERM in a timely fashion, taking care of any housekeeping before terminating.



                If you know that the process either doesn't have any housekeeping to perform (e.g: sleep), or will not respond properly to SIGTERM, you can specify a shorter (or longer) timeout with the -t flag:




                -t, --time=10
                Seconds to wait for stop before killing it



                For example, in your case, you may like to run docker stop -t 0 ${CONTAINER}.





                The reason that this signal behaviour is different is due to the sleep running with PID = 1.



                Typically (e.g: running with PID != 1), any signal that the process doesn't explicitly deal with leads to the process being terminated - try sending a sleep a SIGUSR1.



                However, when running with PID = 1, unhandled signals are ignored, otherwise you'd end up with a kernel panic:



                Kernel panic - not syncing: Attempted to kill init!




                You can send a signal to the docker container using docker tools, for example:



                docker kill -s TERM kill-sleep


                As we can see, this doesn't have the desired effect, whereas this does:



                docker kill -s KILL kill-sleep




                An Experiment



                Dockerfile



                FROM busybox
                COPY run.sh /run.sh
                RUN chmod +x /run.sh
                CMD "/run.sh"


                run.sh



                #!/bin/sh

                echo "sleeping"
                sleep 100000


                Now, run



                docker build -t kill-sleep .
                docker run --rm --name kill-sleep kill-sleep


                And this in a different terminal:



                docker stop kill-sleep


                We observe the same 10 second delay / timeout.



                A Solution



                Now let's handle the SIGTERM. Backgrounding and waiting for sleep are due to how a POSIX shell handles signals (see this for more).



                run.sh



                #!/bin/sh

                die_func() {
                echo "oh no"
                sleep 2
                exit 1
                }
                trap die_func TERM

                echo "sleeping"
                sleep 100000 &
                wait


                Run the commands again, and we see what we are after!



                $ time docker stop kill-sleep
                kill-sleep

                real 0m2.515s
                user 0m0.008s
                sys 0m0.044s





                share|improve this answer















                When you run docker stop ..., some things will happen:





                1. docker sends a SIGTERM to the main process of the container.
                  The process is able to mask/ignore a SIGTERM, and if it does so (or handles it without terminating) "nothing" will happen.

                2. After a timeout (default 10 seconds), docker sends a SIGKILL to the main process. This signal cannot be masked by a process, and thus it dies immediately with no opportunity for executing a shutdown prodedure.


                Ideally, processes run within docker will respond to the SIGTERM in a timely fashion, taking care of any housekeeping before terminating.



                If you know that the process either doesn't have any housekeeping to perform (e.g: sleep), or will not respond properly to SIGTERM, you can specify a shorter (or longer) timeout with the -t flag:




                -t, --time=10
                Seconds to wait for stop before killing it



                For example, in your case, you may like to run docker stop -t 0 ${CONTAINER}.





                The reason that this signal behaviour is different is due to the sleep running with PID = 1.



                Typically (e.g: running with PID != 1), any signal that the process doesn't explicitly deal with leads to the process being terminated - try sending a sleep a SIGUSR1.



                However, when running with PID = 1, unhandled signals are ignored, otherwise you'd end up with a kernel panic:



                Kernel panic - not syncing: Attempted to kill init!




                You can send a signal to the docker container using docker tools, for example:



                docker kill -s TERM kill-sleep


                As we can see, this doesn't have the desired effect, whereas this does:



                docker kill -s KILL kill-sleep




                An Experiment



                Dockerfile



                FROM busybox
                COPY run.sh /run.sh
                RUN chmod +x /run.sh
                CMD "/run.sh"


                run.sh



                #!/bin/sh

                echo "sleeping"
                sleep 100000


                Now, run



                docker build -t kill-sleep .
                docker run --rm --name kill-sleep kill-sleep


                And this in a different terminal:



                docker stop kill-sleep


                We observe the same 10 second delay / timeout.



                A Solution



                Now let's handle the SIGTERM. Backgrounding and waiting for sleep are due to how a POSIX shell handles signals (see this for more).



                run.sh



                #!/bin/sh

                die_func() {
                echo "oh no"
                sleep 2
                exit 1
                }
                trap die_func TERM

                echo "sleeping"
                sleep 100000 &
                wait


                Run the commands again, and we see what we are after!



                $ time docker stop kill-sleep
                kill-sleep

                real 0m2.515s
                user 0m0.008s
                sys 0m0.044s






                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Mar 7 '18 at 17:57

























                answered Mar 1 '18 at 11:25









                AttieAttie

                11.6k32845




                11.6k32845






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Super User!


                    • 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%2fsuperuser.com%2fquestions%2f1299461%2fhow-can-i-stop-a-docker-container-running-sleep%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 make a Squid Proxy server?

                    Is this a new Fibonacci Identity?

                    19世紀