これは 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/log/errorlog ファイル (および SQL Server の起動時に作成されるその他のファイル) は root が所有していました （理にかなっています）。
そして、これらのファイルが root によって所有されていることの直接的な結果 プロセスが適切に開始されたときです（ mssql など） )、次に mssql ユーザーには、ファイル名を .1 で終わるように変更する権限がありません (そして、デフォルト トレースなど、その他のファイルで発生する必要があるものはすべて)。ただし、権限エラーが発生するのではなく、永遠にハングアップします。
主な修正は、単純に次を root として実行することです ( mssql として実行しようとはしていません ）。次の両方のコマンドの場合、sudo 現在 root として機能していない場合にのみ必要です それに続くコマンドを as 実行するので root (または -u username を指定した場合は他のユーザー )、root の入力を求められた後 パスワード。
sudo chown -R mssql:mssql /var/opt/mssql
二次的な修正 (これが再び起こらないようにするため) は、SQL Server を適切に起動することです;-):
sudo systemctl start mssql-server