If the process does not exist, the error message of `kill` command is a
little bit confusing:
`kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]`
Using `killall` in `/s6/debian-root/etc/services.d/pihole-FTL/finish` to
kill the process, like what we do in `cron/finish` & `lighttpd/finish`,
will make the usage in this project more consistent, and also, the
command `killall` will provide better & friendly output, like:
`pihole-FTL: no process found`
Close#986, cc #973
Signed-off-by: Peter Dave Hello <hsu@peterdavehello.org>
- reorder some stuff in the main Dockerfile
- Remove the CORE/WEB/FTL_VERSION args/env vars
- tweaks to GHA build script after some hints from @crazy-max
- always checkout dev versions of Pi-hole for nightly build, also make sure we're using dev branch of this repo
- keep pihole checkout enabled for dev and nightly tags
Signed-off-by: Adam Warner <me@adamwarner.co.uk>
Since piholeFTL test properly spins down it's no longer
necessary to kill it. He's dead Jim
Merge #300, added `piholeFTL test` to the startup sequence to
replace dnsmasq as a dependency for validate_env and gravity.sh.
kill -9 was kept as a work around to a standing issue that
`piholeFTL test` didn't spin down on it's own. This was fixed
in pi-hole/FTL#1067, landed on Apr 14 2021 and confirmed
working, as evinced by #834 which was filed the same day it
that fix landed.
Signed-off-by: D.Rect <48034372+DistractionRectangle@users.noreply.github.com>
piholeFTL exposes configuration to relocate/rename gravityDB so
we cannot just check a hard coded location. This commit greps
pihole-FTL.conf for a custom location. Since pihole-FTL.conf
will eventually be replaced by TOML, some verbosity is added to
denote what config file is being checked and what location it
ultimately ended up checking.
Signed-off-by: D.Rect <48034372+DistractionRectangle@users.noreply.github.com>
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>