OS Reboot during pihole temporary blocking issue

[kuitog]

Versions

• Pi-hole: 5.18.3
• AdminLTE: 5.21
• FTL: 5.25.2

Platform

• OS and version: Ubuntu 22.04

• Platform: Ubuntu install

Expected behavior

I enable a temporary pause of blocking of 10 minutes.
I do a terminal sudo reboot.
When rebooting pihole should check if 10 minutes have passed and resume blocking.

Actual behavior / bug

When rebooting pihole loses the countdown and restarts with filtering permanently disabled. You have to manually go to the dashboard and reenable blocking.

Steps to reproduce

Steps to reproduce the behavior:

1.Set a 1 minute temporary filtering pause on the pihole dashboard
2. Ssh sudo reboot linux
3. Go to the pihole dashboard. The countdown is gone and blocking is disabled for good.

I suggest that when starting the countdown, the countdown end time should be written to the db, so that even if rebooting the countdown can be resumed.

[yubiuser]

With v6 the behavior is: A disabled timer will survive the reboot, but the timer is "forgotten" and blocking is disabled indefinitely.

[kuitog]

Ok, maybe not the best design.. Today I rebooted during a 10 minute pause and I was 3 hours without filtering. It could have been 3 days until I realized.

Doesn't make much sense to "forget" and disable something completely just because the system was rebooted.
For me pihole is very similar to a firewall, and you wouldn't want your firewall to do this..

[DL6ER]

Preamble: Usually, a long answer is not what you want. Such answers tent to try to explain you why what you want is not going to happen. This particular answer you're reading here is not that kind of answer - still it's not going to be fixed immediately.

TL;DR We will change the behavior to survive restarts but not now.

---

The full story:

We discussed this internally and agree that this a kind of design flaw but not a bug as such. The feature was never meant to be used across device or even across service restarts. As such, we don't consider it urgent to change/fix this, moreover, as this is the first report we're seeing in years. This is not saying it will not be changed.

During our internal discussion, it came apparent that there are several pitfalls so this needs to be well-tested before it can be released. As we are pretty far with our public Pi-hole v6.0 beta phase, we're rather looking at fixing this in the next release cycle, so v6.1. If everything works out well, this won't be in the too distant future, hopefully not very long after releasing v6.0.

Concerning the actual implementation:
Writing a (Unix) timestamp to the TOML directly seems wrong IMO, writing such a timestamp to the database info table (like suggested) seems a better idea. Then, on restart, we could import this value and actually restart the timer and blocking mode switches back as if there was no restart in between. This does not, however, address the situation where rebooting (or shutdown time) takes longer than the remaining timer delay - in this case we'd probably have to check if the value in the database has already passed and, if so, switch blocking mode immediately at the start of pihole-FTL + removing the timestamp from the database to avoid this happening on the next (re)start of pihole-FTL again.

Summarized: write the time end timestamp to the database, read it on startup. If now < end date restart the timer with the diff. If now >= end date switch the blocking mode and remove the database entry.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.