Description
Contact Information
tocker#16iot.cn
1Panel Version
v1.10.21-lts
Problem Description
😮 I created a Node.js runtime to run one of my Node services. I noticed that 1Panel shows the service as running, but I cannot see the service logs from the web logs, nor can I access the service via the external port. I checked the firewall, and unfortunately, it is not blocking the working port of the server. I used the docker ps command in the background to check the pod status, and I found that the pod is already in a running state. Then, I navigated to the corresponding directory /opt/1panel/runtime/node and used docker compose logs -f to check the pod logs, but there was no log output. I used the exec command to enter the pod’s shell and found that the Node service is not running.
🤔 Upon further analysis of the docker-compose.yml, I found that the startup command is sh run.sh, and the variables in run.sh are imported from the .env file.I tried to analyze where it is interrupting by adding markers to the run.sh script.
I found that when run.sh executes npm install, the docker logs do not output anything (the run.sh script also has no output statements). At this point, the Node service has not started, but the Pod status is running.
In this situation, the interface shows 'running,' but the expected service has not actually started.
Image: Attempting to enter the pod shell to check the service status.
Image: About 5 minutes later, the install step completed, and the service started normally.
Steps to Reproduce
Create a Node.js runtime as shown in the image below.
Start the environment after it has been created.
When the Pod is in a running state, access port 10010.
The expected correct result
According to my configuration, I want to access the service using port 3000 inside the container or port 10010 outside the container.
Related log output
no log output.Additional Information
According to the current mechanism, HC targets run.sh. When the earlier steps in run.sh are executed slowly, it delays the execution of subsequent expected steps, creating an illusion for the user.
There is no valid information output in the logs, and users generally only observe the 'service' (actually the Pod) status through the web interface.
Suggestions:
- Adjust the HC mechanism to ensure that the Pod status aligns with the actual service status.
- Add necessary log information to run.sh to inform users of the current status.
I also hope others can discuss better solutions. 😀😀😀