Site icon New Generation Enterprise Linux

Stop your container entrypoint from burying the signal

Container & Kubernetes Internals

Stop your container entrypoint from burying the signal

Technical Briefing | 10/26/2026

You probably have an entrypoint script that does a few checks before kicking off your primary application process. It logs environment variables, waits for a database to become ready, or generates a config file from a template. Everything seems fine until you try to send a SIGTERM to stop the container gracefully, and the application just sits there until the orchestrator loses its patience and hits it with a SIGKILL. You lost your graceful shutdown window because your shell script didn’t pass the signal to the child.

The shell swallows your signals

When you run a command via a shell script, the shell becomes PID 1 inside your container. By default, shell scripts don’t propagate signals to the processes they spawn. If you send a SIGTERM to the container, it hits the shell, but the shell just ignores it or terminates without telling your app to finish its tasks. You need to use exec, which replaces the shell process with your application process. This way, your app becomes PID 1 and receives the signal directly from the kernel.

exec python3 app.py
  • If you do not use exec, your app will never see the SIGTERM intended for it
  • Orphaned child processes may be left hanging if the shell just exits
  • PID 1 is special and must reap zombie processes or the kernel will not allow it to terminate properly

When you absolutely have to wrap the process

Sometimes you cannot avoid a wrapper script, like when you have to run multiple setup tasks that cannot be handled by your orchestrator. In those cases, you need to trap the signals manually within your script and forward them to the child process. It is a bit of extra plumbing, but it is the difference between a clean production rollout and a cluster of pods stuck in a terminating loop. Check the signal handlers in your shell script and make sure they pass the termination signal to your backgrounded application process.

Take a look at your next container build and check if your entrypoint actually spawns the main process as a child or replaces itself. If you see the application running as a child of a shell script in ps output, you have some work to do before that next deployment rolls out.

Linux Admin Automation  |  © www.ngelinux.com  |  10/26/2026
0 0 votes
Article Rating
Exit mobile version