Thanks for the clarification. What it took me a while to understand is that
when a handler for SIGINT/SIGTERM is registered it prevents the default
SignalExit handler from firing. So I technically still can get the "exit"
event. I just need to either call process.exit or clean up all my handles
in the SIGINT handler, like so:
var timer = setInterval(function () {
console.log('hello');
}, 500);
process.on('SIGINT', function () {
clearInterval(timer); // Or call process.exit()
});
process.on('exit', function () {
// We get here because we don't have
// any active handles left.
console.log('exit');
});
I like this behavior, so I don't mean to sound like I'm complaining about
it. Just took me a little while to fully understand it, that's all.
--
Michael Jackson
@mjackson
On Thu, Jan 31, 2013 at 1:31 AM, Ben Noordhuis <[email protected]> wrote:
> On Thu, Jan 31, 2013 at 1:59 AM, Michael Jackson <[email protected]>
> wrote:
> > It would be really nice to be able to exit a process gracefully on
> > SIGINT/SIGTERM. Right now both signals are hardwired to exit with a
> status
> > of 1 (see the SignalExit function in node.cc) without emitting the "exit"
> > event on the process object, but I don't see why that needs to be the
> case.
> >
> > Ideally these signals would be handled just like any other signal. The
> > default may be to exit with a 1 status, but it would be nice to be able
> to
> > override this in userland.
>
> You can:
>
> process.on('SIGTERM', function() {
> // do whatever
> });
>
> Ditto for SIGINT.
>
> The reason why the default handler exits is:
>
> a) Historical, and
>
> b) Semantic. The 'exit' event is emitted only when the event loop has
> completed (no active handles left). Such is not the case with SIGINT
> or SIGTERM.
>
> > A couple of real world use cases:
> >
> > - Using Ctrl+C in a terminal that is attached to a running process
> > - Heroku's dyno manifold issues SIGTERM to processes to let them know
> they
> > are going to be restarted (see
> > https://devcenter.heroku.com/articles/ps#graceful-shutdown-with-sigterm).
> As
> > it stands now there is no way to ensure that a running server doesn't
> drop
> > open connections during a deploy on Heroku.
> >
> > What is the reason for the current behavior? Is there any way around it
> for
> > the use cases I've described?
> >
> > Thanks in advance.
> >
> > --
> > Michael Jackson
> > @mjackson
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
