如何解决Ubuntu系统上的SQL Server报错？含mssql-server.service异常排查

我来帮你一步步排查这个问题——服务因为ABRT信号终止，说明SQL Server进程意外崩溃了，咱们从最常见的原因开始梳理：

1. 先看SQL Server的错误日志（最关键） #

崩溃前的详细错误信息几乎都在SQL Server的专属日志里，先拉取最新的日志内容：

sudo tail -n 50 /var/opt/mssql/log/errorlog

重点找崩溃时间点附近的报错，比如磁盘空间不足、权限被拒、配置文件损坏或者依赖库缺失，这些是最常见的触发ABRT信号的原因。

2. 检查磁盘空间是否充足 #

如果SQL Server的数据盘或者系统盘满了，进程会直接崩溃。用下面的命令查看磁盘使用情况：

df -h

重点关注/var/opt/mssql所在的分区（这是SQL Server存储数据和日志的默认目录），如果使用率达到100%，赶紧清理空间：

• 删除旧的SQL Server日志文件（/var/opt/mssql/log下的旧文件）
• 清理系统临时文件或者无用的安装包

3. 验证目录权限是否正确 #

SQL Server运行在mssql用户下，如果它没有权限访问数据目录或安装目录，也会崩溃。检查权限：

ls -ld /var/opt/mssql /opt/mssql
id mssql

确保这两个目录的所有者和组都是mssql，如果不对，修复权限：

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

4. 检查系统依赖是否完整 #

SQL Server在Ubuntu上依赖一些特定的系统库，比如旧版本的libssl，如果依赖缺失或损坏，进程会启动失败甚至崩溃。尝试修复并重新安装依赖：

sudo apt-get install -f
sudo apt-get reinstall mssql-server

⚠️ 重装前记得备份/var/opt/mssql/data目录，这里是你的数据库核心数据文件！

5. 分析核心转储文件（进阶排查） #

ABRT信号通常会生成核心转储文件（core dump），可以用调试工具分析崩溃的具体调用栈：

1. 找到核心转储文件，一般在/var/crash目录下
2. 用gdb分析：

sudo gdb /opt/mssql/bin/sqlservr /var/crash/core.*

在gdb里输入bt命令查看调用栈，就能定位到崩溃的具体代码位置。如果看不懂调用栈，可以把输出内容贴出来进一步分析。

6. 尝试重启服务（清理残留进程） #

有时候残留的僵尸进程会导致服务无法正常启动，先清理再重启：

sudo pkill sqlservr
sudo systemctl start mssql-server

然后再次查看服务状态：

sudo systemctl status mssql-server

最后还要注意：确认你的SQL Server版本和Ubuntu版本是否兼容——旧版SQL Server可能不支持最新的Ubuntu发行版，这也会导致启动失败。

内容的提问来源于stack exchange，提问作者Roshan Sankhe