Can't do process.on('SIGINT' with 0.5.4 on windows #1553
Comments
|
this happend on windows xp btw |
|
SIGINT is not supported in windows indeed. It is possible to capture ctrl+c / ctrl+break on windows, but there is no support for this yet in node. Adding event emitters should probably not crash node, but for the time being it might actually be good if it does. |
|
Catching Windows events and emitting them as SIGINT / SIGTERM signals through the |
|
I had almost forgotten about it, but this issue is the one that made me start making code contributions to Node. |
|
Seems like a sensible way to accomplish this would be to have a win32-specific MSDN lists the "signals" a process can receive from the console, and maybe in combination with what can be received in normal conditions (process shutdown, etc.) emulate the POSIX equivalents. The problems I see with this are twofold:
Thoughts? Obviously not a member of the team or anything, but I've been contemplating a patch and wanted feedback. |
|
I agree that we'll need a way for node apps to capture console control signals. A patch should go into libuv - we haven't discussed this yet, but it seems obvious that we'll have to put a somewhat cross-platform equivalent of ev_signal in libuv. |
|
Windows has literally no equivalent to UNIX signals. The function you link to is a complete fake: sending a signal to the function directly executes the associated signal handler in the calling thread. Ctrl-c is trappable and maps relatively well to SIGINT, and I think we should plumb in a handler to allow process.on('SIGINT') to map to ctrl-c. Beyond that, I can't think off-hand of anything else in Windows that's even remotely signal-like.
|
|
@DrPizza |
|
I'm not sure if they're exactly the same, but probably close enough. More problematic are things like SIGALRM, SIGUSR, SIGHUP.
|
|
Python's
Is the functionality in |
|
@wyattanderson |
|
I think we can probably do something like this:
There might be some value in making |
|
Sounds good, @DrPizza. I like the idea of mapping |
|
As for the implementation... node_signal_watcher.cc currently uses libev directly. My assumption is that libev should be hidden behind libuv, just as libeio is being hidden. There's the other side to the equation-- |
|
It seems java used
|
|
We should get this in v0.6 |
|
CTRL_C_EVENT -> SIGINT is what seems most natural to me. Many tools I encounter on Windows use Ctrl+C to request a graceful shutdown, while Ctrl+Break is reserved for hard kills. CTRL_BREAK_EVENT -> SIGHUP seems a little unexpected. |
|
Consider the behaviour of, for example, Windows' own ping.exe when run in non-stop mode (ping -t). ctrl-c terminates; ctrl-break just prints statistics and continues. Consider Java's behaviour, which when used to profile or debug the application uses ctrl-break to print statistics to the console without interrupting execution. I think ctrl-break -> SIGHUP is entirely appropriate.
|
|
But SIGHUP doesn't mean "please print some statistics and carry on" it means "console/tty has been closed". People generally expect 'Break' to break execution. |
|
I know what SIGHUP means, but I do not actually care. SIGHUP to rehash is a common pattern for non-interactive (daemon) programs on UNIX. If you don't like it, complain to the authors of the many, many programs that already work this way. The convention exists regardless of SIGHUP's proper meaning. People don't generally expect "break" to do anything, and widely-used Windows programs, including some which ship with Windows, use ctrl-break to do something other than halt execution. If it's good enough for ping.exe, it's good enough for node.exe. In any case, the intent is not to provide a perfect mapping. It's to provide a useful one. Windows distinguishes between ctrl-c and ctrl-break, ping.exe demonstrates that there are useful reasons to distinguish between ctrl-c and ctrl-break. Making both ctrl-c and ctrl-break produce SIGINT would deny the ability to distinguish. Making ctrl-break produce SIGHUP is not perfect, but given the way SIGHUP is actually used by server programs, it is a reasonable fit.
|
|
I agree with making them distinguishable - hence my suggestions. Applications can assign handlers to do whatever they want (which is the original point of this issue), so all we have to worry about is having a logical mapping from Win32 to POSIX, without having to worry about what people might use them for. Both the programs you cite only use this functionality in specific situations, not as a general rule. |
|
As a "general rule", ctrl-break doesn't do anything at all.
|
|
Then map it to SIGUSR1. |
|
Why, when a standard UNIX daemon would put the corresponding action on SIGHUP?
|
|
Because a standard UNIX non-daemon wouldn't (and POSIX gives a different default action for SIGHUP). Further looking around the internet and the consensus seems to be that Ctrl+Break is equivalent to SIGQUIT (mostly based on the behaviour of Java, as you noted above). Another question is whether to discourage users from trying to handle CTRL_CLOSE_EVENT (by mapping it to SIGKILL) or not (using SIGTERM or similar). |
|
I think node.js's goal, "scalable network programs", makes the daemon the more relevant comparison. Yes, it can be used interactively, yes, it has a REPL. I know this. I still maintain that daemon behaviour is the more appropriate, over all. I don't really see how it can be "mapped" to SIGKILL. SIGKILL can't be caught. Unless you mean simply that it should call abort() or similar, to provide an effect roughly similar to SIGKILL. I don't like the sound of that. Windows' SIGKILL is TerminateProcess(). CTRL_CLOSE_EVENT is sent to the application to give it a few seconds to shut down; if it doesn't end in time, TerminateProcess() is then used. We shouldn't abort early.
|
|
@DrPizza "I know what SIGHUP means, but I do not actually care" But you should, or you end up giving wrong suggestions that may bring more bad than good. SIGHUP is unix equivalent of logout (hangup - hanging up the terminal line, legacy from the times where terminal was dialed and may get hang-up event, thus ending terminal session; hence, the nohup unix command to let the process survive SIGHUP). So it only natural that logout is mapped to SIGHUP and Ctrl+C is mapped to SIGUSR1. (and don't ask me why they overloaded it with another meaning in case of daemons) @OrangeDog: +1 to your list with SIGUSR1 amendment. |
|
Good point about SIGKILL, was getting confused with How about: |
|
Convention is far more important than specification. Node's forte is daemon-like programs; it should follow daemon conventions. And mapping ctrl-c to SIGUSR1 is indefensible.
|
|
The Windows logoff event simply isn't comparable in terms of when it's sent or how it's sent. CTRL_LOGOFF_EVENT is (per the documentation, though not necessarily the implementation) sent only to services (i.e. programs connected to the SCM). While there's some evidence that it's also, erroneously, sent to interactive programs, they also get terminated afterwards anyway. node.js has no facility for creating Windows services, so the entire CTRL_LOGOFF_EVENT machinery is irrelevant to it. Consider also: there's no (easy) way to send the logoff event to a process, so no (easy) way to get SIGHUP-style configuration rehashing. ctrl-c and ctrl-break are the only signals that are easy to send, because they're the only ones that can be typed at the keyboard.
|
|
Just to keep everyone posted, the behavior that ctrl+break starts the debugger has been removed. To start the debugger, use |
|
Although there's been lively argument above, this still seems an issue. I'm currently hitting it on windows in node 0.6.6. Personally, I don't care about what maps to SIGHUP. The thing stopping me right now is not being able to bind SIGINT. Could this issue be broken into non-contentious and contentious parts and dealt with piecemeal? |
|
Priority order should be:
|
|
Is this still a problem? Im running win 0.6.6 |
|
Still a problem in v0.6.9 (Win7x64) |
ghost
assigned 
|
I suggest managing processes by simple http server example, Any flexibility of SIGINT, SIGQUIT, SIGTERM, SIGHUP, SIGUSR* can be programmed inside that “process controlling channel”. Just some localhost privilege separation and auth will be needed. Especially this is true when we see, that automation scripting in e.g. WSH has only Terminate() method to manage execution of a process by its PID ( I.e. if SIG* stuff will be implemented under MS Windows, it will be a thing inside If other application must be managed, signals aren’t right thing to do also. I.e. |
|
@olecom Not every Node program is am HTTP server. Also, a public webserver that terminates when you make a particular request is not a good idea. Perl supports "signals" on Windows using exactly the same syntax as on *NIX (i.e. it's actually a portable platform), so I don't see why Node shouldn't too. |
|
So this is not a node "0.5.4" version but more with windows and node. The title is a bit miss leading. |
It is the right thing to do because it is independent of other app API Mongo has {"shutdown":1}. Does mysql or nginx have it? But SIGINT will shutdown them both. |
Right. |
|
just hit this with node 0.6.15 |
|
As thrilling as these semantic discussions have been, we really need to finalize a way to monitor processes in all OSes using a consistent API. Cleaning up after worker processes when using |
|
I little work around I found is to capture the STDIN and use if(process.platform === "win32"){
var rint = require('readline').createInterface( process.stdin, {} );
rint.input.on('keypress',function( char, key) {
if(char === "\u0003"){
process.exit();
}
});
require('tty').setRawMode(true);
} |
|
@altIvan That won't work when |
|
@penartur Yeah, I am sure it doesn't work in many situations, is just if you are doing something really simple and just want |
|
I tossed-in an ugly try/catch around this issue for now, but it would be nice if node didnt blow chunks on this. |
|
Agreed, less chunk-blowing would be preferable. |
|
It appears that ea1cba6, which landed in v0.8.9, avoids the throw of 'no such module' |
|
Yes, this should be solved now. Closing. |
PR-URL: nodejs#1553 PORT-PR-URL: nodejs/node#1560 PORT-FROM: v2.x / f9c681c Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
original issue is here https://github.com/Pita/etherpad-lite/issues/94
We get following error message:
is on SIGINT a unix specific thing? is there something similar for windows? or is this a bug
The text was updated successfully, but these errors were encountered: