Dépanner un problème de démarrage de SQL Server 2019 sur Ubuntu lié à une erreur d’action avec root

Introduction

TOUJOURS démarrer le moteur SQL Server sur Linux avec le compte mssql.

mssql@vps$ sudo systemctl start|stop mssql-server

NE JAMAIS EXÉCUTER directement le binaire sqlservr en tant que root, par exemple :

root@vps$ /opt/mssql/bin/sqlsrvr

En effet, le moteur ne peut pas alors être redémarré normalement avec le compte mssql.

mssql@vps$ sudo systemctl start mssql-server
          
● mssql-server.service - Microsoft SQL Server Database Engine
   Loaded: loaded (/lib/systemd/system/mssql-server.service; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2019-05-31 18:57:06 CEST; 4min 7s ago
     Docs: https://docs.microsoft.com/en-us/sql/linux
  Process: 15259 ExecStart=/opt/mssql/bin/sqlservr (code=exited, status=1/FAILURE)

Diagnostiquer et dépanner le problème

SQL Server créé des fichiers binaires systèmes cachés (*.hiv) dans le répertoire /var/opt/mssql/.system/system. Leur usage n’est pas documenté.

mssql@vps$ ls -lrt /var/opt/mssql/.system/system

-rw-r----- 1 mssql mssql  8192 May 31 18:44 licensing.hiv
-rw-rw---- 1 mssql mssql 49152 May 31 15:40 security.hiv
-rw-rw---- 1 mssql mssql 16384 May 31 15:40 lsa.hiv

En exécutant par inadvertance SQL Server en tant que root, les permissions sont modifiées pour ces fichiers :

mssql@vps$ ls -lrt /var/opt/mssql/.system/system

-rw-r----- 1 mssql mssql  8192 Jun  6 18:44 licensing.hiv
-rw-r----- 1 root  root  49152 Jun 18 18:59 security.hiv
-rw-r----- 1 root  root  16384 Jun 18 18:59 lsa.hiv

C’est pourquoi, au démarrage suivant, le moteur SQL Server ne démarre pas, le compte mssql n’est pas autorisé à lire/écrire ces fichiers *.hiv.

L’information est disponible dans les fichiers crash dump générés :

       Reason: 0x00000007
       Status: 0xc0000218
      Message: Cannot open or read the persistent registry: \SystemRoot\security.hiv.

Par défaut les fichiers crash dump sont dans le répertoire /var/opt/mssql/log/, sinon dans le répertoire spécifié par la directive defaultdumpdir dans le fichier de configuration /var/opt/mssql/mssql.conf.

mssql@vps$ /opt/mssql/bin/mssql-conf get filelocation defaultdumpdir

defaultdumpdir : /opt/mssql/dba/srvmssql/crashdump

Donc, en tant que root, remettre le propriétaire de ces fichiers à mssql :

root@vps$ cd /var/opt/mssql/.system/system

root@vps$ chown mssql:mssql security.hiv
root@vps$ chown mssql:mssql lsa.hiv

Malheureusement, le service mssql-server ne démarre alors toujours pas. Même problème que celui rencontré avec les fichiers *.hiv, il faut s’assurer que le propriétaire des fichiers de log de SQL Server et de son agent n’est pas devenu root (répertoire par défaut /var/opt/mssql/log) :

-rw-r----- 1 root root 14357 May 31 19:50 errorlog
-rw-r----- 1 root root 6694 May 31 19:50 sqlagent.log

Lors de la tentative de recyclage des fichiers de log, l’erreur "Access is denied" est rencontrée par le moteur et le moteur s’arrête. Pour vérifier que c’est le cas, en tant que mssql :

mssql@vps$ /opt/mssql/bin/sqlservr

2019-05-31 21:04:22.58 Server      Error: 17058, Severity: 16, State: 1.
2019-05-31 21:04:22.58 Server      initerrlog: Could not open error log file '/opt/mssql/dba/srvmssql/log/errorlog'. Operating system error = 5(Access is denied.).
2019-05-31 21:04:22.88 Server      Error: 17058, Severity: 16, State: 1.
2019-05-31 21:04:22.88 Server      initerrlog: Could not open error log file '/opt/mssql/dba/srvmssql/log/errorlog'. Operating system error = 5(Access is denied.).

En tant que root, modifier le propriétaire de tous les fichiers de log impactés :

root@vps$ chown mssql:mssql errorlog

root@vps$ chown mssql:mssql sqlagent.log

À présent le service mssql-server démarre avec succès :

mssql@vps$ sudo systemctl start mssql-server

mssql@vps$ systemctl status mssql-server
● mssql-server.service - Microsoft SQL Server Database Engine
   Loaded: loaded (/lib/systemd/system/mssql-server.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-05-31 22:33:28 CEST; 1min 31s ago

Conclusion

Y-a-t-il besoin d’une conclusion ? Conclusion évidente : utiliser des connexions avec root seulement si nécessaires et fermer ces connexions dès qu’elles ne sont plus utiles !.