CentOS 8.3环境下mssql-server服务运行中无法连接且生成大量日志

一、连接失败问题排查 #

• 先确认端口监听状态
  执行 ss -tulnp | grep sqlservr 查看是否有1433端口的监听记录。如果无监听记录，说明服务进程虽然运行，但核心网络模块未完成初始化，属于启动异常。
• 清理残留进程修复启动异常
  你提供的systemctl日志中存在服务异常退出后的遗留进程，会阻塞新启动服务的资源分配，按以下步骤处理：
  1. 停止服务：systemctl stop mssql-server.service
  2. 清理所有关联残留进程：ps aux | grep -E 'sqlservr|sh.*mssql|tar.*mssql|bzip2.*mssql' | grep -v grep | awk '{print $2}' | xargs kill -9
  3. 修正数据目录权限：chown -R mssql:mssql /var/opt/mssql，权限异常会导致服务初始化失败
  4. 重新启动服务：systemctl start mssql-server.service
  5. 等待2分钟后再测试连接，SQL Server首次启动或修复后启动需要完成初始化操作，不要立即发起连接请求
• 验证连接配置
  如果端口已正常监听还是连接失败，按以下步骤排查：
  1. 指定IP和端口连接，避免localhost解析异常：sqlcmd -S 127.0.0.1,1433 -U SA -p
  2. 确认SA账号密码符合复杂度要求：至少8位，同时包含大小写字母、数字、特殊符号
  3. 临时关闭防火墙和SELinux验证是否为策略拦截：systemctl stop firewalld、setenforce 0

二、日志过多问题处理 #

/var/opt/mssql/log下的日志分为两类，分别处理：

• 常规运行日志（errorlog.*）：默认保留6个归档文件，可通过命令调整保留个数：/opt/mssql/bin/mssql-conf set errorlog.numerrorlogs 10，最大可设置为99，历史归档日志可直接手动删除
• 崩溃转储文件（.mdmp、.tar.bz2）：这是服务异常崩溃时自动生成的转储文件，也就是你日志中看到的tar、bzip2进程的生成产物，解决服务崩溃问题后，已生成的转储文件可直接删除；也可配置关闭自动转储：/opt/mssql/bin/mssql-conf set coredump.capturemini off

三、根因定位方法 #

如果上述操作后问题仍存在，查看最新的运行日志即可获取明确报错原因：tail -n 100 /var/opt/mssql/log/errorlog，日志中会记录许可过期、数据文件损坏、端口占用、SA账号异常等具体问题。

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