Question tailing microsoft/mssql-server-linux logs

So, I’m following the pattern of using entrypoint.sh to start and seed the server inside of a docker-compose file. The problem I’m running into is my app resides in a separate container. So, I can’t just run npm start to keep the container alive. I’m wondering if I can do something like this:

/opt/mssql/bin/sqlservr & /app/mssql-import.sh && tail -f <MSSQL_LOGS>

Any insights are much appreciated! Been banging my head on this one for a while. Thanks!

[bzier]

Fix (TL;DR):

Thanks to this comment on issue #4, I discovered that reversing the two commands resolves the issue:

/usr/src/app/import-data.sh & /opt/mssql/bin/sqlservr

My thoughts & speculation:

This allows the script to run and SQL Server to start like before, but the container doesn’t bail out as soon as it finishes the data seeding. Now that the container persists, I can see that PID 1 is /bin/sh -c /bin/bash ./entrypoint.sh

From that, my guess is that with the script the original way, sqlservr is spawned and detached, import-data.sh runs and completes and therefore entrypoint.sh is considered complete. The container sees PID 1 exit and stops as well.

With the commands reversed, import-data.sh is spawned and detached and then sqlservr is invoked, which runs and blocks indefinitely. This causes entrypoint.sh to remain open as PID 1 and the container to live on as expected.

Other tweaks & improvements (?):

Also, I wasn’t confident in that arbitrary sleep command in import-data.sh. I replaced it with the following:

# wait for the SQL Server to come up
until /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -d master -Q "SELECT 1"
do 
    (>&2 echo "Failed to connect to SQL Server; waiting 2 seconds...")
    sleep 2s
    echo "Trying again..."
done
echo "Success! SQL Server is ready."

# run the setup script to create the DB and the schema in the DB
/opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -d master -i setup.sql

This loops attempting to run a SELECT 1 statement against the master database. Initially it gets Login timeout expired errors. While I was messing around, I also saw Login failed; invalid SA password (or something like that). If the call is unsuccessful (non-zero exit code), it will wait 2 seconds and try again. Once that call succeeds, we can be relatively sure that the subsequent call to run the setup.sql script will work as well. Feels cleaner than hoping we slept long enough.

Also worth mentioning, since sqlservr requires the SA_PASSWORD environment variable, we should be able to safely use it in the scripts as well, instead of repeatedly hard-coding the password.

@twright-msft, if you’d like to see any of these tweaks as a PR, let me know (specifically the change for the loop wait and the password variable). Obviously, the first part in reversing the commands isn’t relevant to the node demo app, but certainly helpful to know for those of us attempting to use this idea in other ways.

[jaredmeakin]

@bzier that seems to do the trick. Thanks! What I was doing as a workaround was this:

/opt/mssql/bin/sqlservr & /app/mssql-import.sh && tail -f /dev/null

I also ended up with a similar check using sqlcmd for determining when to seed the database, but it hadn’t occurred to me to use to determine its availability—nice one!

At this point, I think the original intent of my inquiry has been satisfied. I’ll go ahead and close this issue out. Thanks, @bzier & @twright-msft !