如何Docker化启动多进程后即退出的第三方应用？

这种应用完全可以容器化，无需立即联系供应商修改架构，下面针对你的问题逐一解决：

1. 修复Entrypoint脚本的挂起问题 #

你的脚本挂起大概率是因为tail -f未找到目标日志文件，或者信号处理逻辑存在漏洞。以下是修正后的脚本：

#!/bin/bash
set -euo pipefail

# 提前创建日志目录并初始化日志文件
mkdir -p /opt/app/logs
touch /opt/app/logs/app.log
chown app:app /opt/app/logs/app.log

# 启动DBus服务（若应用依赖）
dbus-daemon --system --print-address &

# 定义清理函数，处理容器停止信号
cleanup() {
    echo "Triggering application cleanup..."
    /opt/app/entrypoint --terminate
    exit 0
}

# 注册容器停止时的常见信号：SIGINT（Ctrl+C）、SIGTERM（docker stop默认信号）、SIGQUIT
trap cleanup SIGINT SIGTERM SIGQUIT

# 切换到app用户启动应用，引号包裹$*避免参数拆分异常
su - app -c "/opt/app/entrypoint $*"

# 用tail -F跟踪日志（大写F支持日志文件被重建后继续跟踪）
tail -F /opt/app/logs/app.log

关键修改说明： #

• 提前初始化日志文件并设置权限，避免tail因文件不存在而异常挂起
• 补充SIGTERM信号捕获，确保Docker执行stop命令时能触发清理逻辑
• 用tail -F替代tail -f，适配应用可能重建日志文件的场景
• 启用set -euo pipefail增强脚本健壮性，及时暴露静默错误

2. 解决日志无法追踪的问题 #

你之前的ln -sf /proc/1/fd/1 /app/log/app.log未生效，大概率是因为应用启动前日志文件已被创建，软链接无法覆盖已存在的文件。可替换为以下两种方案：

方案A：启动前强制创建软链接 #

# 在启动应用前执行
rm -f /opt/app/logs/app.log
ln -sf /proc/1/fd/1 /opt/app/logs/app.log
chown -h app:app /opt/app/logs/app.log

-h参数确保修改软链接本身的权限，而非指向的标准输出文件。

方案B：后台实时转发日志 #

如果应用会动态创建或轮换日志文件，可添加后台进程实时转发日志到标准输出：

# 在启动应用前启动日志转发进程
su - app -c "tail -F /opt/app/logs/app.log > /proc/1/fd/1 2>&1" &

3. 确保进程清理的可靠性 #

由于原entrypoint启动进程后直接退出，无法通过wait跟踪子进程，但供应商提供的/opt/app/entrypoint --terminate是标准清理方式，只要确保信号能传递到脚本即可：

• 确保脚本是容器的PID 1进程（Docker默认会将entrypoint设为PID 1）
• 避免在脚本中使用exec启动子进程，否则信号会被拦截无法触发清理函数

额外优化建议 #

• 在Dockerfile中直接设置USER app，减少脚本中用户切换的操作
• 添加健康检查，通过检查共享内存文件或关键进程是否存在来判断应用状态
• 如果应用强依赖DBus，可将DBus启动逻辑加入Dockerfile的RUN指令或启动脚本

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