and run by docker run -p 22000:22000 -v /var/log/gtaconnected/:/var/log/gtaconnected/ -v /etc/gtaconnected/:/etc/gtaconnected/ gtaconnected
So the result I wish is make a GTAConnected server in docker, which will be listened at 22000 port, where would be able to change content of /opt/gtaconnected/resources/, /etc/gtaconnected/server.xml on host machine and get logs from container to /var/log/gtaconnected/.
The result I get for now is
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e19e96896425 gtaconnected "/opt/gtaconnected/S…" 3 seconds ago Exited (135) 1 second ago cool_buck
I don’t know gtaconnected, so my responses will be guesses at best.
First of all, we need logs of the exited container in hope they shed some light on why the container terminated.
An oberservation that hits the eye:
The expose instruction in your Dockerfile and the published port use different protocols. The EXPOSE instruction uses udp, the port mapping in your docke run command maps tcp ports. If you want to map udp you need to use -p 22000:22000/udp instead.
Build it, run it, modify it according your needs, repeat until you are statisfied with the result.
Note: instead of adding your modified server.xml to the Dockerfile, you can mount it when running the container with - v /local/path/server.xml:/opt//opt/gtaconnected/server.xml.
If I have to guess, I would say that your log messages are not sent to the standard error and standard output streams at all. You added a folder called “logs” to the image, and the server probably saves logs there. Then mounted the folder from your host into the container, so you should see the logs on your host. If you can’t find anything there, then it is possible that the server doesn’t have permission to save any logs, and maybe this is the reason why it stops.
So you need to make sure the folder you created on the host for logs is writable by the server.
Since I don’t see any USER instruction, this should not be the problem, but I can’t say it for sure.
Since the file is a binary, we don’t know why it stops if we can’t see any error message. Try to run a debian container:
docker run --rm -it debian bash
and install the erver manually inside the container. If it works, you can start to work on the Docker image and you at least know that it is possible to run on the system you are trying. If it doesn’t work, then it might not be a Docker related problem, however I can guess an other and say that you might need more privileges to communicate with the kernel. You could try privileged containers, but without knowing this software I don’t recommend it.
An other reason could be that the server is built for a different architecture, which @meyay has already pointed out.
When I wrote the Dockerfile PoC I saw that the process creates console output on stdout/stderr. Additionaly I used a symlink so that the default log location writes to /dev/stdout to capture those logs as well.
There is nothing to be sorry about @nachonic never seem to have gotten so far that the process actualy created logs, and I didn’t mention before that the process writes to stdout/stderr as well.