Esto terminó como un caso de no tener cuidado al trabajar como root .
Estuve investigando si SQLCLR en Linux tendría acceso al archivo app.Config como lo hace en Windows (lamentablemente, no es así:SQL Server 2017 en Linux ignora el archivo de configuración de la aplicación si existe, o a veces se bloquea si no existe). 't (SQLCLR) ) y, en determinadas circunstancias, SQL Server se bloquearía por completo. Cuando eso sucedió, la única forma de detenerlo fue hacer un kill -9 el sqlservr . Una de las veces que estaba reiniciando el servicio, lo hice ejecutando directamente /opt/mssql/bin/sqlservr y mientras trabajaba como root (por lo tanto, el proceso en sí era propiedad de root ).
No hubo errores inmediatos o comportamientos extraños como resultado de ejecutar sqlservr como root , PERO cuando la máquina virtual se reinició y SQL Server intentó iniciarse correctamente (es decir, ejecutándose como mssql usuario), ahí es cuando se atascó al principio.
Descubrí que es una consecuencia directa de ejecutar sqlservr como root fue que el /var/opt/mssql/log/errorlog (y algunos otros que se crean al iniciar SQL Server) eran propiedad de root (tiene sentido).
Y, una consecuencia directa de que esos archivos sean propiedad de root es que cuando el proceso se inicia correctamente (como mssql ), luego el mssql el usuario no tiene permiso para cambiar el nombre del archivo para que termine en .1 (y cualquier otra cosa que deba suceder con cualquier otro archivo, como el seguimiento predeterminado, etc.). Sin embargo, en lugar de obtener un error de permisos, simplemente se cuelga para siempre.
La solución principal es simplemente ejecutar lo siguiente como root (No he intentado ejecutarlo como mssql ). Para los dos comandos siguientes, sudo solo es necesario cuando no está actuando actualmente como root as ejecutará el comando que le sigue as root (o algún otro usuario si especifica -u username ), después de que se le solicite ingresar el root contraseña.
sudo chown -R mssql:mssql /var/opt/mssql
La solución secundaria (para asegurarse de que esto no vuelva a suceder) es iniciar SQL Server correctamente;-):
sudo systemctl start mssql-server