Skip to content

Check cwd before spawning child process #11520

Description

@jhnns
  • Version: v7.6.0
  • Platform: Darwin Pecorino.local 16.4.0 Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21 PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64

When a cwd is passed to child_process.spawn() that does not exist, node just reports ENOENT:

const spawn = require("child_process").spawn

spawn(process.execPath, { cwd: "/does/not/exist" });
> Error: spawn /usr/local/bin/node ENOENT
    at exports._errnoException (util.js:1028:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:193:32)
    at onErrorNT (internal/child_process.js:359:16)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickDomainCallback (internal/process/next_tick.js:122:9)

This error message is very confusing because it reads like /usr/local/bin/node does not exist. It took me several hours to debug this issue, including serious doubts in my sanity 😁.

Do you think it is feasible to check the cwd before spawning the process, or is there a use-case/is it possible to spawn a process with a non-existent cwd? If it's not feasible, would it be an option to include the cwd in the error message to give a slight hint in the right direction?

Activity

  1. added
    child_processIssues and PRs related to the child_process subsystem.
    feature requestIssues requesting new Node.js features.
    libuvIssues and PRs related to the libuv dependency or the uv binding.
    on Feb 23, 2017
  2. bnoordhuis commented on Feb 23, 2017

    @bnoordhuis
    Member

    That's going to be difficult because the error needs to bubble up from a long way down. I don't think it can be done without backwards-incompatible changes to libuv, which means it won't happen before libuv v2.0.

  3. jhnns commented on Feb 23, 2017

    @jhnns
    ContributorAuthor

    That's going to be difficult because the error needs to bubble up from a long way down

    This means that checking the cwd beforehand (with fs.exists for instance) is not an option?

  4. bnoordhuis commented on Feb 23, 2017

    @bnoordhuis
    Member

    No, that's prone to race conditions (TOCTOU issues.) It's going to work alright 99% of the time and that might be acceptable for an npm module but requirements for node.js core are more stringent.

  5. XadillaX commented on Jul 23, 2017

    @XadillaX
    Contributor

    How about add an option checkCWD?

    something like:

    .spawn(path, { cwd: "some/cwd", checkCWD: true });
  6. bnoordhuis commented on Jul 23, 2017

    @bnoordhuis
    Member

    Check-before-use is an anti-pattern. It's not something to codify in the API.

  7. bnoordhuis commented on Jul 23, 2017

    @bnoordhuis
    Member

    @mrpeu Probably because you use ~ in the file path. No shell expansion is done.

  8. gibfahn commented on Jul 24, 2017

    @gibfahn
    Member

    Check-before-use is an anti-pattern.

    @bnoordhuis why is that?

  9. bnoordhuis commented on Jul 24, 2017

    @bnoordhuis
    Member

    @gibfahn Because it's vulnerable to race conditions: there is a time window between the check and the use where the resource can change or disappear. Every TOCTOU bug ever is a variation on that theme.

    @mrpeu No problem, hope it's working for you now.

  10. gireeshpunathil commented on May 20, 2018

    @gireeshpunathil
    Member

    Doesn't the current code follow TOCTOU? (though the window between TOC and TOU is narrow)

    Given the error is captured right and only issue is with the error message, how about making this explicit in the doc?

  11. RikkiGibson commented on Oct 2, 2018

    @RikkiGibson

    Could you do a check after the fact simply for the purpose of giving a better error message? i.e. if you get an ENOENT, check if the cwd exists, if not then give an error message specific to that. In the worst case you provide a wrong error message, but not a wrong program behavior.

  12. ctday commented on May 8, 2019

    @ctday

    Still happening to me. Is there at least a manual way to work around this? Ubuntu on armv7.

  13. sam-github commented on May 8, 2019

    @sam-github
    Contributor

    @ctday You can check after the fact whether it is the cwd or the node executable that is ENOENT (use fs.stat()).

  14. ctday commented on May 8, 2019

    @ctday

    Ok, thanks.

  15. github-actions commented on Feb 28, 2022

    @github-actions
    Contributor

    There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

    For more information on how the project manages feature requests, please consult the feature request management document.

  16. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Feb 28, 2022
  17. github-actions commented on Apr 4, 2022

    @github-actions
    Contributor

    There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

    For more information on how the project manages feature requests, please consult the feature request management document.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    child_processIssues and PRs related to the child_process subsystem.feature requestIssues requesting new Node.js features.libuvIssues and PRs related to the libuv dependency or the uv binding.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions