SQL Server on Linux hangs on initial startup, no errors, and no new / updated ErrorLog file I'm using SQL Server 2017, Release Candidate 2 (RC2) on Linux (Ubuntu 16.04).
When the server starts up, SQL Server usually starts as well. But for some reason, SQL Server won't start anymore. At least I cannot connect to it using sqlcmd. I get an ODBC timeout (&quot;Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server&quot;) error every time now:
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..

However, when I run:
ps aux | grep mssql

I get two entries returned showing that the mssql user is running the sqlservr process.
Also, the errorlog file in /var/opt/mssql/log/ does not have a timestamp matching when I started the VM (or restarted the service), nor are there any new entries in that file.
AND, in /var/log/messages, all that shows up is:

This is an evaluation version.  There are [141] days left in the evaluation period.

If I run systemctl status mssql-server, then I get the following:

● mssql-server.service - Microsoft SQL Server Database Engine
Loaded: loaded (/lib/systemd/system/mssql-server.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2017-09-04 20:01:56 BST; 36s ago
Docs: https://docs.microsoft.com/en-us/sql/linux
Process: 8009 ExecStart=/opt/mssql/bin/sqlservr (code=exited, status=255)
Main PID: 8009 (code=exited, 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'.
This ended up as a case of not being careful when working as root.

I had been researching if SQLCLR on Linux would have access to the app.Config file like it does in Windows (sadly, it does not: SQL Server 2017 on Linux ignores app config file if it exists, or sometimes locks-up if it doesn't (SQLCLR) ) and under certain circumstances SQL Server would completely lock up. When that happened, the only way to stop it was to do a kill -9 on sqlservr. One of the times that I was starting the service again, I did so by directly executing /opt/mssql/bin/sqlservr and while I was working as root (hence the process itself was owned by root).

There were no immediate errors or odd behavior resulting from running sqlservr as root, BUT when the VM restarted and SQL Server attempted to start properly (i.e. running as the mssql user), that is when it got stuck at the very beginning.

I found that a direct consequence of running sqlservr as root was that the /var/opt/mssql/log/errorlog file (and some others that are created upon SQL Server starting) were owned by root (makes sense).

And, a direct consequence of those files being owned by root is that when the process is started properly (as mssql), then the mssql user doesn't have permission to rename the file to end in .1 (and whatever else needs to happen with any other files, such as default trace, etc). However, rather than getting a permissions error, it just hangs forever.

The primary fix is to simply run the following as root (I haven't tried running it as mssql). For both of the following commands, sudo is only needed when not currently acting as root as it will run the command that follows it as root (or some other user if you specify -u username), after being prompted to enter the root password.

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


The secondary fix (to make sure that this doesn't happen again), is to start SQL Server properly ;-):

sudo systemctl start mssql-server