-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
process: process.kill() and signals on Windows #12378
Comments
In addition, I can't attach an event listener for any signal fired by the |
The docs could doubtless be improved, but they say:
Then you say:
I don't get it, "silent exit" === "unconditional termination", doesn't it? What doc note are you talking about? And like the docs say, all other signals are unsupported. They should perhaps be un-supported more uniformly, perhaps with This is probably happening because node does some checking to convert signal strings to numbers, and it fails on Windows because it doesn't know about some signal strings. But even if it suceeds in converting a signal string to a number, Windows doens't support kill, thus its ENOSYS. |
per "example doesn't work", it links to the signal docs, which say under what conditions it works (3 signals have some emulation on windows). Perhaps its better to rework the docs, moving the signal list into two places, one in process.kill which describes behaviour when signal is sent, and one in process.on() which describes when signal is received. The current structure is I think contributing to the confusion. |
@sam-github 'despite the doc note': I mean, the doc states 'SIGTERM is not supported on Windows', but exactly |
Maybe you can improve it now that you know how it works? To be clear, SIGTERM is not supported on Windows as a signal. Windows as an O/S has absolutely no signal support. Like it says later (should probably be moved closer to the note you mention), sending SIGTERM/KILL/INT cause windows processes to be terminated on Windows, as a way of UV trying to emulate signals where they do not exist. If SIGTERM was supported on Windows, you could listen for it and receive it... but you cannot. You can listen..., but you'll never receive it. |
I try to abstain from writing English texts of a significant length, as I am clumsy at that. And, to be honest, signals on Windows is a murky topic for me. I do feel it is somehow wrong for me to just dump such issues that I can't fix myself. Sorry. Maybe somebody from @nodejs/platform-windows will find some time to refactor the doc on this topic in future. |
[offtopic] anyone knows a TODO app for windows that can track github issues? I would like to address this issue, but after I finish some stuff I'm doing. By them most probably I'd forget about this one. |
been trying octobox.io lately, I usually just keep a markdown file, http://todotxt.com/ can be nice, too. |
@refack alternately you could just assign it to yourself, then it'll show up in the GitHub list of |
The windows subsystem lacks signaling support using |
“Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.” @alohaninja no need to be so negative... |
@refack - posted a more positive contribution. Cheers for handling professionally. ;-) |
I'll bump it up my todo list 😉 a.k.a. I'll see what I can do... |
Is this still an issue? |
It seems all that could be done is done for now) |
I have to excute something like |
The doc states:
WRT supporting signals on Windows, the doc makes only this remark:
As for the rest,
process.kill()
behavior on Windows is somehow confusing and hazardous. A test file with just this line:gives three types of results.
SIGTERM
,SIGINT
,SIGKILL
(despite the doc note wrtSIGTERM
) — silently exit.SIGUSR1
,SIGPIPE
,SIGSTOP
,SIGBUS
— throw this error:SIGHUP
,SIGBREAK
,SIGWINCH
,SIGFPE
,SIGSEGV
,SIGILL
— throw this error:As with this issue, I am not sure, if this is a Node.js or libuv domain. Also I am not sure if this should be addressed in code or in docs. So just reporting for extra precaution.
The text was updated successfully, but these errors were encountered: