Docker compose commands being run within turbo fails to stop the container after exiting the task with cntrl+c

[dBianchii]

Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/dBianchii/docker-turbo-pnpm-issue-reproduction

Which canary version will you have in your reproduction?

2.4.3-canary.3

Enviroment information

CLI:
   Version: 2.4.3-canary.3
   Path to executable: /Users/gabrielbianchi/Documents/Github/docker-turbo-pnpm-issue-reproduction/node_modules/.pnpm/[email protected]/node_modules/turbo-darwin-arm64/bin/turbo
   Daemon status: Running
   Package manager: pnpm9

Platform:
   Architecture: aarch64
   Operating system: macos
   WSL: false
   Available memory (MB): 9556
   Available CPU cores: 12

Environment:
   CI: None
   Terminal (TERM): xterm-256color
   Terminal program (TERM_PROGRAM): vscode
   Terminal program version (TERM_PROGRAM_VERSION): 1.97.2
   Shell (SHELL): /bin/zsh
   stdin: false

Expected behavior

Let's say that packages/db has a docker-compose.yml file with simple postgres service. Let`s say this package has a package.json like this:

"dev": "docker compose up --build"

When I run turbo dev from the root, this command will be run in parallel with my other dev scripts. This is what I want.
When I am done with working with my task and hit cntrl+C in my terminal, the docker container should be stopped.

Actual behavior

The docker container described in the scenario above is not exiting when I hit cntrl+c

To Reproduce

1. Clone https://github.com/dBianchii/docker-turbo-pnpm-issue-reproduction
2. Install deps
3. Make sure you have docker installed
4. turbo dev
5. Make sure the container is running on your machine
6. Close the process with cntrl+c
7. You will see that the container is still running

Additional context

Here is my docker info:

Client:
Version: 27.5.1
Context: desktop-linux
Debug Mode: false
Plugins:
ai: Ask Gordon - Docker Agent (Docker Inc.)
Version: v0.7.3
Path: /Users/gabrielbianchi/.docker/cli-plugins/docker-ai
buildx: Docker Buildx (Docker Inc.)
Version: v0.20.1-desktop.2
Path: /Users/gabrielbianchi/.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.32.4-desktop.1
Path: /Users/gabrielbianchi/.docker/cli-plugins/docker-compose
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.38
Path: /Users/gabrielbianchi/.docker/cli-plugins/docker-debug
desktop: Docker Desktop commands (Beta) (Docker Inc.)
Version: v0.1.4
Path: /Users/gabrielbianchi/.docker/cli-plugins/docker-desktop
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.2
Path: /Users/gabrielbianchi/.docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.27
Path: /Users/gabrielbianchi/.docker/cli-plugins/docker-extension
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.5
Path: /Users/gabrielbianchi/.docker/cli-plugins/docker-feedback
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.4.0
Path: /Users/gabrielbianchi/.docker/cli-plugins/docker-init
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /Users/gabrielbianchi/.docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.16.1
Path: /Users/gabrielbianchi/.docker/cli-plugins/docker-scout

Server:
Containers: 13
Running: 0
Paused: 0
Stopped: 13
Images: 11
Server Version: 27.5.1
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
runc version: v1.1.12-0-g51d5e946
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
cgroupns
Kernel Version: 6.12.5-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: aarch64
CPUs: 12
Total Memory: 7.653GiB
Name: docker-desktop
ID: d03d7f68-28be-48a2-95c9-4ebf0fb01b87
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Labels:
com.docker.desktop.address=unix:///Users/gabrielbianchi/Library/Containers/com.docker.docker/Data/docker-cli.sock
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false

[dBianchii]

Please note that it is possible that this is not a bug and actually expected behavior.
It is also possible that this is a problem in docker and not actually related to turborepo.

I am just trying to have a quick database to be spun up when I run my dev scripts, and for it to go down when I stop developing. This should be quite a common scenario/setup so it's possible my setup is wrong in some way.

[dBianchii]

I have just verified that this is problem is not happening on my Ubuntu linux machine. Only MacOS.

Here's the docker info installed at my linux system:

docker info
Client: Docker Engine - Community
 Version:    27.5.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.20.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.32.4
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 288
 Server Version: 27.5.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
 runc version: v1.2.4-0-g6c52b3f
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.8.0-52-generic
 Operating System: Ubuntu 24.04.1 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 31.13GiB
 Name: gabriel-ubuntu
 ID: b3902fe4-49b0-4649-8a84-77e9f8390dff
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

[chris-olszewski]

It is also possible that this is a problem in docker and not actually related to turborepo

I've been able to reproduce this on my macOS. There's something odd with docker compose where the process seems to exit immediately after receiving SIGINT and another process ends up writing the shutdown to the terminal. Looking to see if I can figure out the exact sequence of events as to why the shutdown is getting interrupted.

[betaorbust]

I'm also seeing this on Mac and only with Turborepo. Tried to do a JS-only implementation of what I had in a package.json script in a workspace, but still saw the early exit (with code 130) when using turborepo.

Click to expand code example 👈

import { spawn } from "child_process";
import path from "path";

const spawnOptions = {
  stdio: "inherit",
  cmd: path.resolve(__dirname, "../"),
} as const;

spawn(
  "docker",
  ["compose", "-f", "./docker-compose.dev.yml", "up"],
  spawnOptions,
);

const cleanup = () => {
  console.log("Cleaning up...");
  new Promise((resolve) => {
    const downProcess = spawn(
      "docker",
      ["compose", "-f", "./docker-compose.dev.yml", "down"],
      spawnOptions,
    );

    downProcess.on("close", (code) => {
      resolve(true);
    });
  }).catch((err: unknown) => {
    console.error("Error cleaning up", err);
  });
};

["SIGINT", "SIGTERM", "SIGQUIT"].forEach((signal) => {
  process.on(signal, cleanup);
});

What's interesting is that if I run npm workspace=my-workspace dev:db it totally works as expected and docker is closed out.

With turbo watch dev:db it immediately exits after getting a sigterm.

In the console I see the cleanup script get called