nx: nx:run-commands hangs when running multiple commands sequentially

Current Behavior

Having a simple target inside project.json -> targets

"test": {
      "executor": "nx:run-commands",
      "options": {
        "commands": [
          "echo 'test 1'",
          "echo 'test 2'"
        ],
        "parallel": false
      }
    },

It only prints ‘test 1’ and hangs indefinitely. It is not possible to stop the process. Tested it with NX 17.3.2 and it works as expected with that version.

Expected Behavior

Both commands are executed sequentially (non parallel). Output is: test 1 test 2

GitHub Repo

No response

Steps to Reproduce

  1. Create new NX App with NX 18.x
  2. Add a new target to project.json with executor "executor": "nx:run-commands",
  3. Set "parallel: false"
  4. Add any 2 commands inside "options" -> "commands" array

Nx Report

Node   : 18.18.0                                         
OS     : win32-x64                                       
npm    : 9.8.1

   nx                 : 18.0.3
   @nx/js             : 18.0.3
   @nx/jest           : 18.0.3
   @nx/linter         : 18.0.3
   @nx/eslint         : 18.0.3
   @nx/workspace      : 18.0.3
   @nx/devkit         : 18.0.3
   @nx/eslint-plugin  : 18.0.3
   @nx/next           : 18.0.3
   @nx/playwright     : 18.0.3
   @nx/react          : 18.0.3
   @nrwl/tao          : 18.0.3
   @nx/web            : 18.0.3
   @nx/webpack        : 18.0.3
   typescript         : 5.3.3

Failure Logs

No response

Package Manager Version

9.8.1

Operating System

  • macOS
  • Linux
  • Windows
  • Other (Please specify)

Additional Information

No response

About this issue

  • Original URL
  • State: closed
  • Created 5 months ago
  • Reactions: 19
  • Comments: 23 (5 by maintainers)

Most upvoted comments

Just chiming in since we just experienced quite a similar issue but I have no additional information wether it is a separate one. We also have targets with sequential nx:run-commands which fail to execute / hang after 1-2 commands.

Funnily enough, once we add --output-style=stream, the commands succeed.

So TL;DR

npx nx run <project>:<target> --verbose                         # fails
npx nx run <project>:<target> --verbose --output-style=stream   # succeeds

Also interestingly, I could not observe the failures when invoking the target through nx run-many. Maybe this helps anyone?

Node   : 20.10.0
OS     : win32-x64
npm    : 10.2.3

nx                 : 18.0.5
@nx/js             : 18.0.5
@nx/jest           : 18.0.5
@nx/linter         : 18.0.5
@nx/eslint         : 18.0.5
@nx/workspace      : 18.0.5
@nx/devkit         : 18.0.5
@nx/eslint-plugin  : 18.0.5
@nx/express        : 18.0.5
@nx/node           : 18.0.5
@nx/plugin         : 18.0.5
@nx/react          : 18.0.5
@nrwl/tao          : 18.0.5
@nx/web            : 18.0.5
@nx/webpack        : 18.0.5
typescript         : 5.3.3

One other fix, that works for me, is the following and after that everything works fine under windows.

Adding NX_NATIVE_COMMAND_RUNNER=false to the .env file at workspace root. The .env file was introduced with NX18.

@Cammisuli

Using NX_NATIVE_COMMAND_RUNNER=false does fix the issue for me with the simpler task syntax.

  "targets": {
    "some-task": {
      "command": "echo 'Command 1'"
    },
  ...

And it also seems to work when I use the nx:run-commands syntax.

  "targets": {
    "some-task": {
      "executor": "nx:run-commands",
      "options": {
        "commands": [
          "echo 'Command 1'",
          "echo 'Command 2'"
        ],
        "parallel": false
      }
    },
  ...

I’ll look into this as soon as possible. In the meantime, can you confirm that things work as expected when setting the env var NX_NATIVE_COMMAND_RUNNER=false?

I ran today into the same problem. We have updated from NX17 to NX18 and the problem occurs. My collegues which are using mostly Mac are fine, the problem is only for me and those who are using Windows.

I am having the same issue with building my react frontend. The build commands hangs at one point after builiding all the libraries. I have also tried using the command after adding NX_NATIVE_COMMAND_RUNNER=false to the root .env.

I have generated a ticket but haven’t gotten any leads on it. #22094

My colleague had issues with some WSL process running away.

I wonder if it’s something to do with using Terminal (non-wsl) then behind the scenes NX is shelling commands which are running in WSL and something between the two environments is going bad.

When the issue happened for him, this process went runaway.

image

It kept growing in memory usage and was sustaining ~100MB/s disk usage until his machine grinds to a halt and needs a hard reset.

Ok I’ll check again with that.

@Cammisuli

Using NX_NATIVE_COMMAND_RUNNER=false does fix the issue for me with the simpler task syntax.

  "targets": {
    "some-task": {
      "command": "echo 'Command 1'"
    },
  ...

And it also seems to work when I use the nx:run-commands syntax.

  "targets": {
    "some-task": {
      "executor": "nx:run-commands",
      "options": {
        "commands": [
          "echo 'Command 1'",
          "echo 'Command 2'"
        ],
        "parallel": false
      }
    },
  ...

I can confirm this works for me.

However I was trying to be a smartypants and did this

        "start": {
            "executor": "nx:run-commands",
            "dependsOn": ["build"],
            "options": {
                "commands": ["my-command"],
                "env": {
                    "NX_NATIVE_COMMAND_RUNNER": "false"
                },
                "parallel": false
            }
        }

But that did not work

I’ll look into this as soon as possible. In the meantime, can you confirm that things work as expected when setting the env var NX_NATIVE_COMMAND_RUNNER=false?

Same result for me: hangs when executing my original prebuild task which has two commands.

Not really a workaround and it scales horribly, cause if you had let’s say 7 commands you would need to add 7 targets with a lot of syntax sugar. As a workaround I would suggest for now downgrade nx to 17.

You are quite right that it doesn’t scale, and I only mention it to back up that I’ve seen the same behaviour, and in case anyone else only has two commands and is happy to wait for a fix by doing what I’m doing (in fact, only one command with a chained dependsOn seems to have the same problem as I see you’ve mentioned elsewhere - behaviour I also see).

Not really a workaround and it scales horribly, cause if you had let’s say 7 commands you would need to add 7 targets with a lot of syntax sugar. As a workaround I would suggest for now downgrade nx to 17.