Cela s'est avéré être un cas de ne pas être prudent lorsque vous travaillez en tant que root .
J'avais recherché si SQLCLR sur Linux aurait accès au fichier app.Config comme il le fait dans Windows (malheureusement, ce n'est pas le cas :SQL Server 2017 sur Linux ignore le fichier de configuration de l'application s'il existe, ou parfois se verrouille s'il n'existe pas 't (SQLCLR) ) et dans certaines circonstances, SQL Server se verrouillerait complètement. Lorsque cela s'est produit, la seule façon de l'arrêter était de faire un kill -9 le sqlservr . Une des fois où j'ai redémarré le service, je l'ai fait en exécutant directement /opt/mssql/bin/sqlservr et pendant que je travaillais en tant que root (par conséquent, le processus lui-même appartenait à root ).
Il n'y a pas eu d'erreurs immédiates ou de comportement étrange résultant de l'exécution de sqlservr comme root , MAIS lorsque la machine virtuelle a redémarré et que SQL Server a tenté de démarrer correctement (c'est-à-dire en s'exécutant en tant que mssql utilisateur), c'est à ce moment-là qu'il s'est bloqué au tout début.
J'ai trouvé que c'était une conséquence directe de l'exécution de sqlservr comme root était que le /var/opt/mssql/log/errorlog le fichier (et quelques autres créés au démarrage de SQL Server) appartenaient à root (a du sens).
Et, une conséquence directe du fait que ces fichiers appartiennent à root est que lorsque le processus est démarré correctement (comme mssql ), puis le mssql l'utilisateur n'a pas la permission de renommer le fichier pour qu'il se termine par .1 (et tout ce qui doit se passer avec d'autres fichiers, tels que la trace par défaut, etc.). Cependant, plutôt que d'obtenir une erreur d'autorisation, il se bloque pour toujours.
Le correctif principal consiste simplement à exécuter ce qui suit en tant que root (Je n'ai pas essayé de l'exécuter en tant que mssql ). Pour les deux commandes suivantes, sudo n'est nécessaire que lorsqu'il n'agit pas actuellement en tant que root car il exécutera la commande qui le suit as root (ou un autre utilisateur si vous spécifiez -u username ), après avoir été invité à entrer le root mot de passe.
sudo chown -R mssql:mssql /var/opt/mssql
Le correctif secondaire (pour s'assurer que cela ne se reproduise plus), est de démarrer SQL Server correctement;-) :
sudo systemctl start mssql-server