Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

PM2 normally tries to launch JavaScript applications with an executable named node. If your Ubuntu installation only provides nodejs, PM2 can fail even though Node.js works in another context. The reliable fix is to identify the actual Node.js binary and give PM2 its absolute path, then verify the PM2 daemon and boot service use the same executable.

Do not replace /usr/bin/node blindly or rely on a shell alias. Ubuntu’s older package naming had a real conflict involving an unrelated package called node; current releases and installation methods differ, so inspect your system before changing packages or symlinks.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

What PM2 means when it says node

PM2 is not normally asking you to install an application dependency literally named “node.” Its ecosystem configuration defines interpreter as an absolute path and uses node as the default. PM2 also chooses an interpreter from the script’s file extension and allows an explicit --interpreter override. Consequently, a message mentioning node usually identifies the executable PM2 is trying to run.

Ubuntu has used different command names across releases and repositories. On affected historical releases, the Node.js runtime was exposed as nodejs, while node belonged to an unrelated Amateur Packet Radio Node Program package. That is why an old Ubuntu server can have a working nodejs command but no node command. The naming behavior is release-specific; it is not safe to assume that every current Ubuntu installation needs the same package or symlink.

Diagnose the executable PM2 can actually use

Run the checks as the same Linux user that owns the PM2 process list. Running them as root while PM2 runs under a deployment user can produce a completely different PATH, version, and home directory.

  1. Locate both possible commands:

    command -v node
    command -v nodejs

    A result such as /usr/bin/node or /home/deploy/.nvm/versions/node/v20.*/bin/node is the path PM2 may need. A blank result means that command is not available in the current environment.

    Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  2. Check the version returned by each command that exists:

    node --version
    nodejs --version

    Record the exact output. Two commands can both exist while pointing to different Node.js versions, which can explain behavior that appears inconsistent between a shell and PM2.

  3. Capture PM2’s own context:

    pm2 report
    pm2 list
    pm2 describe <app-name>

    These commands show the PM2 installation, daemon state, process metadata, interpreter setting, working directory, and restart history. Replace <app-name> with the name shown by pm2 list.

  4. Read the process error output:

    pm2 logs <app-name>

    Look for messages such as “command not found,” “cannot find interpreter,” permission errors, or a Node.js version-related exception. The wording distinguishes a missing executable from an application crash.

    What’s actually slowing this PC down?

    Pick the symptom - the matching free tool is one click away.

    Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  5. Check the environment in which the PM2 daemon was started. If PM2 was launched by a systemd startup unit, a non-interactive SSH session, or a deployment script, it may not read your interactive shell startup files. A path visible after logging in is therefore not proof that the daemon can resolve it.

Preferred fix: set an absolute interpreter path

Once command -v identifies the Node.js runtime you intend to use, configure that path explicitly. This avoids ambiguity between node, nodejs, multiple installations, and a restricted service PATH.

Set the interpreter in an ecosystem file

Edit your PM2 ecosystem file, commonly named ecosystem.config.js:

module.exports = {
  apps: [{
    name: 'my-app',
    script: './app.js',
    interpreter: '/absolute/path/to/node'
  }]
};

Replace /absolute/path/to/node with the path returned by command -v node or command -v nodejs. Use the path that points to the Node.js runtime you have selected, not merely the first command that happens to exist. For a system installation it may be /usr/bin/nodejs; for a version manager it may be a user-specific path under your home directory.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

An absolute path is auditable: the ecosystem file records exactly which runtime the application uses, and an upgrade can be performed by changing that one setting after testing the new binary.

Apply the file to PM2

Start or restart the application from the updated ecosystem file rather than relying on an old process definition:

pm2 start ecosystem.config.js
pm2 restart ecosystem.config.js

If your ecosystem file contains several applications, restarting the file can affect all of them. To limit the operation, use the application name shown in the file and PM2’s normal named-process commands:

pm2 restart my-app

Afterward, inspect pm2 describe my-app and the logs to confirm that the configured interpreter is the one you intended.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Use a one-off command-line override

For a quick test, bypass the ecosystem file:

pm2 start app.js --interpreter /absolute/path/to/node

This is useful for proving that the binary works before editing deployment configuration. A one-off override does not automatically update an existing process definition or every future deployment, so put the tested path in the ecosystem file when the result is confirmed.

If Ubuntu has nodejs but no node

There are three broad approaches. Choose based on whether you need a system-wide command, whether the method is supported on your Ubuntu release, and whether PM2 must work during boot without an interactive login.

Install Node.js using a maintained method that supplies node

A current Node.js installation method may provide the conventional node executable directly. After installing or changing the runtime, verify both location and version as the PM2 user:

command -v node
node --version

Then point PM2 at that exact path. This approach is usually easier to audit than maintaining a hand-created symlink, because the package or installation manager owns the executable and its upgrades. Confirm that the method supports your Ubuntu release and that its Node.js version meets your application’s requirements.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Use the distribution’s compatibility package only when it exists for that release

Historical Ubuntu guidance used a package named nodejs-legacy to provide a node command for installations where the runtime was named nodejs. That advice applies to older packaging and is not a universal instruction for current Ubuntu. Package availability, repository contents, and conflict handling have changed.

Before installing anything, inspect the release and package candidates with your normal package-management tools. If the compatibility package is available and appropriate, install it through the distribution’s package manager, then verify:

command -v node
node --version

If it is not available, do not force an old package recipe onto a newer system. Configure PM2 with the existing Node.js path or install Node.js through a maintained source instead.

Do not overwrite /usr/bin/node blindly

A manually created symlink can break package ownership, future upgrades, or software that expects the unrelated historical node package. It can also mask the fact that PM2 and your shell are using different Node.js versions. Prefer a package-managed compatibility command or PM2’s explicit absolute interpreter setting. If an administrator does create a system-level link, document who owns it, what target it uses, and how it will be repaired after an upgrade.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Why node works in your shell but PM2 cannot find it

PM2 has a long-running daemon. The daemon inherits the environment available when it starts; it does not dynamically read every later shell change. This is especially important with per-user version managers, which commonly modify PATH in interactive shell startup files.

Shell aliases are not service configuration

An alias such as alias node=nodejs in .bashrc affects an interactive shell only. A PM2 daemon or systemd startup unit generally does not expand that alias. It may therefore report that node is missing even though typing node succeeds after login. Replace the alias-based workaround with an absolute interpreter path or a system-managed command.

Version-manager paths need special care

If command -v node returns a path under a version manager, that path may be readable only by one user and may change when the selected version changes. Set the PM2 interpreter to the intended absolute path and ensure the boot service runs as the same user with permission to execute it. When changing Node.js versions, update the ecosystem configuration deliberately and restart PM2; do not assume that a newly selected shell version automatically reaches the existing daemon.

Inspect the daemon, not just the login shell

Use pm2 report, pm2 list, pm2 describe, and pm2 logs to establish which process definition and interpreter PM2 is using. If the daemon was started under another account, run the PM2 commands as that account or inspect the service definition with administrator access. A process that is online under one user does not prove that the same application will start under the user configured for boot.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Verify the correction before relying on it

  1. Confirm the selected binary can execute directly:

    /absolute/path/to/node --version
  2. Start or restart the app with the updated ecosystem configuration:

    pm2 start ecosystem.config.js
    pm2 restart my-app
  3. Check status and metadata:

    pm2 list
    pm2 describe my-app

    The process should be online, and its metadata should show the intended interpreter or at least no missing-interpreter error.

  4. Read startup and application output:

    pm2 logs my-app

    Confirm that the logs show normal application behavior rather than only a successful process spawn. A valid Node.js executable can still reveal an incompatible application runtime through syntax, dependency, or module errors.

  5. Test from the PM2 service context when possible. If the interactive shell uses a version manager, compare the service user, working directory, PATH, and permissions with the values used during your manual test.

    Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Make the corrected process survive a reboot

PM2’s boot procedure has two separate jobs: pm2 startup generates or displays the command needed to create a startup service, and pm2 save stores the current process list for restoration. Run them only after the interpreter and application have been verified.

