Fix for pihole-FTL test

[DL6ER]

By submitting this pull request, I confirm the following:

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.

How familiar are you with the codebase?:

10

---

Fix a few issues revealed when checking why pihole-FTL test doesn't work as expected:

1. The test option is currently broken: It immediately terminates all FTL components (threads surrounding the resolver, etc.), however, it did not terminate the resolver itself leading to an attempt to kill the resolver in the docker container.
2. The log file lock should be shared among processes to ensure we cannot outpace forks (which may result in a log deadlock). This may fix dhcp-script not being called in v5.1.2 #906 as byproduct of our improvements in here
3. We should not detach threads we want to cancel explicitly later on when terminating
4. Ensure we clean up behind us on crashes and fatal errors (such as port 53 not available, dnsmasq config errors, etc.)
5. Improve process-already-running detection (better formatting)

This fixes #1063 and #1064

[DL6ER]

Confirmed working by original reporter in #1063

[dschaper]

Any changes needed or suggested for the Docker image?

[DL6ER]

Not needed but we should get rid of the kill -9 now being obsolete after we fixed the test command here.

@PromoFaux already added TODOs:

• https://github.com/pi-hole/docker-pi-hole/blob/8d57c8ce7b8983edd39cb65111b40e63c3f63775/s6/debian-root/etc/cont-init.d/20-start.sh#L24
• https://github.com/pi-hole/docker-pi-hole/blob/8d57c8ce7b8983edd39cb65111b40e63c3f63775/s6/debian-root/etc/services.d/pihole-FTL/finish#L4

but I am not in the position to make a PR as I have never used the Pi-hole docker container and wouldn't know if getting rid of them without replacement is the right thing to do. I'm however sure that KILL is always wrong, TERM should work as well and is to be preferred (we can clean up behind up, store the last queries into the database, etc.).

[Beanow]

Yes, I think we can at least step down to TERM.
The one that's in 20-start.sh can probably removed completely.

Instead, in bash_functions.sh we might use a blocking test, rather than anticipating a daemon to kill.

pihole-FTL -f test was something I tested at #1065 and does indeed behave differently.
Though we might want to look into how to handle it's logs (which like -f / no-daemon go to stdio).

# Perhaps wrap it to be quiet unless it fails?
pihole-FTL -f test &> /var/logs/pihole-FTL.test.log
RES=$?
if [[ $RET != 0 ]]; then
    cat /var/logs/pihole-FTL.test.log
fi

---

One thing I would suggest looking into though is this:
For starting the process a cleanup has been added https://github.com/pi-hole/docker-pi-hole/blob/20cd9c3abf95e00d2d1920ba432e2a0272c42942/s6/debian-root/etc/services.d/pihole-FTL/run#L4-L6

This makes sense, because the service will to endlessly try to restart in case it fails to start initially. It's a great feature to have to make it low maintenance and self-healing, even if it isn't the most elegant in implementation details.

Because in a sense, we're doing a very similar cleanup as we'd want FTL to do on a clean shutdown, perhaps this is redundant code and we could use a pihole-FTL cleanup or pihole-FTL --force no-daemon argument so that knowledge about how to clean up doesn't go out of sync?

[pralor-bot]

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/pi-hole-ftl-v5-8-web-v5-5-and-core-v5-3-released/46237/1