bg 提示“no current job”或失败的根本原因是当前 shell 会话中不存在已暂停（Stopped）且仍存活的作业；bg 仅能恢复被 Ctrl+Z 暂停、尚未退出且属于本会话的作业，对 & 启动的进程、已结束作业或非本会话进程均无效。

为什么 bg 有时提示 “no current job” 或直接失败

根本原因不是命令写错了，而是当前 shell 没有挂起（SIGTSTP）的作业——bg 只能重启已暂停、且仍属于当前 shell 会话的作业。

常见误操作包括：

• 用 & 启动的进程默认是前台运行后立即转入后台，它从没被暂停过，所以 bg 对它无效
• 按 Ctrl+Z 后没执行 bg 就又输了一条新命令，shell 会把刚挂起的作业标记为“非当前”，此时 bg 默认操作对象丢失
• 作业已在后台运行完毕或被 kill 掉，jobs 列表里看不见，自然不能 bg

验证方式：先执行 jobs，确认看到类似 [1]+ Stopped vim test.txt 的输出，再运行 bg %1（注意带作业号和百分号）。

jobs 显示的 +、- 和数字编号到底代表什么

这些符号不是随机生成的，而是 shell 维护的一个**作业栈顺序标识**：

• + 表示最近一次挂起或启动的作业（即默认操作对象，fg 或 bg 不带参数时作用于此）
• - 表示倒数第二次的作业，再往前的作业只显示编号（如 [2]、[3]），不标符号
• 编号（如 %1、%2）是 shell 分配的唯一作业 ID，和 PID 不同，但可通过 jobs -l 查看对应 PID

例如：jobs -l 输出 [1]- 12345 Running sleep 100 &，说明该作业编号为 1，PID 是 12345，状态是 Running —— 此时对它执行 fg %1 会把它拉回前台并阻塞当前终端。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

用 fg 切换作业时终端卡住或报 “No such job” 怎么办

卡住通常是因为目标作业本身在读取 stdin（比如 vim、read、交互式 python），而你又没给它输入；报错则多因作业已退出或编号记错。

• 先运行 jobs 确认作业还在列表中，且状态不是 Done 或 Exit
• 如果作业是交互程序，fg 后要立刻按键（比如按 Enter 或 Esc）唤醒它，否则看起来像“卡死”
• 避免依赖记忆编号：用 fg %?（问号匹配名字）更安全，比如 fg %?http 会找到名字含 http 的最近作业
• 如果作业已退出但 jobs 还残留（罕见），执行 wait 可清空已完成作业记录

后台作业和系统级守护进程（daemon）不是一回事

很多人以为 nohup cmd & 或 bg 启动的就是“服务”，其实它们仍依赖当前 shell 的生命周期：

• 关闭终端（或 ssh 断连）时，未加 nohup/disown 的后台作业会收到 SIGHUP 并退出
• disown %1 可让作业脱离 shell 作业表，不再受 SIGHUP 影响，但它仍属于当前会话的进程组
• 真正长期运行的服务应使用 systemd、supervisord 或至少 nohup cmd > /dev/null 2>&1 & + disown

一个典型遗漏点：即使用了 nohup，如果忘了重定向 stdout/stderr，日志可能写入 nohup.out 并撑满磁盘 —— 生产环境务必显式指定输出路径。