Linux上のSQL Serverが初期起動時にハングし、エラーが発生せず、新しい/更新されたErrorLogファイルがない

Linux（Ubuntu 16.04）でSQL Server 2017、Release Candidate 2（RC2）を使用しています。

サーバーが起動すると、通常SQL Serverも起動します。しかし、何らかの理由で、SQL Serverが起動しなくなります。少なくともsqlcmdを使用して接続することはできません。今度は、ODBCタイムアウト（「Sqlcmd：エラー：SQL Server用Microsoft ODBCドライバー13」）エラーが毎回発生します。

Login timeout expired.  
TCP Provider: Error code 0x2749.  
A network-related or instance-specific error has occurred while establishing a
connection to SQL Server. Server is not found or not accessible. Check if instance
name is correct and if SQL Server is configured to allow remote connections.
For more information see SQL Server Books Online..

ただし、実行すると：

ps aux | grep mssql

mssqlユーザーがsqlservrプロセスを実行していることを示す2つのエントリが返されます。

また、エラーログ内のファイルの/ var / opt / MSSQL /ログは/私はVMを開始した（またはサービスを再起動）するときのタイムスタンプマッチングを持っていない、またそのファイル内の任意の新しいエントリがあります。

さらに、/ var / log / messagesに表示されるのは次のとおりです。

これは評価版です。評価期間は残り[141]日です。

を実行するsystemctl status mssql-serverと、次のようになります。

●mssql-server.service-Microsoft SQL Serverデータベースエンジン
ロード済み：ロード済み（/lib/systemd/system/mssql-server.service; enabled;ベンダープリセット：有効）
アクティブ：失敗（結果：exit-code）（Mon 2017以降） 09-04 20:01:56 BST; 36 秒前
ドキュメント：https
://docs.microsoft.com/en-us/sql/linuxプロセス：8009 ExecStart = / opt / mssql / bin / sqlservr（code = exited、status = 255）
メインPID：8009（code =終了、ステータス= 255）

Started Microsoft SQL Server Database Engine.  
This is an evaluation version.  There are [141] days left in the evaluation period.  
Stopping Microsoft SQL Server Database Engine...  
mssql-server.service: Main process exited, code=exited, status=255/n/a  
Stopped Microsoft SQL Server Database Engine.  
mssql-server.service: Unit entered failed state.  
mssql-server.service: Failed with result 'exit-code'.  

これは、として作業する場合に注意を怠った場合に終わりましたroot。

LinuxのSQLCLRがWindowsの場合のようにapp.Configファイルにアクセスできるかどうかを調査していました（残念ながら、そうではありません：Linux上のSQL Server 2017は、存在する場合、アプリ構成ファイルを無視し、場合によってはロックアップします't（SQLCLR））および特定の状況下では、SQL Serverが完全にロックします。それが起こったとき、それを止める唯一の方法はを実行することでしkill -9たsqlservr。サービスを再開したときの1つとして、/ opt / mssql / bin / sqlservr を直接実行することで、サービスを開始しましたroot（そのため、プロセス自体はによって所有されていましたroot）。

sqlservrとして実行したことによる即時のエラーや奇妙な動作はありませんでしrootたが、VMが再起動し、SQL Serverが適切に起動しようとしたとき（つまり、mssqlユーザーとして実行しているとき）、つまり最初から動かなくなったときです。

私は、実行中の直接の結果ことがわかっsqlservrなどがrootいたことの/ var / opt / MSSQL /ログ/エラーログファイル（およびSQL Serverが起動時に作成されているいくつかの他）が所有していたroot（センスますが）。

そして、によって所有されているこれらのファイルの直接の結果は、rootプロセスは（として適切に開始されたときということですmssql）、その後、mssqlユーザが最後にファイル名を変更する権限を持っていない0.1（および他で発生する他のどんなニーズデフォルトのトレースなどのファイル）。ただし、アクセス許可エラーが発生するのではなく、永久にハングします。

主な修正は、次のように実行することですroot（私はとして実行したことはありませんmssql）。次のコマンドの両方のために、sudo現在として機能していない場合にのみ必要とされroot、それを次のコマンドを実行しますようとして root（あなたが指定した場合や他のユーザーを-u username入力するように要求された後、）rootパスワードを。

sudo chown -R  mssql:mssql /var/opt/mssql

二次修正（これが再び起こらないようにするため）は、SQL Serverを適切に起動することです;-)：

sudo systemctl start mssql-server

権限を正しく取得してスマートエラーを取得するには、少なくとも次のものが必要です...

# make sure needed directories exist
sudo mkdir /var/opt/mssql /var/opt/mssql/.system /var/opt/mssql/data /var/opt/mssql/log

# this should be owned by mssql
sudo chown -R  mssql:mssql /var/opt/mssql
sudo chmod 770 /var/opt/mssql

# this should be owned by root
sudo chown -R root:root /opt/mssql