Dies endete in einer Unachtsamkeit bei der Arbeit als root .
Ich hatte recherchiert, ob SQLCLR unter Linux Zugriff auf die app.Config-Datei haben würde, wie es in Windows der Fall ist (leider nicht:SQL Server 2017 unter Linux ignoriert die App-Konfigurationsdatei, falls vorhanden, oder sperrt sich manchmal, wenn dies der Fall ist 't (SQLCLR) ) und unter bestimmten Umständen würde SQL Server vollständig abstürzen. Als das passierte, war die einzige Möglichkeit, es zu stoppen, eine kill -9 am sqlservr . Einmal habe ich den Dienst erneut gestartet, indem ich direkt /opt/mssql/bin/sqlservr ausgeführt habe und während ich als root arbeitete (daher gehörte der Prozess selbst root ).
Es gab keine unmittelbaren Fehler oder ungewöhnliches Verhalten, die sich aus der Ausführung von sqlservr ergaben als root , ABER wenn die VM neu gestartet wurde und SQL Server versuchte, ordnungsgemäß zu starten (d. h. als mssql ausgeführt wurde Benutzer), da blieb es ganz am Anfang hängen.
Ich fand das eine direkte Folge der Ausführung von sqlservr als root war das die /var/opt/mssql/log/errorlog Datei (und einige andere, die beim Starten von SQL Server erstellt werden) waren im Besitz von root (macht Sinn).
Und eine direkte Folge davon, dass diese Dateien root gehören ist das, wenn der Prozess ordnungsgemäß gestartet wird (als mssql ), dann mssql Der Benutzer hat keine Berechtigung, die Datei so umzubenennen, dass sie auf .1 endet (und was auch immer sonst mit anderen Dateien passieren muss, wie z. B. Standard-Trace usw.). Anstatt jedoch einen Berechtigungsfehler zu erhalten, bleibt es einfach für immer hängen.
Die primäre Lösung besteht darin, Folgendes einfach als root auszuführen (Ich habe nicht versucht, es als mssql auszuführen ). Für die beiden folgenden Befehle sudo wird nur benötigt, wenn derzeit nicht als root agiert wird da es den folgenden Befehl als ausführen wird root (oder ein anderer Benutzer, wenn Sie -u username angeben ), nachdem Sie aufgefordert wurden, den root einzugeben Passwort.
sudo chown -R mssql:mssql /var/opt/mssql
Die zweite Lösung (um sicherzustellen, dass dies nicht noch einmal passiert) besteht darin, SQL Server ordnungsgemäß zu starten;-):
sudo systemctl start mssql-server