Packer构建OpenVAS Scanner Ubuntu AMI时脚本执行完成后为何挂起

根本原因 #

挂起的核心触发逻辑和你提到的移除-F参数无关，主要由两个机制叠加导致：

• Packer 的 shell provisioner 判定命令执行完成的标准，不是远程Shell父进程的退出码，而是对应SSH通道的stdout、stderr管道没有任何进程持有写端，收到文件EOF信号后才会结束provision流程。
• 脚本中启动ospd-openvas的命令没有做完全的后台隔离：虽然ospd-openvas作为常驻服务完成了Socket初始化，让后续的while检测循环、chmod权限设置、所有echo提示都正常执行完成，但这个常驻进程默认继承了当前SSH会话的stdout/stderr文件描述符，一直持有管道写端，导致Packer永远等不到EOF信号，流程就一直卡在等待状态。
• 脚本末尾的tail /usr/local/var/log/gvm/*命令本身不会造成永久阻塞（无-f参数的tail读取完文件最后几行就会退出），但因为后台的ospd-openvas进程没有释放管道，整个会话会一直保持激活，表现为所有步骤输出完成后流程无响应。

修复步骤 #

1. 修正ospd-openvas的启动逻辑
   把启动命令改为完全脱离当前会话的后台运行模式，断开和SSH管道的关联：

   ospd-openvas --log-file /usr/local/var/log/gvm/ospd-openvas.log --unix-socket /data/ospd.sock --log-level INFO \
     < /dev/null > /dev/null 2>&1 &
   

   关键改动：
   • 末尾加&将进程放到后台运行，避免阻塞父Shell流程
   • 重定向进程的stdin、stdout、stderr到/dev/null，彻底断开和当前SSH会话的管道关联，避免Packer一直等待未关闭的管道
2. 修正末尾的日志读取命令
   指定tail读取的行数，避免意外扫描大日志文件造成阻塞：

   tail -n 20 /usr/local/var/log/gvm/*.log
   

3. 生产优化建议
   如果AMI启动后需要自动运行ospd-openvas，不要在Packer构建阶段直接启动进程，应该配置对应的systemd服务单元，把进程托管给系统管理。这样构建阶段不会启动任何常驻进程，从根源上避免管道泄漏导致的挂起问题。

内容的提问来源于stack exchange，提问作者Dylan