Use SIGTERM instead of SIGKILL when ending processes, allow attachSimplePort=0

Describe the bug

(Note sure if bug or feature request is most appropriate, this might be a somewhat special case!)

wskdebug is a debugging tool for Apache Openwhisk (a serverless platform), which starts a container with a nodejs process inside that will have the actual debug port to which the VS Code debugger should connect. I am using this in VS Code as runtimeExecutable and have been intercepting the --inspect-brk=NNNN argument that was set by the previous debugger to use this port on the container that gets started. VS Code then did connect to the container, which was great.

However, it seems the new debugger uses a different mechanism. Apparently it sets NODE_OPTIONS with a --require that loads a JS file into the node process that apparently sets up the debugging from “inside” the process.

The problem is that now it debugs the wskdebug “intermediary” and not the target container.

Is there a way in the new debugger I can disable that and just get hold off the port number (which VS code randomly chooses, i.e. in case there are multiple debug sessions going on)?

See also https://github.com/apache/openwhisk-wskdebug/issues/74

On a related note, the new debugger seems to kill the process at the end immediately (SIGKILL style). The previous debugger sent a SIGTERM so that the process had a chance to cleanup and properly exit. In wskdebug case this is used to stop the docker container amongst other things. With the new debugger this is no longer possible and thus the container with the open debug port is left behind, so that the next run usually fails with “debug port already in use”. This is also an artifact of the above issue since always the same default debug port (9229) is picked now since --inspect-brk=NNNN with a unique port NNNN is missing.

To Reproduce Steps to reproduce the behavior:

1. Run launch config with wskdebug as described here
2. Notice debugger connects to wskdebug itself, but not the container it starts
3. Cannot hit any breakpoints since it’s debugging the wrong process

Log File

vscode-debugadapter-9.json.gz

VS Code Version: 1.47.1

[connor4312]

Yep, they are

[connor4312]

The nightly where --inspect-brk will not be filtered is today’s nightly, which will be available in about two hours from now 🙂

The change you want in your launch.json is

{
  "type": "pwa-node", // if only "node", VS Code will complain
  "request": "launch",
  "name": "My launch",
+ "attachSimplePort": 9229,