subprocess.kill should ignore signal argument on Windows

[fasttime]

Version

v18.0.0

Platform

Microsoft Windows NT 10.0.19044.0 x64

Subsystem

child_process

What steps will reproduce the bug?

The documentation about subprocess.kill([signal]) says:

On Windows, where POSIX signals do not exist, the signal argument will be
ignored, and the process will be killed forcefully and abruptly (similar to
'SIGKILL').

This does not seem to match the current behavior, where the signal argument is not ignored on Windows, and it can lead in fact to different results. A minimal repro:

// test.mjs - Run on Windows

import { spawn } from 'child_process';

spawn(process.execPath, ['-v']).kill('SIGKILL'); // ok
spawn(process.execPath, ['-v']).kill('SIGHUP'); // throws ENOSYS

How often does it reproduce? Is there a required condition?

Always on Windows

What is the expected behavior?

If the documentation is right, invoking kill('SIGHUP') on a subprocess on Windows should work exactly like kill('SIGKILL').

What do you see instead?

The signal argument is not currently ignored on Windows. I can't decide if this behavior is intended and the documentation is wrong or if the documentation is right and the behavior is incorrect.

Additional information

If someone could clarify me about the expectations of running subprocess.kill on Windows, I would be glad to submit a PR to fix the code or the documentation.

[fabiospampinato]

This seems a fairly significant issue, in the sense that anybody that is triggering a signal with process.kill without knowing this issue is probably doing it in a problematic way for Windows.

[ehmicky]

Documenting the change of behavior for anyone encountering it.

Windows does not really have the Unix concept of signals. So Node emulates it.
Node on Windows only supports the following signals:

• SIGINT, SIGQUIT, SIGTERM, SIGKILL: all have the behavior, i.e. to terminate the process immediately.
• SIGHUP, SIGILL, SIGABRT, SIGFPE, SIGSEGV, SIGWINCH, SIGBREAK: are present in os.constants.signals, can be listened to, but cannot be sent with subprocess.kill().

Before Node 23.4.0, calling subprocess.kill('SIGHUP') (and SIGILL, etc.) used to emit an error event on the subprocess, with error.code 'ENOSYS'. However, it does not terminate the subprocess.

Since Node 23.4.0, the signal is converted to SIGKILL instead. Which means the subprocess will not emit an error event, but end with an exit/close event. Also, the subprocess is terminated immediately. The event handler will receive (null, 'SIGKILL') as its (exitCode, signalCode) arguments.

[ehmicky]

@fabiospampinato @fasttime I am not sure this PR was made realizing the following points:

• This impacts not only SIGHUP but some other signals which are never meant for termination, such as SIGWINCH.
• The subprocess is now terminated abruptly. It did not used to. Note: emitting an error event on the subprocess does not terminate it (unless it has not been spawned yet).

The second point in particular is quite a breaking change.

I can see how a user sending SIGHUP would probably want to terminate the subprocess abruptly on Windows instead (since Windows does not support such signals). However, a user sending SIGWINCH most likely does not want to terminate the subprocess on Windows.

It seems to me:

1. This change should have been in a major release, since it is technically breaking.
2. Although calling subprocess.kill('SIGWINCH') rarely makes sense, that specific signal should still be ignored instead of terminating the subprocess abruptly.

[ehmicky]

Additionally, subprocess.kill(0) is now broken. I opened a separate issue for it at #57669 since it is a different problem that the one I was mentioned above, and might require a different solution.