Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SIGQUIT handler being ignored when node is loaded as a shared library #10520

Closed
sxa opened this issue Dec 29, 2016 · 2 comments
Closed

SIGQUIT handler being ignored when node is loaded as a shared library #10520

sxa opened this issue Dec 29, 2016 · 2 comments
Labels
build Issues and PRs related to build files or the CI. process Issues and PRs related to the process subsystem.

Comments

@sxa
Copy link
Member

sxa commented Dec 29, 2016

  • Version: 4 and later
  • Platform: Most UNIX-based platforms, but reported on xLinux
  • Subsystem: core - signal handling

I've had a report from a user that is having an issue with #615 which set all signal handlers back to the default ones. The user is loading a shared library build of node, and it is overriding their own SIGQUIT signal handler (actually one set by the JVM their application uses but that's not inherently relevant) so the expected behaviour of their application is being altered when they load the node.js runtime dynamically.

While the reasons for removing any existing handlers (when node is being exec'd from another process) may have been sound, I suspect it is likely to be generally undesirable in the shared library case where we are being invoked by another application.

I'm open to thoughts on this so am raising this issue while mulling solutions:

  1. I could look at not resetting any existing handlers in the shared library case (the most obvious option!)
  2. We could just leave any SIGQUIT handler in place to resolve this particular scenario
  3. We could look at skipping more of the startup section when loaded as a shared library
  4. Have a runtime parameter to control the overrides
  5. Something else?

FYI @bnoordhuis @sam-github since you wrote/reviewed the original PR, and @stefanmb for info ;-)

@sam-github
Copy link
Contributor

My 2 farthings: 1 and 3 looks reasonable, 2 seems excessively specific (SIGHUP or INT for example could quite reasonably have handlers set by the host process), 4 sounds excessively flexible for this specific problem (though maybe there is a set of problems that could all be helped with such a mechanism).

@gibfahn
Copy link
Member

gibfahn commented Dec 29, 2016

So presumably 1. is a subsection of 3. , i.e. if we're skipping the handler reset we should also look at skipping some other not-shared-library-suitable stuff? If so that seems like something we should be doing/checking in general.

@mscdex mscdex added build Issues and PRs related to build files or the CI. process Issues and PRs related to the process subsystem. labels Dec 29, 2016
sxa pushed a commit to sxa/node that referenced this issue Jan 16, 2017
Fixes: nodejs#10520
Ref: nodejs@dd47a8c

An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.
sxa pushed a commit to sxa/node that referenced this issue Jan 18, 2017
An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.

PR-URL: nodejs#10539
Fixes: nodejs#10520
Refs: nodejs#615
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
italoacasas pushed a commit to italoacasas/node that referenced this issue Jan 18, 2017
An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.

PR-URL: nodejs#10539
Fixes: nodejs#10520
Refs: nodejs#615
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
italoacasas pushed a commit to italoacasas/node that referenced this issue Jan 23, 2017
An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.

PR-URL: nodejs#10539
Fixes: nodejs#10520
Refs: nodejs#615
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
italoacasas pushed a commit to italoacasas/node that referenced this issue Jan 25, 2017
An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.

PR-URL: nodejs#10539
Fixes: nodejs#10520
Refs: nodejs#615
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
italoacasas pushed a commit to italoacasas/node that referenced this issue Jan 27, 2017
An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.

PR-URL: nodejs#10539
Fixes: nodejs#10520
Refs: nodejs#615
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
sxa pushed a commit to sxa/node that referenced this issue Feb 1, 2017
An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.

PR-URL: nodejs#10539
Fixes: nodejs#10520
Refs: nodejs#615
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
MylesBorins pushed a commit that referenced this issue Feb 21, 2017
An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.

PR-URL: #10539
Fixes: #10520
Refs: #615
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
MylesBorins pushed a commit that referenced this issue Feb 22, 2017
An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.

PR-URL: #10539
Fixes: #10520
Refs: #615
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
MylesBorins pushed a commit that referenced this issue Mar 8, 2017
An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.

PR-URL: #10539
Fixes: #10520
Refs: #615
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
MylesBorins pushed a commit that referenced this issue Mar 9, 2017
An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.

PR-URL: #10539
Fixes: #10520
Refs: #615
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
MylesBorins pushed a commit that referenced this issue Mar 9, 2017
An application using node built as a shared library may legitimately
implement its own signal handling routines. Current behaviour is
to squash all signal handlers on node startup. This change will
stop that behaviour when node is built as a shared library.

PR-URL: #10539
Fixes: #10520
Refs: #615
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI. process Issues and PRs related to the process subsystem.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants