SQL Server sur 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 avec sqlcmd . J'obtiens une erreur ODBC timeout ( "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
J'obtiens deux entrées retournées montrant que l'utilisateur mssql exécute le processus sqlservr.
En outre, le fichier journal des erreurs dans /var/opt/mssql/log/ n'a pas d'horodatage correspondant lorsque j'ai démarré le VM (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 lance systemctl status mssql-server, alors 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éréglage du fournisseur: activé)
Actif: échoué (résultat: code de sortie) depuis lun. 2017-09-04 20:01:56 BST; Il y a 36s
Documents: https://docs.Microsoft.com/en-us/sql/linux
Processus: 8009 ExecStart =/opt/mssql/bin/sqlservr (code = quitté, statut = 255)
PID principal: 8009 (code = sorti, 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 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, il ne le fait pas: SQL Server 2017 sur Linux ignore le fichier de configuration d'application s'il existe, ou parfois se verrouille) si ce n'est pas le cas (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 -9 sur sqlservr. Une fois que j'ai redémarré le service, je l'ai fait en exécutant directement /opt/mssql/bin/sqlservr et alors 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 sqlservr en tant que root, MAIS lorsque VM redémarré et SQL Server a tenté de démarrer correctement (c'est-à-dire en exécutant en tant que l'utilisateur mssql), c'est à ce moment qu'il s'est bloqué au tout début.
J'ai trouvé qu'une conséquence directe de l'exécution de sqlservr en tant que root était que /var/opt/mssql/log/errorlog (et certains autres qui sont créés au démarrage de SQL Server) appartenaient à root (c'est logique).
Et, une conséquence directe de la possession de ces fichiers par root est que lorsque le processus est démarré correctement (comme mssql), l'utilisateur mssql n'est pas autorisé à renommez le fichier pour qu'il se termine par . 1 (et tout ce qui doit se produire avec d'autres fichiers, comme 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 si elle n'agit pas actuellement comme root car elle exécutera la commande qui la suit asroot (ou un autre utilisateur si vous spécifiez -u username), après avoir été invité à saisir le mot de passe root.
Sudo chown -R mssql:mssql /var/opt/mssql
Le correctif secondaire (pour vous assurer que cela ne se reproduise pas), 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