Giters

nrwl / nx

Smart Monorepos · Fast CI

Home Page:https://nx.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

tasks-runner component doesn't validate sock path

vergilfromadyen opened this issue · comments

commented

Current Behavior

  • Setting NX_DAEMON_SOCKET_DIR to a path longer than 108 characters leads to an EADDRINUSE error
  • This can be triggered accidentally if a CI process sets TMPDIR for its own purposes

Expected Behavior

  • NX throws an error that explains the sock path is too long

Steps to Reproduce

  1. Set NX_DAEMON_SOCKET_DIR to something long, e.g. /tmp/xxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxxx-xxxxxxxxxxxxxxx-xxxxxxxxxxxxxx-xxxxxxxxxxx
  2. Run any NX task

Operating System

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

Additional Information

Linux has a 108-char path limit, Windows has a MAX_PATH constant which is 256ish characters.

Extracted from this issue and addresses a subset of the problems in there.

Fix should be placed around here.

commented

Hey @vergilfromadyen thanks for the report and the detailed investigation. It seems reasonable to provide a better experience here... we already fall back to the workspace-folder socket dir if we can't access the socket dir.
Maybe it would be easiest to try again with that folder if we can't open a socket as well.

Otherwise a validation step might work as well though I'll have to research the proper limits.

commented

Thanks @MaxKless for the quick response.

Setting NX_DAEMON_SOCKET_DIR to something generated can exceed the limits and break NX with an error that appears unrelated to NX. So falling back is nice but it's not enough because the OS tmpdir can be overridden so it can end up too long anyway. So this should probably fail with a more descriptive error.

To help your research:

  • MAX_PATH for the Windows API is 260 chars (source) - unless long paths are enabled. To be absolutely sure, process.env.MAX_PATH can be used on Windows
  • For MacOS and Linux it's 108 characters (for sock files only)

Let me know if I can help in any other way.

commented

for sure but if it just fails, you'll have to set the env var anyways right. If both the temp dir and the workspace path are too long, you won't get around setting it manually.
So providing a fallback and better error message is probably the best we can do here. Unless you have another idea?

commented

When throwing an error I'd still differentiate between a path potentially too long, and a generic "can't create sock file" message, because the former isn't really common knowledge. Other than that it sounds great.