@cassini is on the right track, but I don’t think you’ve given enough information for us to track down exactly what the problem is. There’s clearly something wrong with the way node.js has been installed from the Ubuntu repository. In fact, I would recommend not using the Ubuntu repository at all to install node.js — it usually serves pretty old versions of packages and the whole node/nodejs package naming problem is pretty confusing. Neither of these comments are intended as knocks against Ubuntu: they serve old packages because they try to serve stable packages, and the naming problem arises because of problems out of their control.
A better solution than using the Ubuntu repository, in my opinion, is to use one of the official node images from the Docker repository. If you check out that link, you’ll see they have a wide variety of versions and operating systems available. You could rewrite your Dockerfile to look something like this:
# the Debian wheezy image with node 8.5.0 installed
FROM node:8.5.0-wheezy
# looks like you have a typo here... changed /usr/scr/app to /usr/src/app
WORKDIR /usr/src/app
COPY package.json package-lock.json /usr/src/app/
COPY . .
EXPOSE 8080
CMD ["npm", "start"]
As an aside… the Alpine linux images are nice if you want a small image. The Ubuntu image is going to be several hundred megabytes in size while the Alpine image will be significantly smaller. The downside is that it’s not Debian based so there are a few quirks that you’ll have to get used to.
If, however, you really want to go ahead with your own Ubuntu-based image with node.js I would first look at installing node.js directly from the source. This will involve downloading via wget/curl in your Dockerfile, unpacking it, and ensuring it’s installed in the right place.
If you really want to use Ubuntu and the version from the repository, then you need to figure out what’s wrong with the image you built. That means diving into a container running this image & finding the node binary.
To get shell access to the container:
docker run -it --rm <image name or hash> /bin/bash
Once you run this command on your host, you will be presented with a new bash shell prompt. Congratulations! You now have shell access to a temporary container based on your image. Now you need to poke around and see if you can run or find that binary.
Try node --version or nodejs --version to see if you have it installed. If that works, try which node or which nodejs to find the path to the binary.
If you can find the binary, you can edit your Dockerfile to include a link from somewhere in your path to that binary. For example, assuming which nodejs gives you /usr/bin/nodejs, you can use the link suggested by @cassini in your Dockerfile:
RUN ln -s /usr/bin/nodejs /usr/bin/node
@cassini is on the right track, but I don’t think you’ve given enough information for us to track down exactly what the problem is. There’s clearly something wrong with the way node.js has been installed from the Ubuntu repository. In fact, I would recommend not using the Ubuntu repository at all to install node.js — it usually serves pretty old versions of packages and the whole node/nodejs package naming problem is pretty confusing. Neither of these comments are intended as knocks against Ubuntu: they serve old packages because they try to serve stable packages, and the naming problem arises because of problems out of their control.
A better solution than using the Ubuntu repository, in my opinion, is to use one of the official node images from the Docker repository. If you check out that link, you’ll see they have a wide variety of versions and operating systems available. You could rewrite your Dockerfile to look something like this:
# the Debian wheezy image with node 8.5.0 installed
FROM node:8.5.0-wheezy
# looks like you have a typo here... changed /usr/scr/app to /usr/src/app
WORKDIR /usr/src/app
COPY package.json package-lock.json /usr/src/app/
COPY . .
EXPOSE 8080
CMD ["npm", "start"]
As an aside… the Alpine linux images are nice if you want a small image. The Ubuntu image is going to be several hundred megabytes in size while the Alpine image will be significantly smaller. The downside is that it’s not Debian based so there are a few quirks that you’ll have to get used to.
If, however, you really want to go ahead with your own Ubuntu-based image with node.js I would first look at installing node.js directly from the source. This will involve downloading via wget/curl in your Dockerfile, unpacking it, and ensuring it’s installed in the right place.
If you really want to use Ubuntu and the version from the repository, then you need to figure out what’s wrong with the image you built. That means diving into a container running this image & finding the node binary.
To get shell access to the container:
docker run -it --rm <image name or hash> /bin/bash
Once you run this command on your host, you will be presented with a new bash shell prompt. Congratulations! You now have shell access to a temporary container based on your image. Now you need to poke around and see if you can run or find that binary.
Try node --version or nodejs --version to see if you have it installed. If that works, try which node or which nodejs to find the path to the binary.
If you can find the binary, you can edit your Dockerfile to include a link from somewhere in your path to that binary. For example, assuming which nodejs gives you /usr/bin/nodejs, you can use the link suggested by @cassini in your Dockerfile:
RUN ln -s /usr/bin/nodejs /usr/bin/node
A great feature of VS Code is the ability to connect to remote systems, and run code directly on them.
There are many advantages to doing this. You no longer need to worry about library version compatibility, as you’re running on the target system. Database connections can remain limited to localhost. And you no longer have to load a single system with all of your dev libraries.
You can enable this feature by installing the appropriate plugins – which are developed by Microsoft themselves.
Unfortunately, a recent attempt to get this set up didn’t go to plan.
Node Not Found
Setting up VS Code Remote is designed to be simple. In this case, I was using the SSH Remote option, but there’s also an option for connecting to docker instances.
Once you’ve connected to the remote server, VS Code downloads software that runs on the client, which it uses to deploy the code you’re testing.
Setting this up on a Pi 4, I came across a the following error message.
Looking through the message log, I found this.
[14:43:38.053] > Server did not start successfully. Full server log at
/home/user/.vscode-server/.c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5.log >>>
[14:43:38.057] > /home/user/.vscode-server/bin/
c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5/bin/code-server: 12:
/home/user/.vscode-server/bin/
c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5/node: not foundThe node executable that runs on the remote server is not found.
A check on the server shows the node file is there.
So what’s the issue?
Incorrect Architecture
It turns out, the issue is a simple one.
This particular Raspberry Pi is running the standard 32-bit version of Raspberry Pi OS. However, for increase database performance, it’s been updated to use the 64-bit kernel. This was achieved by adding
arm_64bit=1to /boot/config.txt.
This alters the output of uname -m, to reflect that a 64-bit kernel is running.
$ uname -m
aarch64Running the 64-bit kernel is enough to trigger VS Code to install a 64-bit version of the remote server application.
Unfortunate, as the userspace is still 32-bit, the application will not run. The OS doesn’t even recognise the 64-bit node application as an executable, hence the slightly misleading not found message.
An Easy Fix
Working around this requires first removing the VS Code data on the remote server. You can do this by running
rm -rf ~/.vscode-serverNext, comment out the arm_64bit=1 line in /boot/config.txt.
#arm_64bit=1Save the file, and reboot the system.
When the system has rebooted, confirm the change by running uname -m again.
$ uname -m
armv7lIf the result is armv7l, try setting up the VS Code remote server again.
[16:35:39.245] Remote server is listening on 41667
[16:35:39.245] Parsed server configuration: {
"serverConfiguration":{
"remoteListeningOn":{"port":41667},
"osReleaseId":"raspbian",
"arch":"armv7l",
"webUiAccessToken":"",
"sshAuthSock":"",
"tmpDir":"/run/user/1001",
"platform":"linux",
"connectionToken":"a1a11111-1111-11a1-111a-11aaa1a11a1a"
},
"downloadTime":4577,
"installTime":8750,
"serverStartTime":918,
"installUnpackCode":"success"
}It should now run correctly. Note the arch is listed in the returned server configuration – which matches the uname -m output.
Once this is complete, you can uncomment the line in /boot/config.txt, and reboot the system, to switch back to the 64-bit kernel.
While this issue was encountered (and fixed) on a Raspberry Pi, it’s possible it will surface in any system using a different kernel and userspace architecture.
我也遇到了同样的问题，我配置了：
http_proxy=socks5://127.0.0.1:23033
https_proxy=socks5://127.0.0.1:23033
[root@cluster2-172-21-48-17 pods]# systemctl show-environment
HOSTNAME=cluster2-172-21-48-17
HTTPS_PROXY=socks5://127.0.0.1:23033
HTTP_PROXY=socks5://127.0.0.1:23033
LANG=en_US.utf8
NO_PROXY=127.0.0.1,localhost,cluster2-172-21-48-17
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
[root@cluster2-172-21-48-17 pods]# systemctl set-environment NO_PROXY=127.0.0.1,localhost,cluster2-172-21-48-17,172.21.48.17 # add a 172.21.48.17
[root@cluster2-172-21-48-17 pods]# systemctl show-environment
HOSTNAME=cluster2-172-21-48-17
HTTPS_PROXY=socks5://127.0.0.1:23033
HTTP_PROXY=socks5://127.0.0.1:23033
LANG=en_US.utf8
NO_PROXY=127.0.0.1,localhost,cluster2-172-21-48-17,172.21.48.17
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
[root@cluster2-172-21-48-17 pods]# systemctl restart containerd
[root@cluster2-172-21-48-17 pods]# kubeadm init --ignore-preflight-errors=all
In this article, we will delve into the common issues of ‘node: command not found’ and ‘npm: command not found’ errors in Ubuntu. These errors can be quite frustrating, especially when you’re trying to set up your Node.js environment. But don’t worry, we’ve got you covered.
- Understanding the Problem
- Solution 1: Creating a Symbolic Link
- Solution 2: Installing the nodejs-legacy Package
- Solution 3: Using Node Version Manager (nvm)
- Solution 4: Reinstalling Node.js
- Checking the System’s PATH
- Conclusion
Understanding the Problem
The errors ‘node: command not found’ and ‘npm: command not found’ typically occur when the system can’t find the Node.js and npm executables in the directories listed in your PATH environment variable. This might be due to incorrect installation, conflict with other packages, or your system’s PATH not being set up correctly.
Solution 1: Creating a Symbolic Link
One of the simplest ways to resolve this issue is by creating a symbolic link from nodejs to node. A symbolic link is essentially a file that points to another file.
To create a symbolic link, open your terminal and run the following command:
ln -s /usr/bin/nodejs /usr/bin/nodeIn this command, ln -s is used to create a symbolic link, /usr/bin/nodejs is the file you want to link to, and /usr/bin/node is the name of the symbolic link.
Solution 2: Installing the nodejs-legacy Package
Another solution is to install the nodejs-legacy package. This package provides the node command for Node.js, resolving any conflicts.
To install nodejs-legacy, use the following command:
sudo apt-get install nodejs-legacyIn this command, sudo is used to run the command with root privileges, apt-get is the package handling utility in Ubuntu, and install is the command to install a package.
Solution 3: Using Node Version Manager (nvm)
If you’re using nvm (Node Version Manager), you might need to use the nvm use command before using npm.
For instance:
nvm use 0.xReplace 0.x with the version of Node.js you want to use. The nvm use command tells nvm which version of Node.js to use.
Solution 4: Reinstalling Node.js
If none of the above solutions work, consider reinstalling Node.js. You can follow the official installation steps from the Node.js website.
Checking the System’s PATH
Remember to check your system’s PATH to ensure that the correct directories are included. You can do this by running the command:
echo $PATHThis command will print the directories in your PATH. Ensure that the directory containing the Node.js and npm executables is included.
Conclusion
In this article, we’ve explored several solutions to the ‘node: command not found’ and ‘npm: command not found’ errors in Ubuntu. These solutions include creating a symbolic link, installing the nodejs-legacy package, using nvm, and reinstalling Node.js. We hope this guide has been helpful in resolving these errors and getting your Node.js environment up and running.
To check if Node.js is installed on your Ubuntu system, open your terminal and run the command node -v. This will display the version of Node.js installed on your system, if it is installed.
To check if npm is installed on your Ubuntu system, open your terminal and run the command npm -v. This will display the version of npm installed on your system, if it is installed.
Creating a symbolic link allows you to create an alias or shortcut to a file or directory. In the case of ‘node: command not found’ and ‘npm: command not found’ errors, creating a symbolic link from nodejs to node allows the system to recognize the node command.
To uninstall Node.js from your Ubuntu system, you can use the package manager apt-get. Open your terminal and run the command sudo apt-get remove nodejs to remove the Node.js package. Additionally, you can also remove any global npm packages by running the command sudo npm uninstall -g <package-name> for each package you want to uninstall.
To update Node.js to the latest version on your Ubuntu system, you can use the package manager apt-get. Open your terminal and run the command sudo apt-get install --only-upgrade nodejs to upgrade the Node.js package to the latest available version.