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
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
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.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →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.
#1 Best Overall
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.
-
Locate both possible commands:
command -v node command -v nodejsA result such as
/usr/bin/nodeor/home/deploy/.nvm/versions/node/v20.*/bin/nodeis 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. -
Check the version returned by each command that exists:
node --version nodejs --versionRecord 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.
-
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 bypm2 list. -
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. -
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.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →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.
Recommended Free Tools
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.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteUse 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.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhy 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.
Rank #4
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.
Verify the correction before relying on it
-
Confirm the selected binary can execute directly:
/absolute/path/to/node --version -
Start or restart the app with the updated ecosystem configuration:
pm2 start ecosystem.config.js pm2 restart my-app -
Check status and metadata:
pm2 list pm2 describe my-appThe process should be online, and its metadata should show the intended interpreter or at least no missing-interpreter error.
-
Read startup and application output:
pm2 logs my-appConfirm 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.
-
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.
Best Value
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.
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.
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.
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.
Quick Recap
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.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors

