it-swarm.com.de

SQL Server unter Linux hängt beim ersten Start, keine Fehler und keine neue / aktualisierte ErrorLog-Datei

Ich verwende SQL Server 2017, Release Candidate 2 (RC2) unter Linux (Ubuntu 16.04).

Wenn der Server gestartet wird, wird normalerweise auch SQL Server gestartet. Aus irgendeinem Grund wird SQL Server jedoch nicht mehr gestartet. Zumindest kann ich mit sqlcmd keine Verbindung herstellen. Ich erhalte jedes Mal einen Fehler ODBC timeout ( "Sqlcmd: Fehler: Microsoft ODBC Treiber 13 für SQL Server") jetzt:

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

Wenn ich jedoch renne:

ps aux | grep mssql

Ich erhalte zwei Einträge zurück, die zeigen, dass der Benutzer mssql den Prozess sqlservr ausführt.

Auch die Datei errorlog in /var/opt/mssql/log/ hat keinen übereinstimmenden Zeitstempel, als ich VM (oder den Dienst neu gestartet)) gestartet habe, und es gibt auch keine neuen Einträge in dieser Datei.

UND in /var/log/messages wird nur Folgendes angezeigt:

Dies ist eine Evaluierungsversion. Im Bewertungszeitraum verbleiben [141] Tage.

Wenn ich systemctl status mssql-server, dann bekomme ich folgendes:

● mssql-server.service - Microsoft SQL Server-Datenbankmodul
Geladen: geladen (/lib/systemd/system/mssql-server.service; aktiviert; Hersteller-Voreinstellung: aktiviert)
Aktiv: fehlgeschlagen (Ergebnis: Exit-Code) seit Mo 2017-09-04 20:01:56 BST; Vor 36s
Dokumente: https://docs.Microsoft.com/en-us/sql/linux
Prozess: 8009 ExecStart =/opt/mssql/bin/sqlservr (Code = beendet, Status = 255)
Haupt-PID: 8009 (Code = beendet, 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'.  
11
Solomon Rutzky

Dies endete damit, dass man bei der Arbeit als root nicht vorsichtig war.

Ich hatte untersucht, ob SQLCLR unter Linux Zugriff auf die Datei app.Config haben würde, wie dies unter Windows der Fall ist (leider nicht: SQL Server 2017 unter Linux ignoriert die Konfigurationsdatei der App, falls vorhanden, oder sperrt sie manchmal). Wenn dies nicht der Fall ist (SQLCLR) ) und unter bestimmten Umständen würde SQL Server vollständig abstürzen. Wenn dies geschah, war die einzige Möglichkeit, dies zu stoppen, ein kill -9 Für sqlservr. Eines der Male, als ich den Dienst erneut startete, führte ich direkt /opt/mssql/bin/sqlservr und während ich als root arbeitete (daher gehörte der Prozess selbst root).

Es gab keine unmittelbaren Fehler oder merkwürdigen Verhaltensweisen, die sich aus der Ausführung von sqlservr als root ergaben, ABER als VM neu gestartet wurde und SQL Server versuchte, ordnungsgemäß zu starten (dh als ausgeführt als) der mssql Benutzer), das heißt, als es am Anfang stecken blieb.

Ich fand heraus, dass eine direkte Folge des Ausführens von sqlservr als root darin bestand, dass /var/opt/mssql/log/errorlog Datei (und einige andere, die beim Starten von SQL Server erstellt werden) gehörten root (sinnvoll).

Eine direkte Folge dieser Dateien, die root gehören, ist, dass der Benutzer mssql beim ordnungsgemäßen Starten des Prozesses (als mssql) keine Berechtigung dazu hat Benennen Sie die Datei so um, dass sie mit endet. 1 (und was auch immer mit anderen Dateien geschehen muss, wie z. B. Standard-Trace usw.). Anstatt einen Berechtigungsfehler zu erhalten, bleibt er jedoch für immer hängen.

Die primäre Lösung besteht darin, einfach Folgendes als root auszuführen (ich habe nicht versucht, es als mssql auszuführen). Für beide der folgenden Befehle wird Sudo nur benötigt, wenn es derzeit nicht als root fungiert, da der darauf folgende Befehl ausgeführt wird asroot (oder ein anderer Benutzer, wenn Sie -u username angeben), nachdem Sie aufgefordert wurden, das Kennwort root einzugeben.

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

Die sekundäre Korrektur (um sicherzustellen, dass dies nicht erneut geschieht) besteht darin, SQL Server ordnungsgemäß zu starten ;-):

Sudo systemctl start mssql-server
15
Solomon Rutzky

Um die Dauerwellen richtig zu machen und intelligente Fehler zu erhalten, benötigen Sie mindestens Folgendes ...

# 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
1
Evan Carroll