O SQL Server no Linux trava na inicialização, sem erros e nenhum arquivo ErrorLog novo / atualizado

Estou usando o SQL Server 2017, Release Candidate 2 (RC2) no Linux (Ubuntu 16.04).

Quando o servidor é iniciado, o SQL Server geralmente também é iniciado. Mas, por algum motivo, o SQL Server não será mais iniciado. Pelo menos não consigo me conectar a ele usando o sqlcmd . Sempre recebo um erro de tempo limite ODBC ( "Sqlcmd: Erro: Driver ODBC da Microsoft 13 para SQL Server ") agora:

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..

No entanto, quando eu corro:

ps aux | grep mssql

Recebo duas entradas retornadas, mostrando que o mssqlusuário está executando o sqlservrprocesso.

Além disso, o arquivo errorlog em / var / opt / mssql / log / não possui um carimbo de data e hora quando iniciei a VM (ou reiniciei o serviço), nem existem novas entradas nesse arquivo.

E, em / var / log / messages , tudo o que aparece é:

Esta é uma versão de avaliação. Restam [141] dias no período de avaliação.

Se eu executar systemctl status mssql-server, obtenho o seguinte:

● mssql-server.service - Mecanismo de banco de dados do Microsoft SQL Server
Carregado: carregado (/lib/systemd/system/mssql-server.service; ativado; predefinição de fornecedor: ativado)
Ativo: falhou (resultado: código de saída) desde seg 2017 - 09-04 20:01:56 BST; 36s ago
Docs: https://docs.microsoft.com/en-us/sql/linux
Processo: 8009 ExecStart = / opt / mssql / bin / sqlservr (código = encerrado, status = 255)
PID principal: 8009 (código = encerrado, status = 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'.  

Isso acabou como um caso de não ter cuidado ao trabalhar como root.

Eu estava pesquisando se o SQLCLR no Linux teria acesso ao arquivo app.Config como no Windows (infelizmente, isso não acontece: o SQL Server 2017 no Linux ignora o arquivo de configuração do aplicativo, se existir, ou, às vezes, trava se não (SQLCLR) ) e, em determinadas circunstâncias, o SQL Server seria bloqueado completamente. Quando isso aconteceu, a única maneira de pará-lo era fazer um kill -9on sqlservr. Uma vez que eu estava iniciando o serviço novamente, eu o fazia executando diretamente / opt / mssql / bin / sqlservr e enquanto trabalhava root(por isso o próprio processo era de propriedade root).

Não houve erros imediatos ou comportamento estranho resultante da execução sqlservrcomo root, MAS quando a VM foi reiniciada e o SQL Server tentou iniciar corretamente (ou seja, executando como mssqlusuário), ou seja, quando ele ficou paralisado no início.

Descobri que uma consequência direta de correr sqlservrcomo rootfoi que a / var / opt / MSSQL / log / errorlog arquivo (e alguns outros que são criados em cima do SQL Server começando) foram detidas por root(faz sentido).

E uma conseqüência direta da propriedade desses arquivos rooté que, quando o processo é iniciado corretamente (as mssql), o mssqlusuário não tem permissão para renomear o arquivo para terminar em .1 (e o que mais precisar acontecer com qualquer outro arquivos, como rastreamento padrão etc.). No entanto, em vez de obter um erro de permissão, ele fica travado para sempre.

A correção principal é simplesmente executar o seguinte como root(eu não tentei executá-lo como mssql). Para os dois comandos a seguir, sudoé necessário apenas quando não estiver atuando atualmente, rootpois ele executará o comando que o segue como root (ou algum outro usuário, se você especificar -u username), após ser solicitado a digitar a rootsenha.

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

A correção secundária (para garantir que isso não aconteça novamente) é iniciar o SQL Server corretamente ;-):

sudo systemctl start mssql-server

Para obter as permissões certas e obter erros inteligentes, você precisa pelo menos do seguinte ...

# 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