To skončilo jako případ, kdy jste nebyli opatrní při práci jako root .
Zkoumal jsem, zda SQLCLR na Linuxu bude mít přístup k souboru app.Config jako ve Windows (bohužel ne:SQL Server 2017 na Linuxu ignoruje konfigurační soubor aplikace, pokud existuje, nebo se někdy zablokuje, pokud ano 't (SQLCLR) ) a za určitých okolností by se SQL Server zcela zablokoval. Když se to stalo, jediný způsob, jak to zastavit, bylo udělat kill -9 dne sqlservr . Jednou z případů, kdy jsem službu znovu spouštěl, jsem tak učinil přímým spuštěním /opt/mssql/bin/sqlservr a když jsem pracoval jako root (proto samotný proces vlastnil root ).
Při spuštění sqlservr nedošlo k žádným okamžitým chybám nebo zvláštnímu chování jako root , ALE když se VM restartoval a SQL Server se pokusil správně spustit (tj. běží jako mssql uživatel), tehdy se zasekl na samém začátku.
Zjistil jsem, že je to přímý důsledek spuštění sqlservr jako root bylo to /var/opt/mssql/log/errorlog (a některé další, které jsou vytvořeny při spuštění SQL Serveru) byly vlastněny root (dává smysl).
A přímý důsledek toho, že tyto soubory jsou vlastněny root je, že když je proces spuštěn správně (jako mssql ), pak mssql uživatel nemá oprávnění přejmenovat soubor tak, aby končil na .1 (a cokoli dalšího se musí stát s jinými soubory, jako je výchozí trasování atd.). Místo toho, aby se zobrazila chyba oprávnění, prostě zůstane navždy.
Primární opravou je jednoduše spustit následující jako root (Nezkoušel jsem to spustit jako mssql ). Pro oba následující příkazy sudo je potřeba pouze v případě, že aktuálně nevystupuje jako root protože spustí příkaz, který za ním následuje jako root (nebo jiný uživatel, pokud zadáte -u username ), poté, co budete vyzváni k zadání root heslo.
sudo chown -R mssql:mssql /var/opt/mssql
Sekundární oprava (aby se to už neopakovalo) je správně spustit SQL Server;-):
sudo systemctl start mssql-server