web-dev-qa-db-ja.com

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

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

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

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つのエントリが返されます。

また、errorlogファイルが/ var/opt/mssql/log /VM=（またはサービスを再起動）を開始したときにタイムスタンプが一致していません。また、そのファイルに新しいエントリはありません。

さらに、/ var/log/messagesでは、次のように表示されます。

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

systemctl status mssql-serverの場合、次のようになります。

●mssql-server.service-Microsoft SQL Serverデータベースエンジン
ロード済み：ロード済み（/lib/systemd/system/mssql-server.service; enabled; vendor preset：enabled）
アクティブ：2017年9月4日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（コード=終了、ステータス= 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'.
sql-serverlinuxerrors
11
Solomon Rutzky

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

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

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

sqlservrをrootとして実行した直接的な結果は、/ var/opt/mssql/log/errorlogファイル（およびSQL Serverの起動時に作成されるその他のファイル）は、rootが所有しています（理にかなっています）。

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

主な修正は、単にrootとして以下を実行することです（私はmssqlとして実行したことはありません）。次の両方のコマンドで、Sudoは、現在rootとして機能していない場合にのみ必要です。これは、それに続くコマンドを実行するためですasroot（または-u username）、rootパスワードの入力を求められた後。

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

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

Sudo systemctl start mssql-server
15
Solomon Rutzky

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

# 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
1
Evan Carroll