Questo finì per non essere stato attento quando si lavorava come root .
Stavo cercando se SQLCLR su Linux avrebbe avuto accesso al file app.Config come fa in Windows (purtroppo non lo fa:SQL Server 2017 su Linux ignora il file di configurazione dell'app se esiste, o talvolta si blocca se non lo fa 't (SQLCLR) ) e in determinate circostanze SQL Server si bloccherebbe completamente. Quando ciò accadeva, l'unico modo per fermarlo era fare un kill -9 il sqlservr . Una delle volte che stavo riavviando il servizio, l'ho fatto eseguendo direttamente /opt/mssql/bin/sqlservr e mentre lavoravo come root (quindi il processo stesso era di proprietà di root ).
Non ci sono stati errori immediati o comportamenti strani risultanti dall'esecuzione di sqlservr come root , MA quando la VM è stata riavviata e SQL Server ha tentato di avviarsi correttamente (ovvero in esecuzione come mssql user), cioè quando si è bloccato proprio all'inizio.
Ho scoperto che è una conseguenza diretta dell'esecuzione di sqlservr come root era il file /var/opt/mssql/log/errorlog file (e alcuni altri creati all'avvio di SQL Server) erano di proprietà di root (ha senso).
E, una conseguenza diretta del fatto che quei file sono di proprietà di root è che quando il processo viene avviato correttamente (come mssql ), quindi mssql l'utente non dispone dell'autorizzazione per rinominare il file in modo che termini con .1 (e qualsiasi altra cosa debba accadere con qualsiasi altro file, come la traccia predefinita, ecc.). Tuttavia, invece di ricevere un errore di autorizzazione, si blocca per sempre.
La soluzione principale consiste nell'eseguire semplicemente quanto segue come root (Non ho provato a eseguirlo come mssql ). Per entrambi i seguenti comandi, sudo è necessario solo quando attualmente non agisce come root poiché eseguirà il comando che lo segue as root (o qualche altro utente se specifichi -u username ), dopo che ti è stato chiesto di inserire il root password.
sudo chown -R mssql:mssql /var/opt/mssql
La correzione secondaria (per assicurarsi che ciò non accada di nuovo) è avviare correttamente SQL Server;-):
sudo systemctl start mssql-server