Certbot 按 Ctrl+Z 后报 Another instance of Certbot is already running

在 Certbot 的交互提示处按了 Ctrl+Z，终端回到命令行；再次运行却出现：

Another instance of Certbot is already running.

在启用作业控制的 Linux 交互式 Bash 中，默认的 Ctrl+Z 会暂停前台任务。旧 Certbot 进程仍然存在，也可能继续持有目录锁。重新打开一个终端或再运行一次相同命令，不会让原任务退出。

下面只处理“刚暂停过 Certbot，且原 shell 还在”的情况。这个报错本身只能说明锁被另一个进程持有，不能单独证明有人按过 Ctrl+Z；自动续期任务正常运行时，也可能与手动命令冲突。

在原来的 shell 中找到停止的任务

回到启动 Certbot 的那个终端，在同一个 shell 执行：

jobs -l

核对任务的完整命令、编号和状态。输出应能对应到刚才的 Certbot 命令，并显示 Stopped 或本地语言对应的停止状态。jobs 是 shell 自己维护的任务表，另开终端后列表为空，不能用来证明整台机器没有 Certbot 进程。

任务编号和进程 PID 不是同一个概念。假设核对后确认停止的 Certbot 是任务 1，才使用：

fg %1

%1 必须换成刚查到的实际任务编号。不要随便对当前默认任务执行 fg，以免恢复另一项维护操作。fg 会把该任务恢复到前台，并从暂停处继续执行；这一步本身并不是取消。

恢复后完成原任务，或明确中止它

如果只是误按了暂停键，可以继续处理原来的交互提示。若目的是取消这次申请或安装，恢复前台后使用程序提供的取消选项，或按 Ctrl+C 请求中断，然后等待 Certbot 退出并返回 shell。不要再次按 Ctrl+Z，也不要立即并发启动第二次申请。

Certbot 可能在暂停前已经执行过部分操作。恢复任务会继续这些步骤；取消也不能当作“所有文件都回到操作前”。如果当时正在调整 Apache 或 Nginx 配置，应保留 Certbot 日志，核对服务配置与当前服务状态，必要时按操作前的备份恢复。

再次运行 jobs -l，确认对应任务不再处于停止或运行状态，再按原计划重试需要的 Certbot 操作。锁错误消失只表示这次互斥冲突解除；原来的虚拟主机选择、域名验证或证书部署问题仍要分别确认。

不要靠删除锁文件恢复并发写入

Certbot 会保护它使用的配置、工作和日志目录。默认路径通常是 /etc/letsencrypt、/var/lib/letsencrypt 和 /var/log/letsencrypt；Apache、Nginx 插件还可能锁住对应服务的配置目录。

Linux 下的锁与进程打开的文件有关。停止的进程没有退出，锁也不会因为终端出现提示符而自然释放。直接删除 .certbot.lock 不能把这个进程变成已结束任务，反而可能破坏多个实例之间的互斥，让它们同时修改相同资料。

这一场景不需要批量删除锁、杀掉全部 Python 进程，或另换一套空配置目录绕过报错。改目录可能使 Certbot 看不到原证书和续期状态；即使新命令能启动，也没有解决旧任务仍占用资源的问题。

如果原 shell 已关闭，或者 jobs -l 找不到对应任务，就停止沿用 %1 示例。应转而核对实际运行的 Certbot 进程及其启动者，区分另一个终端、计划任务和服务管理器。正常执行中的续期应等待完成；只有确认了具体任务的用途和影响，才能按该任务的管理方式结束它。不要凭一个锁文件名判断进程已经失效。

处理后保留原证书、私钥与续期配置。若本次任务确实完成了签发或安装，再核对目标服务加载的证书；解除进程锁不会自动修复已经失败的验证，也不会替服务重新加载证书。