SBT docker:Publish部署问题：应用崩溃但容器仍存活

你猜的没错，问题确实出在那个自动生成的bash启动脚本上！我之前碰到过好几个类似的案例，核心原因是默认的bash脚本没有让Java进程成为容器的PID 1进程，或者说bash进程在Java子进程崩溃后没有随之退出，导致Docker以为主进程还在运行，容器就一直处于“存活”状态。

下面给你三个实用的解决办法，按推荐优先级排序：

1. 直接让Java进程作为容器的PID 1（最直接） #

放弃使用自动生成的bash脚本，让Docker直接调用Java命令启动应用。这样Java进程就是容器的主进程（PID 1），一旦它崩溃，容器会立刻终止。

在你的build.sbt里添加以下配置：

dockerCommands := dockerCommands.value.flatMap {
  // 替换默认的CMD指令
  case cmd@Cmd("CMD", _) =>
    // 替换成你的主类全路径，类路径用/opt/docker/lib/*（这是sbt-native-packager默认的lib目录）
    Seq(Cmd("CMD", "java", "-cp", "/opt/docker/lib/*", "com.yourcompany.yourapp.Main"))
  case other => Seq(other)
}

2. 修改bash脚本，让它随Java进程退出（保留脚本便利性） #

如果你不想放弃bash脚本帮你处理类路径、环境变量的功能，可以修改脚本的启动逻辑，确保Java进程退出时bash也跟着退出。

关键是在启动Java的命令前加上exec，这样Java进程会替换bash进程（成为PID 1），而不是作为bash的子进程运行。在build.sbt里添加：

bashScriptExtraDefines += """exec "$@""""

这个配置会在生成的bash脚本末尾加上exec "$@"，让脚本执行传入的命令（也就是Java启动命令）时替换自身进程，这样Java崩溃后，容器的主进程也会终止。

3. 使用tini处理PID 1信号转发（通用方案） #

如果你的场景比较复杂（比如脚本里有多个子进程），可以用tini这个轻量级的初始化工具来处理PID 1的信号转发问题。它会帮你监控子进程，确保子进程退出时容器也随之停止。

在build.sbt里配置：

// 基于带apt的JRE镜像（比如openjdk的slim版本）
dockerBaseImage := "openjdk:17-jre-slim"

dockerCommands ++= Seq(
  // 安装tini
  Cmd("RUN", "apt-get update && apt-get install -y --no-install-recommends tini && rm -rf /var/lib/apt/lists/*"),
  // 设置tini为ENTRYPOINT
  Cmd("ENTRYPOINT", ["tini", "--"]),
  // 保持原来的CMD（启动bash脚本）
  Cmd("CMD", ["bin/the-app-name"])
)

这样tini会成为容器的PID 1进程，它启动bash脚本后会监控所有子进程，一旦Java应用崩溃，tini会收到信号并退出，容器也就跟着停止了。

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