如何在Docker容器停止/关闭前执行自定义清理命令？

I’ve run into this exact union filesystem residue issue before, so let’s break down why your previous attempts didn’t work and fix this properly.

Why Your Existing Approaches Failed #

1. Appending commands to entrypoint: When you chain commands like entrypoint; cleanup, the cleanup only runs if the entrypoint exits normally. But Docker sends SIGTERM (default) to the PID 1 process to stop the container—if PID 1 is your main app (not the shell), the shell gets killed immediately before it can execute the cleanup.
2. Trap with STOPSIGNAL SIGINT: Chances are your main process wasn’t being waited on by the shell, or you used exec to launch the app (which replaces the shell process, losing all trap handlers). Docker defaults to sending SIGTERM first, so setting STOPSIGNAL SIGINT meant you missed the initial termination signal.

Working Solutions #

1. Proper Shell Entrypoint with Trap & Wait #

This is the most reliable method. Create a shell script as your entrypoint that handles signal trapping, runs your main process, and triggers cleanup on any termination signal.

Step 1: Create the Entrypoint Script (/entrypoint.sh)

#!/bin/bash

# Define your cleanup logic
cleanup() {
    echo "Cleaning up union filesystem mount..."
    if fusermount -uz /mount/point; then
        echo "Successfully unmounted /mount/point"
    else
        echo "Warning: Failed to unmount /mount/point" >&2
    fi
    exit 0
}

# Trap all common termination signals
trap cleanup SIGINT SIGTERM SIGQUIT SIGABRT

# Launch your main application (run in foreground so the shell stays active)
echo "Starting main application..."
your_main_app_command_here

Step 2: Update Your Dockerfile

# Copy the entrypoint script into the container
COPY entrypoint.sh /entrypoint.sh

# Make it executable
RUN chmod +x /entrypoint.sh

# Set the entrypoint and default command (adjust CMD if your app needs arguments)
ENTRYPOINT ["/entrypoint.sh"]
CMD ["your_main_app_command_here"]

Key Notes:

• Don’t use exec for your main app: exec your_main_app replaces the shell process with the app, which discards all trap handlers. Let the shell run the app as a child process.
• Stick with default STOPSIGNAL: Docker sends SIGTERM first (with a 10-second grace period), then SIGKILL if the process doesn’t exit. Our trap handles SIGTERM, so cleanup will trigger before the container shuts down.
• Extend grace period if needed: If cleanup takes longer than 10 seconds, add stop_grace_period: 30s to your docker-compose.yml or use docker stop --time 30 <container-name>.

2. Use dumb-init for Robust Signal Forwarding #

If your main app ignores signals or you want a more reliable PID 1 process, use dumb-init—a lightweight init system designed for containers that properly forwards signals to child processes.

Step 1: Install dumb-init in Your Dockerfile

# For Debian/Ubuntu-based images
RUN apt-get update && apt-get install -y --no-install-recommends dumb-init

# For Alpine-based images
RUN apk add --no-cache dumb-init

Step 2: Update Entrypoint to Use dumb-init

Modify your Dockerfile to set dumb-init as the entrypoint, which will launch your shell script:

ENTRYPOINT ["dumb-init", "--", "/entrypoint.sh"]
CMD ["your_main_app_command_here"]

This ensures signals are correctly passed down to the shell, which will trigger your cleanup trap even if your main app doesn’t handle signals well.

3. Test the Setup #

To verify cleanup runs as expected:

1. Start the container
2. Stop it with docker stop <container-name>
3. Check logs with docker logs <container-name>—you should see your cleanup messages.

Final Checks #

• Ensure /mount/point exists in the container and is mounted before cleanup runs.
• If your cleanup command requires elevated privileges, run the container as root or a user with mount permissions (avoid sudo unless absolutely necessary).

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