SQL Server 2017 Container Crashes on Startup with SIGABRT

[raschmitt]

Description

I have been using the mcr.microsoft.com/mssql/server:2017-latest image in a Docker container without issues. However, recently, the container fails to start and crashes with a SIGABRT error. The same setup works fine with the 2022-latest tag.

Reproduction Steps

1. Run the following docker-compose.yml:

volumes:
    sql-server:

services:     
    sql-server:
        image: "mcr.microsoft.com/mssql/server:2017-latest"
        container_name: sql-server
        environment:
            - ACCEPT_EULA=Y
            - MSSQL_SA_PASSWORD=sa@@2017
        healthcheck:
            test: /opt/mssql-tools/bin/sqlcmd -U sa -P $$MSSQL_SA_PASSWORD -Q "SELECT 1"
        ports:
            - 1433:1433
        volumes: 
            - sql-server:/var/opt/mssql

2. Start the container with:

   docker compose up
   

3. The container crashes with the following error:

Error Logs

sql-server  | SQL Server 2017 will run as non-root by default.
sql-server  | This container is running as user root.
sql-server  | This program has encountered a fatal error and cannot continue running at Mon Feb 17 21:23:58 2025
sql-server  | The following diagnostic information is available:
sql-server  | 
sql-server  |          Reason: 0x00000001
sql-server  |          Signal: SIGABRT - Aborted (6)
sql-server  | ...
sql-server  | Distribution: Ubuntu 18.04.6 LTS
sql-server  | Last errno text: No such file or directory
sql-server  | /usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory
sql-server exited with code 1

Environment Details

• Host OS: Ubuntu 24.04
• Docker version: 27.3.1
• SQL Server image version: mcr.microsoft.com/mssql/server:2017-latest

Additional Information

• SQL Server 2022 (mcr.microsoft.com/mssql/server:2022-latest) works fine with the same setup, with the only change being the health check command using mssql-tools18 instead of mssql-tools.
• This issue started recently, but I am unsure of the exact point when it broke.
• The logs mention a missing file (/bin/journalctl), which might indicate a missing dependency in the latest version of the image.

Expected Behavior

SQL Server 2017 should start successfully and be accessible via port 1433.

Questions/Requests

1. Has there been a recent change in the 2017-latest image that could cause this issue?
2. Is this an issue with dependencies missing in the latest image?
3. Are there any workarounds or recommended fixes?

Thank you for your support!

[raschmitt]

Seems to be related with this other issue #881

[csaba-kovacs]

Same issue happens here with 2017:latest, i spent countless hours trying to debug this but with no luck.