Closed h2non closed 9 years ago
This happens with node version 0.12 also. Tested with version 0.12.1 and 0.12.2 on linux and darwin os.
It starts the app fine, but requires two Ctrl-C
's to exit the app and the app won't run again until the .nar
directory is removed (gives error Error: cannot clean the output path. Check the directory permissions
)
Is this maybe something to do with the stream api changes in node 0.12 vs 0.10?
Are there any work arounds for this?
Sample commands used to package:
nar create --executable --os linux --arch x64 --node 0.12.2
nar create --executable --os darwin --arch x64 --node 0.12.2
Thank you for the comment.
iojs
based executables can be created with the new 0.3.19
version.
npm update -g nar
Regarding to your question, try it again updating nar, since I've upgraded some third-party dependencies which improves the support and cross compatibility for newer node/io versions
Thanks for the update!
I've tried version 0.3.19
and it still takes two Ctrl-C
's to exit, but it will run again without removing the .nar
directory.
I can probably work with this.
If you're starting a network based application, such an HTTP server, it will remain in the event loop queue until it ends (closing the socket, for instance), so there isn't a SIGTERM signal received in the child process created by nar, that's the main reason you need to force the exit
Which kind of application you're using?
I'm starting an HTTPS server and listening for the SIGTERM and SIGINT events (using process.on()
) so I can close the server connections when the process is killed.
If nar does not listen/pass the SIGTERM/SIGINT events, is there another event I should listen for to do the same thing?
You could try with the following:
process.on()
, usually dispatched by CTRL+Cprocess.exit(code)
This should work!
The first two bullets are what I'm currently doing. See code sample below:
process.on('SIGINT', server.stop.bind(server));
process.on('SIGTERM', server.stop.bind(server));
This is enough to close my process cleanly when invoked via node, but not when invoked by nar.
I'll do some more testing to see if my callbacks are getting called in the nar bundle.
Definitely appreciating the help!
I changed my SIGINT/SIGTERM listeners to:
process.on('SIGINT', function () {
console.log('got SIGINT event');
server.stop();
});
process.on('SIGTERM', function () {
console.log('got SIGTERM event');
server.stop();
});
And now it exits as soon as it starts.....
...
Run [start]: /usr/bin/env bash /home/user/.nar/nar/scripts/node.sh app.js
Running application...
End [start]: exited with code 0
Finished
-sh-4.1$
It's still working normally if I run it with node app.js
.....maybe something I need to do related to signal handling in a nar environment?
Sorry, that last comment was a little misinformed.
It was exiting because there was an orphaned process listening on the same port the app was trying to listen to.
It starts fine, but still takes two Ctrl-C
's to exit (though my callback is being called):
Run [start]: /usr/bin/env bash /home/user/.nar/nar/scripts/node.sh app.js
Running application...
> Mon, 11 May 2015 18:02:09 GMT info { address: '::', family: 'IPv6', port: 8080 }
^CEnd [start]: exited with code 0
Finished
> got SIGINT event
^C
-sh-4.1$
The interesting thing is that it closes cleanly when invoked with node, but not when packaged as a nar app.....
I can add a timeout with a call to process.exit()
, but feels like a bit of a work around.
Calling process.exit()
does not seem to work either....it's like the child process where my app is running is exiting, but the parent process is not.
I see. I'll recreate a similar scenario to reproduce your error and I'll come back with the result.
Thanks. Really appreciate the support!
Doing a little more debug and it seems that the issue happens when running the archive and pressing Ctrl-C
from the same tty.
There are 4 levels of processes:
1) bash app-0.0.1-linux-x64.nar
2) ~/.nar/bin/node ~/.nar/nar/bin/nar start ~/.nar/app-0.0.1.nar
3) bash ~/.nar/nar/scripts/node.sh app.js
4) node app.js
If I send a SIGINT
or SIGTERM
signal to process 4
from another tty session, then all 4 processes exit clean.
When I press Ctrl-C
in the same tty where I executed the nar executable, processes 3
and 4
exit, but processes 1
and 2
remain (which lead to the need to press Ctrl-C
again to exit fully).
Since I can kill the server cleanly by having my app write it's pid to a pidfile and then send signals accordingly, this is no longer a blocking issue for me.
However, I thought the additional info on the behavior I'm seeing might be of interest.
Thanks again for the help and the great tool!
I realize that this issue is closed but the problem still seems to exist. Are there any intentions on solving it?
In my use case I have a process manager which sends a SIGINT to the process it started which would be 1
from the description above. That leaves 3
and 4
still running which is a problem.
@mattiasrunge Would you mind creating a demo project to reproduce the issue?
Process never ends