SQL Server su Linux si blocca all'avvio iniziale, nessun errore e nessun file ErrorLog nuovo / aggiornato


11

Sto usando SQL Server 2017, Release Candidate 2 (RC2) su Linux (Ubuntu 16.04).

All'avvio del server, di solito viene avviato anche SQL Server. Ma per qualche motivo, SQL Server non si avvia più. Almeno non riesco a connettermi ad esso usando sqlcmd . Ricevo ogni volta un errore di timeout ODBC ( "Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server "):

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

Tuttavia, quando corro:

ps aux | grep mssql

Ricevo due voci che mostrano che l' mssqlutente sta eseguendo il sqlservrprocesso.

Inoltre, il file log degli errori in / var / opt / mssql / log / non ha una corrispondenza data / ora quando ho avviato la VM (o riavviato il servizio), né ci sono nuove voci in quel file.

E, in / var / log / messages , tutto ciò che appare è:

Questa è una versione di valutazione. Sono rimasti [141] giorni nel periodo di valutazione.

Se corro systemctl status mssql-server, ottengo quanto segue:

● mssql-server.service - Motore di database di Microsoft SQL Server
caricato: caricato (/lib/systemd/system/mssql-server.service; abilitato; preimpostazione fornitore: abilitato)
Attivo: non riuscito (Risultato: codice di uscita) dal lun 2017- 09-04 20:01:56 BST; 36 anni fa
Documenti: https://docs.microsoft.com/en-us/sql/linux
Processo: 8009 ExecStart = / opt / mssql / bin / sqlservr (codice = uscito, stato = 255)
PID principale: 8009 (codice = uscito, stato = 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'.  

Risposte:


15

Questo è finito per non stare attento quando si lavora come root.

Avevo cercato se SQLCLR su Linux avesse accesso all'app. File di configurazione come fa in Windows (purtroppo no: SQL Server 2017 su Linux ignora il file di configurazione dell'app se esiste, o a volte si blocca se non lo fa 't (SQLCLR) ) e in determinate circostanze SQL Server si bloccherebbe completamente. Quando ciò è accaduto, l'unico modo per fermarlo è stato fare un kill -9on sqlservr. Una delle volte in cui ho riavviato il servizio, l'ho fatto eseguendo direttamente / opt / mssql / bin / sqlservr e mentre stavo lavorando come root(quindi il processo stesso era di proprietà root).

Non si sono verificati errori immediati o comportamenti strani derivanti dall'esecuzione sqlservrcome rootMA MA quando la VM è stata riavviata e SQL Server ha tentato di avviarsi correttamente (ovvero in esecuzione come mssqlutente), ovvero quando si è bloccato all'inizio.

Ho scoperto che una diretta conseguenza di correre sqlservrcome rootera che il / var / opt / mssql / log / errorlog file (e alcuni altri che si creano all'avvio di SQL Server) sono stati di proprietà di root(ha un senso).

E, una conseguenza diretta di quei file di proprietà rootè che quando il processo viene avviato correttamente (come mssql), allora l' mssqlutente non ha il permesso di rinominare il file per finire in .1 (e qualsiasi altra cosa deve accadere con qualsiasi altro file, come traccia predefinita, ecc.). Tuttavia, anziché ottenere un errore di autorizzazione, si blocca per sempre.

La correzione primaria è semplicemente eseguire quanto segue come root(non ho provato a eseguirlo come mssql). Per entrambi i seguenti comandi, sudoè necessario solo quando attualmente non agisce in rootquanto eseguirà il comando che lo segue come root (o qualche altro utente se specificato -u username), dopo che è stato richiesto di immettere la rootpassword.

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

La correzione secondaria (per assicurarsi che ciò non accada di nuovo), è avviare correttamente SQL Server ;-):

sudo systemctl start mssql-server

1

Per ottenere i permessi giusti e ottenere errori intelligenti, è necessario almeno quanto segue ...

# 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
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.