Program SQL Server w systemie Linux zawiesza się przy pierwszym uruchomieniu, bez błędów i bez nowego / zaktualizowanego pliku ErrorLog

Używam SQL Server 2017, Release Candidate 2 (RC2) w systemie Linux (Ubuntu 16.04).

Kiedy serwer się uruchamia, SQL Server zwykle również się uruchamia. Ale z jakiegoś powodu SQL Server już się nie uruchamia. Przynajmniej nie mogę się z nim połączyć za pomocą narzędzia sqlcmd . Otrzymuję błąd limitu czasu ODBC ( „Sqlcmd: Błąd: Microsoft ODBC Driver 13 dla SQL Server ”) za każdym razem teraz:

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

Jednak gdy uruchamiam:

ps aux | grep mssql

Otrzymuję dwa wpisy zwrócone wskazujące, że mssqlużytkownik uruchamia sqlservrproces.

Ponadto plik dziennika błędów w katalogu / var / opt / mssql / log / nie ma pasującego znacznika czasu, kiedy uruchomiłem maszynę wirtualną (lub ponownie uruchomiłem usługę), ani nie ma żadnych nowych wpisów w tym pliku.

ORAZ w / var / log / messages pokazuje się tylko:

To jest wersja ewaluacyjna. W okresie oceny pozostało [141] dni.

Jeśli uruchomię systemctl status mssql-server, otrzymam następujące informacje:

● mssql-server.service -
Załadowano aparat bazy danych Microsoft SQL Server : załadowany (/lib/systemd/system/mssql-server.service; włączony; preset dostawcy: włączony)
Aktywny: nie powiódł się (Wynik: kod wyjścia) od Mon 2017- 09-04 20:01:56 BST; 36s temu
Dokumenty: https://docs.microsoft.com/en-us/sql/linux
Proces: 8009 ExecStart = / opt / mssql / bin / sqlservr (kod = zakończony, status = 255)
Główny PID: 8009 (kod = zakończony, 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'.  

Skończyło się to na tym, że nie byłem ostrożny podczas pracy jako root.

Badałem, czy SQLCLR w systemie Linux miałby dostęp do pliku app.Config, podobnie jak w systemie Windows (niestety nie: SQL Server 2017 w systemie Linux ignoruje plik konfiguracyjny aplikacji, jeśli istnieje, lub czasami blokuje się, jeśli nie działa 't (SQLCLR) ) i pod pewnymi warunkami SQL Server całkowicie się zablokuje. Gdy tak się stało, to jedyny sposób, aby zatrzymać to było zrobić kill -9na sqlservr. Kiedyś ponownie uruchamiałem usługę, zrobiłem to bezpośrednio wykonując / opt / mssql / bin / sqlservr i podczas gdy ja pracowałem jako root(stąd sam proces był własnością root).

Nie wystąpiły żadne bezpośrednie błędy ani dziwne zachowania wynikające z uruchomienia sqlservrjako root, ALE, gdy maszyna wirtualna została ponownie uruchomiona, a SQL Server próbował uruchomić się poprawnie (tj. Działając jako mssqlużytkownik), to znaczy, że utknął na samym początku.

Odkryłem, że bezpośrednią konsekwencją takiego działania sqlservrjest rootto, że plik / var / opt / mssql / log / errorlog (i niektóre inne, które są tworzone po uruchomieniu programu SQL Server) były własnością root(ma sens).

Bezpośrednią konsekwencją posiadania tych plików jest rootto, że po prawidłowym uruchomieniu procesu (as mssql) mssqlużytkownik nie ma uprawnień do zmiany nazwy pliku, aby kończył się na .1 (i cokolwiek innego musi się zdarzyć z dowolnym innym pliki, takie jak domyślny ślad itp.). Jednak zamiast błędu uprawnień, po prostu zawiesza się na zawsze.

Podstawową poprawką jest po prostu uruchomienie następującego polecenia root(nie próbowałem go uruchomić jako mssql). Dla obu z następujących poleceń, sudojest potrzebny tylko wtedy, gdy nie są aktualnie działających w charakterze root, jak to będzie działać polecenie, które następuje go jako root (lub innego użytkownika, jeśli można określić -u username), po potwierdzeniu, aby wprowadzić roothasło.

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

Dodatkową poprawką (aby upewnić się, że to się więcej nie powtórzy) jest prawidłowe uruchomienie programu SQL Server ;-):

sudo systemctl start mssql-server

Aby uzyskać prawidłowe perms i uzyskać inteligentne błędy, potrzebujesz przynajmniej następujących ...

# 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