麒麟系统定位进程异常需三类日志交叉分析：用journalctl按服务名或PID查systemd结构化错误日志；用grep在/var/log/syslog等文本日志中检索进程关键词；用dmesg捕获OOM、段错误等内核级终止痕迹。
您在麒麟系统中遇到程序崩溃、服务无响应或后台进程异常终止，需要从系统日志中精准定位该进程的错误输出和失败原因，必须结合结构化日志、文本日志与内核缓冲区三类源头交叉比对。
用 journalctl 筛选指定进程的报错日志
systemd-journald 会为每个由它启动的进程（包括服务、用户单元）打上唯一标识，可直接按进程名、PID 或服务单元名过滤错误事件。
第一步：查看最近一次启动以来所有与 nginx 相关的日志（含启动、崩溃、重启全过程）→ sudo journalctl -u nginx.service -b
第二步：只显示错误级别（err）及以上消息，并限制输出最近 50 行，避免被调试信息淹没→ sudo journalctl -u nginx.service -b -p err -n 50
第三步：若进程非 systemd 服务（如手动运行的 ./myapp），先查其 PID→ ps aux | grep myapp，再用 PID 精准抓取日志→ sudo journalctl _PID=12345 -p err
【注意：_PID 过滤仅对 journalctl 持久化存储启用后有效；若提示“No journal files were found”，需先执行 sudo mkdir -p /var/log/journal/ && sudo systemctl restart systemd-journald】
从 /var/log/ 文本日志中提取进程级错误线索
rsyslog 会将部分进程输出（尤其是 daemon 类）自动归集到 syslog 或 messages 中，适合检索未被 systemd 托管的进程错误。
方法一：在 syslog 中搜索进程名 + 错误关键词（不区分大小写）→ sudo grep -i "myapp.*error\|myapp.*fail\|myapp.*segfault" /var/log/syslog
方法二：快速定位认证类进程（如 sshd、sudo）的拒绝记录→ sudo grep "Failed password" /var/log/auth.log
方法三：分页查看并高亮所有含“segmentation fault”或“killed process”的行→ sudo less /var/log/syslog → 输入 /segmentation fault 回车，再按 n 跳转
用 dmesg 捕获进程被内核强制终止的痕迹
当进程因内存溢出（OOM）、非法指令或访问受保护内存而被 kernel 杀掉时，只会记入内核环形缓冲区，不会出现在 journalctl 或 syslog 中。
① 显示带时间戳的全部内核消息，重点查找 “Out of memory” 或 “Killed process” 字样→ sudo dmesg -T
② 只输出警告与错误级消息，并高亮关键词→ sudo dmesg -l warn,err | grep -i "killed\|oom\|segfault"
③ 若当前缓冲区已被刷掉，立即执行 sudo dmesg -C 清空，复现问题动作（如启动某程序），再立刻运行上一步命令捕获原始记录。
