I am running my tests from inside a docker container . List line in Dockerfile is
CMD ["nohup","/bin/scripts/run_test.sh","&"]
This causes the docker to terminate with the error as below
2022-09-07 16:13:48,626 - sinit - DEBUG - simple_init.py logger configured
usage: simple_init.py [-h] [-t TIMEOUT] [-v] [-f]
simple_init.py: error: unrecognized arguments: nohup /bin/scripts/run_test.sh &
Putting nohup is necessary for me as this process ends without doing the needful job completely, if I don't put nohup.
The command looks fine to me in general, what might be causing this issue ?
P.S :
As of now I do not have , an ENTRYPOINT , earlier I had same command (without & in the end )configured as ENTRYPOINT , but it does not run the jar inside the container till it performs the desired operation whereas without being contanerized it works as expected , so some where docker is killing the operation earlier than expected.
Related
I am running a jar package within a container by docker. I spot when there is database connect timeout issue or kafka connect issue, the container will fail. However, I will be fine if I print java error log to console or log file. Anyone can clarify the logic to define a container as failed/error, Thanks!
Well there is no such thing as failed/errorneus container. Docker image can have default ENTRYPOIN or CMD which executes as docker container is started but when command ends docker lifecycle ends as well.
I assume you run some server app in docker container which serves forever which makes one think that docker images all run without stopping. Your docker which should always run stops after your app crashes, you can see the details in docker logs if your didn't run it with --rm option. Try docker ps -a to see your container with exited status and see execution logs or extract files from it's filesystem to debug what went wrong.
To the extent Docker has this concept at all, it follows normal Unix semantics. The container runs a single process, and when that process exits, the container exits too. If the process exits with a status code of 0 it is "successful" and if it exits with any other status code it "fails".
In the context of a Java container, Is there a complete List of JVM exit codes asserts that a JVM will always exit with status code 0 ("success") even if the program terminates with an uncaught exception; it will only return "failure" if the JVM itself fails in some way.
The most significant place this can matter is around a restart policy. If you start your container with docker run --restart on-failure, an uncaught exception won't be considered "failure" and your container won't restart.
I'm using WSL2 on Windows 10 using an Ubuntu image, and Docker for Desktop Windows (2.2.2.0) with the WSL integration.
I have a Rust TCP server. When I run it with cargo run (or the binary after cargo install), it does the right thing, and I can send Ctrl-C to it to terminate. I don't do any explicit signal handling in the code.
I turned it into a Docker image. Here's the Dockerfile.
FROM rust:1.40 as builder
COPY . .
RUN cargo install --path . --root .
FROM debian:buster-slim
COPY --from=builder ./bin/myserver ./myserver
EXPOSE 8080
ENTRYPOINT ["./myserver"]
I then do:
docker build -t myserver .
docker run -it --rm -p 8080:8080 myserver
Attempting to Ctrl-C the process shows the ^C character in the terminal, but the signal doesn't seem to reach the process. I have to use docker kill. I've read other posts like this and this. It suggests that a combination of -it and using the array parameter version of ENTRYPOINT or CMD should allow the signal to reach it, however these don't seem to be helping me.
To see if it was something to do with my setup (Docker for Desktop, WSL, etc.) or my Dockerfile, I followed the README for docker-http-https-echo, and I'm able to Ctrl-C the process. Inspecting the Dockerfile doesn't show that it's doing anything different than me, but clearly I'm missing something.
The reason for your problem is that the kernel treats a process with PID 1 specially, and does not, by default, kill the process when receiving the SIGTERM or SIGINT signals.
You have two options:
Add --init flag to docker run command. By that a special process with PID 1 will be created, which will be a parent for your process and will proxy all signals and properly reap your processes.
Add explicit signal handling to your app, which is good if you want to do graceful shutdown.
The good practice is to combine both methods.
I hope not being late, Nikscorp provides one of the possible reasons why your container could be no stopping, but this could happen in other cases like below:
Your ENTRYPOINT is a sheel script and you are not using Exec: usually, when you run your container from a shell script, your container runs on a new process causing your container won't receive any signals, this can be solved using the exec command
Don't use Pipeline in your Exec entrypoint: in some cases this can generate your application run in a subshell, which causes the no signals (SIGINT, SIGTERM, SIGKILL)
Using an incorrect form of Entrypoint: the Entrypoint Form recommended is the exec form, like this one (This happened to me and solved my problem)
ENTRYPOINT ["/app/bin/your-app", "arg1", "arg2"]
I based my answer on this post and this one
I need to know how to bubble up / handle errors on docker containers to a jenkins in the host machine, what is the best approach?
I can do it only using docker or i need use docker-compose?
How I can tell to docker to throw a failed exit code if the code running inside of it fail?
Example:
I want to run in jenkins a docker image that run a script with nodeJs.
If this script fail with exit code 1 I need that Jenkins fail the build.
Thanks
Hi with the info about the exit codes in docker and CMD command. I was able to throw up all the errors inside of more than one docker container to jenkins using set -e in a bash script starting my docker containers.
If any container fails with a non zero exit code the script stop the current execution and the exit code is catched by jenkins instead to follow with the next docker container execution.
I've had a similar situation here. I created an Execute Shell at Jenkins Build step and put the following script:
docker exec ${CONTAINER_NAME}
if [[ $? -eq 0 ]]; then
docker stop ${CONTAINER_NAME}
exit 0 # success
else
docker stop ${CONTAINER_NAME}
exit 1 # fail
"$?" reads the exit status of the last command executed. After a function returns, "$?" gives the exit status of the last command executed in the function. This is Bash's way of giving functions a "return value."
Source: https://www.tldp.org/LDP/abs/html/exit-status.html
docker_admin#Ashoka:~$ sudo docker run sqldb
exec format error
Error response from daemon: Cannot start container 4e1b251d50ceda05f7b4dd0d3eebd13a731bab0f9a5ed4486f4303d8b5f5b272: [8] System error: exec format error
I try to run the image it shows this error, but when I run the same image in interactive mode it runs successful.
Do you know why?
This message is produced when the kernel, for whatever reason, doesn't know how to handle the given executable format. It's a problem that's often associated with scripts that don't include a shebang line, or binaries that are incompatible with your system.
Since you're able to run the image interactively, you probably have a badly written script somewhere in your container.
See: https://github.com/moby/moby/issues/10668
Try run command using image TAG, execute docker images and get your TAG.
sudo docker run sqldb:1.0
Maybe you need any initial command too
I have had this problem just now, in an Alpine 3.5 container running in a Mint 18 host. It's not a very helpful error, and as far as I can tell there is no feature to inspect logs unless the container keeps on running.
The problem was this line in my Dockerfile:
ENTRYPOINT ["sleep 500"]
I'm using sleep at present so I can shell into the container and install a few things experimentally before committing it to the Dockerfile. In fact this would have happened if I had tried to put any command with parameters into a single ENTRYPOINT entry. It should have been:
ENTRYPOINT ["sleep", "500"]
I am using dockerfiles to build a simple container. Here is the Dockerfile:
FROM XXXXXXX:5003/base-java
MAINTAINER XXXXX
ADD pubsub/ /opt/pubsub/
CMD ["/opt/pubsub/run.sh"]
Content of run.sh is as follows:
#!/bin/bash
nohup java -jar /opt/pubsub/publish.jar &
nohup java -jar /opt/pubsub/subscribe.jar &
This is simple java application for pub/sub.
Now I have got another container running rabbitmq and I am linking the 2 containers however each of my attempt has just failed and My pub/sub container does not start. Can someone advice how to go about debuggin this issue? Somehow docker logs does not have anything.
Here is how I am linking the containers: sudo docker run -d -P --name pub_sub --link rabbitmq:rabbitmq1 image_pub_sub
And here is how I am using the alias name in my pub/sub code
factory = new ConnectionFactory();
factory.setHost("rabbitmq1");
try { connection = factory.newConnection();
channel = connection.createChannel();
channel.queueDeclare("pub", true, false, false, null);
}
catch (IOException e) { // TODO Auto-generated catch block
e.printStackTrace(); }
I was expecting that my publish code will create a queue in the rabbitmq container and start pushing messages. My subscriber code will basically connect to the same rabbitmq and start reading the messages.
When I run the command nothing happens it just prints a long id of the new container and exits..When I run sudo docker ps -a, I can see the following:
e8a50d5aefa5 image_pub_sub:latest "/opt/pubsub/run.sh" 32 minutes ago Exited (0) 32 minutes ago pub_sub
So this means my container is not running.
Just now I tested by updating the /etc/hosts by launching a new container using the following command: sudo docker run -i -t image_pub_sub /bin/bash. Modified the /etc/hosts of this new container and added the following entry <IP_ADDRESS> rabbitmq1 and ran my script /opt/pubsub/run.sh and it appends the nohup file with the following messages:
Message Sent
[x] Received 'Hello'
Message Sent
Message Sent
[x] Received 'Hello'
A Docker container will stop when its main process completes. In your case, this means the two Java applications will be forked to the background (because of the nohup call) then the script will immediately complete and the container will exit.
There are a few solutions:
The quickest and easiest solution is to just remove nohup call from the second java call. That way the script won't exit until the second Java application exits.
Use a process manager such as runit or supervisord to manage the processes.
Put the jars in separate containers and call Java directly (this would seem to be the best solution to me).
can use tail -f /dev/null or tail your log