jobs -r 只显示真正运行中的后台任务：bash 4.0+ 支持该选项，仅列出状态为 r（running）的作业，排除 s（sleeping）及未调度进程；jobs -r 无效，会报错；输出含作业编号、状态和命令行，不含 pid。
jobs -r 只显示真正运行中的后台任务
bash 的 jobs 命令本身不区分“启动了但没真正在跑”和“正在 CPU 上执行”的任务，很多人误用 jobs | grep 'Running'，但输出格式可能随 bash 版本变化，不可靠。正确做法是直接用内置选项：jobs -r（Bash 4.0+ 支持），它只列出状态为 R（Running）的作业，不含 S（Sleeping）或刚 fork 出来还没调度的假活跃任务。
常见错误：试图用 jobs -R——这个选项根本不存在，bash 会报错 jobs: bad option: -R。
-
jobs -r输出的是作业编号（如[1]）、状态、命令行，不带 PID - 若需进一步查资源占用，可配合
ps：先用jobs -p -r获取 PID 列表，再ps -o pid,comm,%cpu,%mem,state -p $(jobs -p -r) - 注意：只有当前 shell 启动的后台任务（用
&或Ctrl+Z+bg启动的）才会出现在jobs输出里，systemd 服务或其它终端启的进程不会出现
ps aux | grep 看全局进程时怎么避免漏掉“假运行”状态
ps aux 里的 STAT 列是关键：单个 R 表示正在运行（on CPU），R+ 或 R 也是运行态；但 <code>S（Sleeping）常被误认为“在跑”，其实只是就绪队列里等待 I/O 或信号，没占 CPU。真正要盯的是 %CPU > 0 且 STAT 含 R 的进程。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 过滤真实运行中进程：
ps aux --sort=-%cpu | awk '$8 ~ /^[Rr]/ && $3 > 0 {print}'（第8列是 STAT，第3列是 %CPU） - 别只信
ps aux | grep myapp——grep 自身也会出现在结果里，加-v grep不够稳，推荐用pgrep -f 'myapp'直接取 PID -
ps是快照，瞬间状态。如果某个进程%CPU为 0 但STAT是R，说明它刚被调度但还没执行完时间片，仍算运行中
top 和 htop 里哪些字段能确认“真正在消耗资源”
top 默认界面中，%CPU 和 STATE（即 S 列）必须同时看：R 状态 + 非零 %CPU 才代表此刻在跑；而 S 状态下 %CPU 恒为 0，哪怕它占着内存也不算“运行中”。htop 更直观——顶部有实时 CPU 使用率图，进程行右侧的 “CPU%” 列和颜色标识（绿色=活跃）比 top 更少歧义。
-
top中按P（大写）可按 CPU 使用率排序，但默认刷新间隔 3 秒，短时脉冲可能错过；可临时改：按s输入1设为 1 秒刷新 - 注意
top的%MEM和%CPU是采样周期内的平均值，不是瞬时值；高%MEM但低%CPU的进程大概率是缓存型服务（如 redis），不算“运行中任务” -
htop需单独安装（sudo apt install htop或yum install htop），它不依赖/proc实时解析，对高负载系统更稳定
systemctl list-units --type=service --state=running 不等于“正在运行的任务”
这是最容易混淆的点：systemd 服务状态为 running，只表示该 unit 被激活且主进程没退出，不代表其内部逻辑正在执行。比如一个 cron 服务，systemctl is-active cron 返回 active，但它大部分时间处于 S（Sleeping）状态，只在定时器触发时才变成 R。
- 查服务对应的真实进程：
systemctl show -p MainPID servicename得到 PID，再用ps -o pid,comm,state,%cpu -p PID看实际状态 - 想确认服务是否“此刻在干活”，不能只看
systemctl status servicename里的 Active: active (running)，得结合ps或journalctl -u servicename --since "1 minute ago"看最近日志有没有新条目 - 某些服务（如 nginx）启多个 worker 进程，
systemctl只显示主进程状态，worker 进程的R/S状态需单独查
ps 里 STAT 是 R，但 %CPU 为 0，jobs -r 也抓不到。这种边界情况只能靠多次采样或 strace 观察调度行为，日常运维中通常忽略。
