Should we use an `init` process in our Dockerfiles?

[halfer]

I have this in a Dockerfile for one of my apps:

# This installs Tini at /sbin/tini (see https://github.com/krallin/tini)
# My Docker Compose is ancient, otherwise I'd do it in the DC YAML file
RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]

On system boot I get this in the logs. It doesn’t cause any start-up issues, it’s probably been there a year or so without my noticing:

 2025-09-02T05:41:39.251 app[185e629c45xxxx] lhr [info] [WARN tini (638)] Tini is not running as PID 1 and isn't registered as a child subreaper.

2025-09-02T05:41:39.251 app[185e629c45xxxx] lhr [info] Zombie processes will not be re-parented to Tini, so zombie reaping won't work.

2025-09-02T05:41:39.251 app[185e629c45xxx] lhr [info] To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1. 

I’m aware that the Fly init is injected as PID 1. What’s the best practice here; remove Tini and let Fly handle signals? It does mean that I’ll not have an init process locally, but it’s a minor grumble.

[rubys]

If you use containers, your processes will start as pid 1.

Using Containers with Flyctl

Previously: Docker without Docker, now with containers - at the time support was limited the to the Machine API and you needed to request access. We quietly lifted the requirement to request access, and as of flyctl Release v0.3.113 · superfly/flyctl · GitHub , we now have fly machine run and fly deploy support. There is a lot to explain, so a rate limiter demo was created that will walk you through what you need to know. If you have any questions, feel free to ask them here. Below is the cu…

[halfer]

OK, interesting. I will look into that at some point, but it is going to need some research.

So I will stick with Firecracker for now. On that basis, should I remove my init process?

[rubys]

That would depend on what you are using tini for. Typically, it would be to start and manage multiple processes. The closest equivalent might be Supervisord. See Multiple processes inside a Fly.io app · Fly Docs for options.

[halfer]

Ah no, I install it in pretty much all Dockerfiles; I used to use dumb-init for the same purpose. The rationale is that not all processes started as PID 1 (e.g. a Bash script) will process signals correctly, so one adds the init system at the top, to ensure that whatever gets run, it won’t need a kill signal to exit.

I think I picked it up as a good practice some years ago, but it has become reflexive, and I’ll drop it if it is no longer required (at Fly or in general).

[rubys]

My understanding: as you said, PID 1 may problematic with bash, causing signals not to be forwarded.

• Docker starts your command as pid 1. Init may be helpful here.
• Fly.io without containers starts your command as a pid other than 1. Init may be unhappy.
• Fly.io with containers starts your command as pid 1. Once again, init may be helpful here.

[lights0123]

Docker also ships tini, you can have it start tini as PID 1 for you without installing it in containers

[lillian]

our pre-containers pid1 handles signals correctly, you should not need to add dumb-init or tini in front of it. it’s not a problem to keep it there though!

fwiw, both regular init and pilot (containers) run inside Firecracker VMs.

[halfer]

Thanks, but I think the (non-containers) Fly PID1 process overrides it, per the guidance from @rubys and @lillian. This is what gives rise to the error in the OP.

I spot a plan, though; I think I can use Docker Compose to switch on the init flag for local development only, and then for remote (where I presently do not use containers), it will just use the Fly PID1, and my image will not attempt to run its own.