pm2 startup
pm2 save

pm2 startup commonly prints a privileged command tailored to your user and operating system. Copy and run the exact command it outputs; do not substitute a generic service command. Then reboot or otherwise test the generated service and inspect the restored process with pm2 list, pm2 describe my-app, and pm2 logs my-app.

If Node.js comes from a per-user version manager, review the generated startup command and service environment. The boot service must run as the account that owns the PM2 process list and must be able to resolve the absolute interpreter path. A path that exists only in an interactive shell will not be made reliable by pm2 save alone.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Compare the available fixes

Approach Changes system-wide command resolution? Ubuntu-release dependence Works reliably for PM2 at boot Version auditing and upgrades
Absolute interpreter in ecosystem file No Low; uses whatever verified binary you select Yes, if the path is readable and executable by the PM2 service user High; the exact runtime path is recorded in configuration
One-off --interpreter override No Low Only for the process definition created with that command; repeat or persist it for future deployments Medium; easy to test, but less centralized
Maintained Node.js installation that provides node Usually yes, through the installer or package manager Depends on the installation method and Ubuntu release Usually, provided the service user can access the installed path High when the package or installer owns upgrades; document the selected version
Historical nodejs-legacy compatibility package Yes High; tied to older Ubuntu packaging Potentially, if the package is installed system-wide and available to the service Lower on current systems because availability and maintenance vary
Shell alias in .bashrc No Low No; non-interactive PM2 services generally do not load aliases Low; behavior is hidden in an interactive shell
Unmanaged manual symlink Yes Varies Only while the link remains valid and accessible Low; package upgrades can overwrite or conflict with it

Common failure modes and recovery steps

PM2 still reports “node not found” after editing the file

The running process may still use an old definition. Stop or restart the named application from the updated ecosystem file, then inspect pm2 describe. If necessary, delete the stale process definition and start it again from the file, taking care not to remove unrelated applications from the PM2 list.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The path works manually but fails after reboot

Check which user owns the startup service, whether that user can traverse every directory in the path, and whether the executable’s permissions allow execution. For a version-manager path, confirm that the selected runtime still exists after an upgrade and that the service points to the intended version rather than a temporary shell shim.

Both node and nodejs exist but versions differ

Do not choose by name alone. Run command -v and both version commands as the PM2 user, then set the ecosystem interpreter to the binary whose version and dependency environment you have tested. Remove ambiguity from deployment scripts by using the same absolute path.

The process starts, then exits immediately

This indicates that PM2 found an interpreter but the application itself failed, for example because of an unsupported Node.js feature, missing dependency, wrong working directory, or configuration error. Use pm2 logs and the application’s own diagnostics. Changing the command name will not fix an application-level exception.

A package installation proposes removing unrelated software

Stop and review the transaction. The historical node naming conflict means that an apparently simple package change can affect an unrelated package. Prefer the explicit interpreter configuration when the existing Node.js runtime is otherwise correct.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

PM2 and Ubuntu version considerations

The current PM2 npm package listing describes PM2 as a process manager for Node.js and Bun applications, states support for Node.js 18 and newer, and shows global installation with npm install pm2 -g. Confirm the PM2 and Node.js versions used by your deployment before applying instructions copied from an older Ubuntu guide.

The durable procedure is version-neutral: identify the executable with command -v, verify its version, configure PM2 with an absolute path when resolution is uncertain, inspect the daemon and logs, and then regenerate the startup configuration and save the verified process list. Historical recipes involving nodejs-legacy, manual symlinks, or package names should be treated as compatibility notes for specific releases rather than universal fixes.

Decision rule

If node already points to the correct runtime, leave the system command alone and set PM2 to that absolute path if the daemon has a different environment. If only nodejs exists, use its verified absolute path in the ecosystem file unless you have a current, supported reason to provide a system-wide node command. After any change, validate the process under the PM2 service user and run pm2 startup followed by pm2 save so a reboot restores the same tested configuration.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.