Proposed solution to #834
I believe the correct way to solve this issue is to change when "Gravity on Boot" is run.
The s6 init system has different stages. Currently, "gravity on boot" is run during Stage 2.ii: cont-init.d. One instance of pihole-FTL is started during cont-init, but it is only there to check the validity of the config files; it exits soon after starting. The final "service mode" instance of pihole-FTL is not started until Stage 2.iii, when the supervisor starts doing work.
If gravity.sh is counting on FTL to do its DNS lookups, then we should not run gravity until the supervised instance of FTL is running. We can accomplish this by moving "Gravity on Boot" to a @reboot line in /etc/cron.d/gravity-on-boot, and making that file's existence dependent on the value of SKIPGRAVITYONBOOT.
This will work because cron isn't started until we've reached Stage 2.iii.
Signed-off-by: Matt Winter <MattWinter@gmail.com>
- Add a new container environment variable allowing to specify the user to run the pihole-FTL process as. Defaults to root.
- Set inherited capabilities attributes on the pihole-FTL file to automatically grant runtime permitted capabilities when available in the bounding set. This allows dropping root before starting pihole-FTL without failing with a permission error if the capabilities are not available to the container (the process may still error out if performing an operation requiring the capability).
- Add some information on capabilities to the Readme file.
Signed-off-by: Mathieu Hofman <86499+mhofman@users.noreply.github.com>
* Tests are passing, hopefully consistently
* FTL pulling from official releases
* thanks @DL6ER for the musl-libc build
* Thanks middleagedman for the IPv6 fixes
* Thanks everyone for patience while I get this release working!
