Logs do not seems to be written to a log file

[pawlakm]

Version

latest tag (digest c19e948b9790)

The issue

The server log file does not seem to be created regardless of passing or not the logfile option as an environment variable. In both cases, when connecting to the container, no log file can be found in /var/log/ nor in /data nor in the directory specified by the environment variable.

Connecting to the container as root and running a "find" does not yield any result.

When passing a MUMBLE_CONFIG_LOGFILE: /data/murmur.log environment variable in my docker-compose.yml file, the variable is correctly set into /data/mumble_server_config.ini however the /data/murmur.log file is never created and as such logs are not written to it.

It is not a volume / access rights issue (for instance the db file is correctly mounted / created / modified + logging into the container as "mumble" user and executing touch where the logfileshould be located creates the file with no issue, however nothing is written to it later even if the file is created manually.)

it seems that murmur forces itself to foreground mode which logs to the console and not to a file or that something is missing to allow it to write logs.

Tried both with docker-compose up and docker-compose up -d with no difference.

[Krzmbrzl]

it seems that murmur forces itself to foreground mode which logs to the console and not to a file or that something is missing to allow it to write logs.

Aye - that's what is requested from the Dockerfile itself: https://github.com/mumble-voip/mumble-docker/blob/6535e9dfc049c0e033ca50b391e3825f7dd0885d/Dockerfile#L78

I did not remember this preventing a log file from being written but now that you mention this, I think I stumbled upon this before :thinking:

I actually don't quite remember why we start the server in foreground mode here anyway. Presumably to a) Prevent the container from exiting right after having started the server and b) Make sure that the log is written to stdout so that you can check on what the server is doing

If it turns out to be impracticable or unnecessary to run in foreground mode, I would not be opposed to removing the -fg parameter and just letting the server run in background mode :eyes:

[azlux]

@Krzmbrzl with docker, you need to keep your program in foreground, this allow docker to follow the run and his state. (for status, restart, starting steps), we should not remove this flag.

The doc say:

-fg Run in the foreground, logging to standard output.

So if mumble isn't capable to copy the ouput into a file in foreground mode, it's not possible to fix this issue.

[Krzmbrzl]

Ah okay, I see. I guess in this case it should probably be considered a bug in the upstream code...

@pawlakm the log should also be found in the servers database (in the slog table) so in the meantime youcoukd access it through that.

[pawlakm]

Thanks for the workaround. Will you create a request in the upstream code ? Or do I have to do it ?

[Krzmbrzl]

Feel free to do it yourself - I'll only forget it xD

[pawlakm]

Done

[pawlakm]

Update:

Just found the docker-file-log-driver logging driver plugin. It can be installed using the following command:

docker plugin install deepcompute/docker-file-log-driver:1.0 --alias file-log-driver

Then when adding this to my docker-compose.yml file at the same level as the image block :

        logging:
            driver: file-log-driver
            options:
                fpath: "/mumble-server/mumble-server.log"

I can access mumble-server logs as a json file located in /var/log/mumble-server/mumble-server.log.

Unlike using docker-compose logs -f <service-name> > logs/mumble-server.logs & which requires a manual execution at each container "up", this approach is fully automatic. The logs are a bit verbose, but it does the job.

[pawlakm]

IMHO using a logging driver should be the preferred approach for retrieving the logs. However this means that MUMBLE_CONFIG_LOGFILE will never be used and people should be aware of that. Mounting a volume for the logs is also useless then.

What do you think ?

[Krzmbrzl]

Sounds good to me, but I am also not very experienced in the Docker business. @azlux what's your take on this?

[azlux]

You can use a logging driver for a specific service into the docker-compose. This will allow you to only save mumbler-server log.

I think the bug on the upstream is valid too. At least, mumble should warn the log will not be write because of foreground flag. Other product like nginx allow you to log into a file AND having the error into the console during foreground run.

[StrangePeanut]

Please don't change this behaviour. This is how most apps work when not allowed to daemonise/fork (ie -fg). Experienced users expect things to work this way. People should do things right and use one of the Docker logging drivers to suit their needs, https://docs.docker.com/config/containers/logging/configure/

[Krzmbrzl]

Alright, then I guess everything is working as intended and if anything, this would be a bug report against the upstream repo.

[albotroz]

I searched around to find the SuperUser password after setting up the Mumble server (Docker). Searched and searched the log. Nowhere was one created. Although I explicitly mentioned this in mumble-server.ini.

This "problem" is or was not mentioned anywhere. In no doc or tutorial. I just found this by chance.

[Krzmbrzl]

mentioned this in mumble-server.ini.

That's not possible. For the Docker image you have to specify it via a variable as documented in the README of the Docker repo.