systemctl 与 journalctl：服务故障排查的固定顺序

服务启动失败时，我会按“状态 → 日志 → 配置 → 端口 → 再验证”的顺序检查。这样可以保留证据，也能避免一上来就重装软件。下面以 sshd 为例；不同发行版的服务名可能是 ssh。

1. 先确认服务状态

systemctl status sshd --no-pager
systemctl is-enabled sshd

status 会显示是否运行、退出码以及最近几行日志。is-enabled 只表示开机是否自动启动，与此刻是否运行是两回事。若提示单元不存在，先用 systemctl list-unit-files | grep ssh 找真实名称。

2. 沿着时间线读日志

journalctl -u sshd -b --no-pager -n 80
journalctl -u sshd --since "30 minutes ago" --no-pager

-b 限制为本次启动，-n 80 看末尾 80 行。重点找第一条明确错误：配置语法、权限、端口占用或依赖失败。记下报错原文，再查对应配置。

3. 改动前先验证配置

OpenSSH 服务端可用 sshd -t 检查配置语法；执行前先确认系统已安装并找到该命令。其他服务也常有自己的 --test 或 -t 选项。编辑配置前先备份，修改后先做语法检查，再重启。

sudo sshd -t
sudo systemctl restart sshd
systemctl status sshd --no-pager
ss -lntp | grep -E ':(22|62307)\b'

远程操作 SSH 时，保留当前登录会话，确认新会话可以连接后再退出。最后记录“现象、日志证据、改动、验证结果”，这比“重启好了”更有复用价值。

重新加载的适用边界

本站 SSH 使用自定义端口，文中 22 只是默认示例。先用 systemctl cat sshd 核对服务执行的程序，再检查实际监听；机器上存在多套 OpenSSH 时，PATH 中的 sshd 不一定是服务正在使用的版本。修改前保留控制台入口，用实际服务二进制 -t 检查，再按服务能力选择 reload 或 restart。daemon-reload 只重新读取 systemd 单元，不会替服务加载业务配置。

内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。