S6 no longer in image

[PromoFaux]

Hey, i am not sure if this is exactly my issue, but i contributed to a separate docker image based on the official pihole:latest image and am now trying to update it to the latest changed. In the past the image used /etc/services.d/ to start other services separately from running the main pihole entrypoint without overwriting anything. This was a very good and working approach, but now i cannot use this anymore, because it seems like the alpine image does not contain any kind of init system.
I tried changing the entrypoint (which i really do not want to do, as i do not want to interferre with the entrypoint of the base pihole image) but that did not work either, i kept getting errors, that it couldnt start and stopped the container.

Therefore could you please add an init system OR add a mechanic do expand the startup of the image maybe through additional scripts in a specific directory.

Originally posted by @Joly0 in #1701

[PromoFaux]

@Joly0 - created a new issue because the discussion is not on topic to the issue you tacked onto .

This is not likely to happen, I'm afraid. V6 was a chance to redesign the image from the ground up, and as we no longer need to run multiple binaries, we no longer needed the s6 init system. This also is more in fitting with the "docker way" of doing things, which is one service per container.

Take a look at projects such as this one https://github.com/klutchell/balena-pihole, where additional services are added in a stack, rather than injecting them into a single monolithic image.

[Joly0]

Hey @PromoFaux thank your for creating a separate issue. I have looked through various github issues to see, how others are creating their adjusted image and most of them (if not all of them now) create a separate wrapper script, that overwrites the default start.sh script, executes the custom stuff and in the end usually executes the start.sh. Also balena-pihole uses docker-compose, which is not always a good solution in my opinion and is not always available as a choice.

While all in all this is a solution one could use and is working, i dislike this approach, because you have to keep track of the upstream (meaning the repo here pi-hole/docker-pi-hole) and check regularly if the entrypoint has changed, which is not super likely but can happen and would probably break the container one created.

I do understand the issue regarding one service per container and that this project no longer needs an init system, but it makes it harder to built on top of it and create separate images based on your great work here. Also, and this is only my personal opinion, an init system does not violate the "one service per container" rule, because it is not really a service itself, but part of another service. The init system is only needed to start and gracefully stop the actual services in a way, so no zombie processes are left behind. Even docker themselves recommend using a proper init system. But of course i understand, that an init system would require a slightly larger image from you and would require some more work to keep the init system itself up to date.

So while it is ok for me, that this image does no longer have an init system, it would be great to have some kind of extendability. I mentioned already, that the start.sh script could also be extended in a way to load scripts in a specific folder on startup, like linuxserver.io images do https://docs.linuxserver.io/general/container-customization/#custom-scripts atleast that way users could built upon the pi-hole image without interferring with the way it starts and manages itself.

[yubiuser]

We could use tini as init system (it adds almost nothing), using it as entrypoint and run start.sh as CMD

[PromoFaux]

0.1 MB in fact.

We did have tini, but it was removed because... well, it wasn't actually doing anything.

I wonder if people that wanted to use this container as a base could use the built-in docker support for tini...

https://docs.docker.com/reference/cli/docker/container/run/#init