Skip to content

Node v5.x.x does not exit on Ctrl-C in Docker container #4182

Closed

Description

@adam-beck
server.js
var http = require('http');
var server = http.createServer();


server.listen(3000, function() {
  console.log('listening on port 3000...');
});

docker run --rm -it -v /home/foo/repos/test/server.js:/usr/test/server.js -w /usr/test node node server.js

You are unable to kill the server by using Ctrl-C anymore. I've tried testing this with an older version of node (0.10.41) and it seems to be working properly. I am able to use docker stop $CONTAINER_ID and it will stop the container.

May be something similar to this

Activity

  1. evanlucas commented on Dec 8, 2015

    @evanlucas
    Contributor

    There is another issue (somewhere in the archive repo) that goes into detail on why that is the intended behavior (I'm searching for it). But, to work around, you can add listeners for those signals and then call process.exit()

  2. chrisdopuch commented on Dec 9, 2015

    @chrisdopuch

    I was able to reproduce this problem using Node 5.2.0, and I also reproduced the correct behavior with Node 0.10.41.

    @evanlucas your workaround does work great, added the following to @adam-beck 's code and was able to end the process in Node 5.2.0 with Ctrl-c

    process.on('SIGINT', function() {
        process.exit();
    });
    

    Docker version 1.8.2
    docker-machine version 0.4.1
    OSX Yosemite 10.10.5

  3. adam-beck commented on Dec 10, 2015

    @adam-beck
    Author

    The above code worked. Thanks @evanlucas & @chrisdopuch.

  4. samsalisbury commented on Jan 13, 2016

    @samsalisbury

    Should this issue be closed @adam-beck @evanlucas @chrisdopuch ? It seems like broken behaviour, since node usually exits on SIGINT on Mac, why should it need to have explicit handlers registered when running inside a Ubuntu-14 Docker container? It means that Node code is not portable in this regard, which seems like an odd decision if it is really intended.

  5. chrisdopuch commented on Jan 13, 2016

    @chrisdopuch

    I agree @samsalisbury, and I would also still like to see this issue resolved.

  6. MylesBorins commented on Jan 13, 2016

    @MylesBorins
    Contributor

    /cc @nodejs/ctc

  7. samsalisbury commented on Jan 14, 2016

    @samsalisbury

    Also note that this is broken at least as early as node 4.2.3, which is what I'm using now, and probably earlier.

  8. misterdjules commented on Jan 14, 2016

    @misterdjules

    @evanlucas Were you looking for nodejs/node-v0.x-archive#9131, as indicated at the bottom of the issue's description (maybe edited after your comment was posted)?

  9. MylesBorins commented on Jan 14, 2016

    @MylesBorins
    Contributor

    nodejs/node-v0.x-archive#9131 (comment) seems to do a really good job of describing what is happening, and why this appears to be an issue with docker not node. The issue tracking this on docker was closed as fixed, and it seems if process.on('sigint') is firing than perhaps docker is passing the SIGINT to pid 1 as expected.

    I think someone with a bit more docker understanding needs to take a peak @nodejs/docker

  10. evanlucas commented on Jan 14, 2016

    @evanlucas
    Contributor

    Thanks @misterdjules for the link. I was thinking there was another issue, but I have been unable to find it. I agree with @thealphanerd that the description in the previous issue explains it pretty well. But, since @indutny signed off on the commit that changed this behavior, perhaps he can shed some light on this.

  11. eljefedelrodeodeljefe commented on May 20, 2017

    @eljefedelrodeodeljefe
    Contributor

    This should be reopened.
    Also I am pretty sure our closing behaviour is faulty in a number of places.

    E.g. in C++ we should register the default handler with std::signal, since std::raise would cause implementation defined behaviour. Which though I cal rule out to be the cause of this.

    Again for reference, this commit c61b0e9 was believed to cause this.

  12. bnoordhuis commented on May 20, 2017

    @bnoordhuis
    Member

    @eljefedelrodeodeljefe Then please file a new issue. This one is about PID 1 being special when it comes to signals, it's not a node issue.

  13. eljefedelrodeodeljefe commented on May 20, 2017

    @eljefedelrodeodeljefe
    Contributor

    Will do.

  14. lakruzz commented on Jun 11, 2018

    @lakruzz

    Another solution, which doesn't require any change in the code, is to add --pid=host to the docker run startup arguments.

    That will allow you to kill the host, with <CTRL>+C

  15. thelebster commented on Jun 15, 2018

    @thelebster

    @lakruzz this worked for me. I have a running gulp watch task from the docker on macosx.
    2018-06-15_08-43-30

  16. added a commit that references this issue on Sep 3, 2019
  17. slavafomin commented on Jan 5, 2022

    @slavafomin

    Another solution, which doesn't require any change in the code, is to add --pid=host to the docker run startup arguments.

    That will allow you to kill the host, with <CTRL>+C

    This really helped me 4 years later, thanks :)

  18. smijar commented on May 9, 2022

    @smijar

    Another solution, which doesn't require any change in the code, is to add --pid=host to the docker run startup arguments.
    That will allow you to kill the host, with <CTRL>+C

    This really helped me 4 years later, thanks :)

    Thanks, brilliant!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions