Linux日志里的报错不是乱码，而是系统在“说话”——关键看懂它说的是哪类问题。核心思路是：先定位错误类型（权限？端口？磁盘？），再结合日志上下文和时间点判断根因。
常见错误代码含义与典型场景
日志中高频出现的错误码往往指向明确问题，无需逐行读完日志就能缩小范围：
-
EACCES (Permission denied)：进程没权限访问文件或目录。比如服务启动时提示“cannot open /etc/myapp/config”，检查该配置文件的属主和权限（
ls -l /etc/myapp/config） - ENOENT (No such file or directory)：路径根本不存在。常见于脚本硬编码了错误路径，或服务依赖的二进制、配置、证书文件被误删
-
EADDRINUSE (Address already in use)：端口被占。运行
sudo ss -tuln | grep :8080可查谁在用8080端口 -
ENOSPC (No space left on device)：磁盘满。不只是
/分区，也可能是/var/log所在分区或/run（tmpfs）空间耗尽，用df -h确认 - ECONNREFUSED / ETIMEDOUT：目标服务未运行或网络不通。前者多见于本地连接失败（如数据库没启），后者更倾向防火墙、路由或远端宕机
-
SIGSEGV / SIGABRT：程序崩溃。通常出现在应用日志或
dmesg输出中，说明有内存越界或主动中止，需查对应服务的堆栈或core dump
快速定位报错所在的日志源
别盲目翻所有日志，按问题性质选对入口：
- 系统级故障（启动失败、内核警告、硬件异常）→ 查
dmesg -T或/var/log/kern.log - 服务无法启动/反复退出 → 先看
systemctl status 服务名，再执行journalctl -u 服务名 -n 50 --no-pager看最近50行 - SSH登录失败、sudo被拒 → 直接查
/var/log/auth.log（Debian系）或/var/log/secure（RHEL系） - Web服务返回502/503 → 看Nginx/Apache的error.log，而非access.log；同时用
journalctl -u nginx交叉验证 - 定时任务出错 → 检查
/var/log/cron，并确认crond是否在运行（systemctl status cron）
高效查看和过滤错误日志的实操命令
不用打开大文件盲搜，几条命令就能聚焦关键信息：
- 实时盯住错误：
sudo journalctl -f -p err（systemd系统）sudo tail -f /var/log/syslog | grep -i "error\|fail\|denied"（传统syslog） - 查某服务最近1小时的错误：
journalctl -u nginx --since "1 hour ago" -p err - 从海量日志中提取带时间戳的错误行（适配常见格式）：
grep -i "error\|fail" /var/log/messages | head -20 - 确认是不是权限导致读不了日志：
sudo ls -l /var/log/messages，若显示Permission denied，必须加sudo再操作
排查时容易忽略的关键细节
很多问题卡在“以为找到了，其实不是”：
- 日志时间可能不准：系统时间偏差会导致错误时间难定位，先运行
timedatectl status确认时区和同步状态 - 错误是结果不是原因：比如“Connection refused”常是上游服务挂了，要顺藤摸瓜查那个上游服务的日志，而不是只修当前报错的服务
- 日志轮转后旧记录丢失：默认
/var/log/messages会被logrotate压缩归档，查更早的问题得翻/var/log/messages.1.gz甚至.2.gz，用zgrep搜索 - 某些错误只在
journalctl里有，不在文件日志中：如果没配置journald持久化（/var/log/journal目录不存在），重启后日志就没了
