Issues while creating new docker image

I have the following Dockerfile:

FROM debian:latest
ADD ./Server /opt/gtaconnected/Server
ADD ./ /opt/gtaconnected/
ADD ./resources/ /opt/gtaconnected/resources/
ADD ./logs/ /var/log/gtaconnected/
ADD ./server.xml /etc/gtaconnected/server.xml
EXPOSE 22000/udp
CMD ["/opt/gtaconnected/Server", "-config", "/etc/gtaconnected/server.xml"]

build an image by
docker build -t gtaconnected .

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

The source binaries I use is * Grand Theft Auto Connected Server 1.4.0 Linux

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.

I’ve mentioned now that there’s no difference what protocol to use for game server, so then I deleted the UDP mapping.

How can I see the container logs?
docker logs <container_name>
has not show any output

is also empty

This should be fine with container_name or id.

Here is a Dockerfile I threw together as PoC:

FROM debian:latest
ARG version=1.4.0
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update \
    && apt-get install --assume-yes --no-install-recommends apt-utils curl ca-certificates \
    && mkdir -m 755 -p /opt/gtaconnected \
    && curl${version}.tar.gz -o /tmp/download.tar.gz \
    && tar xzf /tmp/download.tar.gz -C /opt/gtaconnected \
    && rm /opt/gtaconnected/logs/ServerLog.log \
    && ln -s /dev/stdout /opt/gtaconnected/logs/ServerLog.log \
    && apt-get remove --assume-yes --purge apt-utils curl ca-certificates \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* /tmp/download.tar.gz
WORKDIR /opt/gtaconnected
EXPOSE 22000/tcp
CMD ["./Server"]

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.

Good luck!

While running container by your Dockerfile, I got

Segmentation fault (core dumped)

error. What there’d be the reason?

Like I wrote it’s a PoC. The binary it downloads is for x86_64 and it works for me like this. No idea why it doesn’t for you.

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.

Oh I am sorry, I didn’t notice it. Then it is more likely the architecture. I least I don’t have other ideas.

There is nothing to be sorry about :slight_smile: @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.