Ini berakhir sebagai kasus ketidakhati-hatian saat bekerja sebagai root .
Saya telah meneliti apakah SQLCLR di Linux akan memiliki akses ke file app.Config seperti di Windows (sayangnya, tidak:SQL Server 2017 di Linux mengabaikan file konfigurasi aplikasi jika ada, atau terkadang terkunci jika tidak 't (SQLCLR) ) dan dalam keadaan tertentu SQL Server akan terkunci sepenuhnya. Ketika itu terjadi, satu-satunya cara untuk menghentikannya adalah dengan melakukan kill -9 pada sqlservr . Suatu kali saya memulai layanan lagi, saya melakukannya dengan langsung mengeksekusi /opt/mssql/bin/sqlservr dan saat saya bekerja sebagai root (maka proses itu sendiri dimiliki oleh root ).
Tidak ada kesalahan langsung atau perilaku aneh akibat menjalankan sqlservr sebagai root , TETAPI ketika VM dimulai ulang dan SQL Server berusaha untuk memulai dengan benar (yaitu berjalan sebagai mssql pengguna), saat itulah macet di awal.
Saya menemukan bahwa konsekuensi langsung dari menjalankan sqlservr sebagai root apakah itu /var/opt/mssql/log/errorlog file (dan beberapa lainnya yang dibuat saat SQL Server dimulai) dimiliki oleh root (masuk akal).
Dan, konsekuensi langsung dari file-file tersebut dimiliki oleh root adalah ketika proses dimulai dengan benar (seperti mssql ), lalu mssql pengguna tidak memiliki izin untuk mengubah nama file menjadi berakhiran .1 (dan apa pun yang perlu terjadi dengan file lain, seperti jejak default, dll). Namun, alih-alih mendapatkan kesalahan izin, itu malah hang selamanya.
Perbaikan utama adalah menjalankan yang berikut ini sebagai root (Saya belum mencoba menjalankannya sebagai mssql ). Untuk kedua perintah berikut, sudo hanya diperlukan saat tidak bertindak sebagai root karena akan menjalankan perintah yang mengikutinya as root (atau pengguna lain jika Anda menentukan -u username ), setelah diminta memasukkan root sandi.
sudo chown -R mssql:mssql /var/opt/mssql
Perbaikan sekunder (untuk memastikan hal ini tidak terjadi lagi), adalah memulai SQL Server dengan benar;-):
sudo systemctl start mssql-server