SQL Server sous Linux se bloque au démarrage initial, aucune erreur et aucun fichier ErrorLog nouveau / mis à jour

J'utilise SQL Server 2017, Release Candidate 2 (RC2) sur Linux (Ubuntu 16.04).

Lorsque le serveur démarre, SQL Server démarre généralement également. Mais pour une raison quelconque, SQL Server ne démarre plus. Au moins, je ne peux pas me connecter à l'aide de sqlcmd . J'obtiens une erreur de délai d'expiration ODBC ( "Sqlcmd: erreur: Microsoft ODBC Driver 13 pour SQL Server ") à chaque fois maintenant:

Login timeout expired.  
TCP Provider: Error code 0x2749.  
A network-related or instance-specific error has occurred while establishing a
connection to SQL Server. Server is not found or not accessible. Check if instance
name is correct and if SQL Server is configured to allow remote connections.
For more information see SQL Server Books Online..

Cependant, lorsque je cours:

ps aux | grep mssql

Je reçois deux entrées retournées montrant que l' mssqlutilisateur exécute le sqlservrprocessus.

En outre, le fichier journal des erreurs dans / var / opt / mssql / log / n'a pas d'horodatage correspondant lorsque j'ai démarré la machine virtuelle (ou redémarré le service), ni de nouvelles entrées dans ce fichier.

ET, dans / var / log / messages , tout ce qui apparaît est:

Ceci est une version d'évaluation. Il reste [141] jours dans la période d'évaluation.

Si je cours systemctl status mssql-server, j'obtiens ce qui suit:

● mssql-server.service - Moteur de base de données Microsoft SQL Server
chargé: chargé (/lib/systemd/system/mssql-server.service; activé; prédéfini par le fournisseur: activé)
Actif: échoué (résultat: code de sortie) depuis lun 2017- 09-04 20:01:56 BST; Il y a 36s
Docs: https://docs.microsoft.com/en-us/sql/linux
Processus: 8009 ExecStart = / opt / mssql / bin / sqlservr (code = quitté, status = 255)
PID principal: 8009 (code = sortie, statut = 255)

Started Microsoft SQL Server Database Engine.  
This is an evaluation version.  There are [141] days left in the evaluation period.  
Stopping Microsoft SQL Server Database Engine...  
mssql-server.service: Main process exited, code=exited, status=255/n/a  
Stopped Microsoft SQL Server Database Engine.  
mssql-server.service: Unit entered failed state.  
mssql-server.service: Failed with result 'exit-code'.  

Cela a fini par être un cas de ne pas faire attention lorsque l'on travaille comme 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 d'application s'il existe, ou parfois se bloque s'il ne fonctionne pas 't (SQLCLR) ) et dans certaines circonstances, SQL Server se bloquerait complètement. Lorsque cela s'est produit, la seule façon de l'arrêter était de faire un kill -9on sqlservr. L'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(d'où 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 sqlservras root, MAIS lorsque la machine virtuelle a redémarré et que SQL Server a tenté de démarrer correctement (c'est-à-dire en tant mssqlqu'utilisateur), c'est-à-dire lorsqu'elle s'est bloquée au tout début.

J'ai constaté qu'une conséquence directe de l'exécution de sqlservras rootétait que le fichier / var / opt / mssql / log / errorlog (et certains autres créés au démarrage de SQL Server) appartenait à root(est logique).

Et, une conséquence directe de la possession de ces fichiers rootest que lorsque le processus est démarré correctement (as mssql), l' mssqlutilisateur n'a pas l'autorisation de renommer le fichier pour qu'il se termine par .1 (et tout ce qui doit se produire avec n'importe quel autre 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, sudoest uniquement nécessaire lorsqu'il n'agit pas actuellement rootcar il exécutera la commande qui le suit en tant que root (ou un autre utilisateur si vous spécifiez -u username), après avoir été invité à entrer le rootmot de passe.

sudo chown -R  mssql:mssql /var/opt/mssql

Le correctif secondaire (pour vous assurer que cela ne se reproduise plus) consiste à démarrer correctement SQL Server ;-):

sudo systemctl start mssql-server

Pour obtenir les bonnes autorisations et obtenir des erreurs intelligentes, vous avez besoin au moins des éléments suivants ...

# make sure needed directories exist
sudo mkdir /var/opt/mssql /var/opt/mssql/.system /var/opt/mssql/data /var/opt/mssql/log

# this should be owned by mssql
sudo chown -R  mssql:mssql /var/opt/mssql
sudo chmod 770 /var/opt/mssql

# this should be owned by root
sudo chown -R root:root /opt/mssql