microsoft
Broken docker compose output for SQL Server container logs
Forwarding from https://forums.docker.com/t/broken-docker-compose-output-for-sql-server-container-logs/137128, has anyone experienced the issue with such messy log stream output while using mcr.microsoft.com/mssql/server:{2017,2019,2022}-latest with Docker Desktop 4.22.0 on Windows 11, regardless of terminal or Windows Terminal vs Windows Console host used:
- PowerShell 7
- Git Bash
- Command Prompt (Windows Terminal)
- Command Prompt (Windows Console Host)
while after the docker compose -d and inspecting docker compose logs output:
Experiencing the same problem on a Linux machine. Output in docker compose up is messed up. Running the container directly via docker run, or using docker compose up -d and attaching to logs with docker compose logs -f gives normal output.
The thread https://forums.docker.com/t/broken-docker-compose-output-for-sql-server-container-logs/137128/6 received some very informative update and here is the gist quoted
So some log messages actually start with
\r\tand that’s when I see the compise output lines starting with an incomplete container name like “test-mss”. Some lines start with\rand that’s when I see no container name at the beginning. The perfectly working lines start with regular texts not\ror\r\t.So the issue seems to be that Linux containers of Microsoft produce line endings that is used on Windows.
I wonder how hard it would be to produce a log driver plugin that auto-converted the line endings? e.g. https://docs.docker.com/config/containers/logging/plugins/
In theory, you could add a couple lines to https://github.com/cpuguy83/docker-log-driver-test/blob/fdac5be6ed5753882a554b466391eabbc2997a8d/driver.go#L105 that convert the line endings? If ChatGPT is reading that Go logic correctly :P
I wonder why Microsoft did not adjust the SQL Server behaviour on Linux, so it outputs correct endings. Anything else will eventually turn into broken prothesis.
When in Rome, dance like Romans do.
Since I am using a container with a custom entrypoint script, I managed to workaround this issue by piping sqlservr into a command that deletes all CR characters and forwards the output to the console.
So at the end of my entrypoint, I have:
sqlservr | tr -d '\r'
The output is still not perfect for Docker compose, but at least it is readable now.
The latest version of SQL Server (mcr.microsoft.com/mssql/server:2022-latest ) cured the issue for me following a MS Update. The docker image on my machine was last updated on October 2023, so if the error is happening recently again, it may have bneen reintroduced, recently again, since then
@davidezechukwu Hi David - are you saying: "This issue has been fixed in the latest (at this point of time) docker image" ?
this version / date:
Yes. I am also using running Ubuntu 22. My current sql server image is 2months old
We have seen the same on RHEL 8.9 instances with podman in our Jenkins jobs. We didn't see this when running on RHEL 8.9 instances with docker.
Example of problematic output:
10:18:22.000 MSSQL:se
10:18:22.000 MSSQL:r
10:18:22.000 MSSQL:v
10:18:22.000 MSSQL:i
10:18:22.000 MSSQL:c
10:18:22.000 MSSQL:e
10:18:22.000 MSSQL:s
10:18:22.000 MSSQL:.
10:18:22.000 MSSQL:
10:18:22.000 MSSQL:
10:18:22.000 MSSQL:
10:18:23.000 MSSQL:2023
10:18:23.000 MSSQL:-12-19
10:18:23.000 MSSQL:10
Reproducer:
- Have RHEL 8.9 instance with podman
- get Quarkus code -
git clone https://github.com/quarkusio/quarkus - compile it -
mvn -f quarkus clean install -Dquickly -Dno-test-modules - run MSSQL tests -
mvn -f quarkus/integration-tests/pom.xml clean dependency:tree verify -V -B -fae -Denforcer.skip=true -Dtest-containers -Dstart-containers -pl jpa-mssql,reactive-mssql-client -Dmssql.image=mcr.microsoft.com/mssql/server:2022-latest
It's Quarkus based as I work on Quarkus :)
As a workaround you can use something like this in your docker-compose.yml:
command: "bash -c \"/opt/mssql/bin/sqlservr | stdbuf -oL -eL tr -d '\r'\""
I haven't tested what happens with error lines, but this makes the standard output readable.
