prdtn
March 27, 2018, 5:33pm
1
Expected Behaviour:
active (running)
Actual Behaviour:
Although I dont have any problems its kinda weird and I wonder if I have to worry about the exited FTL service.
pihole status
systemctl status pihole-FTL
Debug Token:
igwvjdtyq0
//edit: The only issue I'm having is that pihole -up always tells me there is an update for FTL but after updating the update is available again and again and ...
pihole -up
[i] FTL out of date
[i] FTL Checks...
[i] Web Interface: up to date
[i] FTL version is now at
Thanks
DL6ER
March 27, 2018, 6:24pm
3
I agree, due to historical reasons, we are using an init.d script. We could look into changing it to systemd, but this may lead to additional problems. @DanSchaper would our lowest supported OS be fine with us switching to a systemd unit file?
1 Like
prdtn
March 27, 2018, 6:46pm
4
at least for me init.d is also fine but im getting:
/etc/init.d/pihole-FTL status
Directly supported, they pretty much are all on Systemd. But there are a number of heavily used, but user supported installations that run in chroot jails and those tend to be sysvinit still. So we could try to detect the running init system and install the correct scripts, but I can see that getting pretty messy to handle.
1 Like
sysvinit still works fine. I'm a fan of systemd but I agree there is a large section of the community that may make things more difficult for.
DL6ER
April 14, 2018, 9:32am
8
This problem should be resolved by
pi-hole:development ← pi-hole:FTLDNS-systemd
opened 09:31AM - 14 Apr 18 UTC
**By submitting this pull request, I confirm the following:**
*please fill any… appropriate checkboxes, e.g: [X]*
- [x] I have read and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md), as well as this entire template.
- [x] I have made only one major change in my proposed changes.
- [x] I have commented my proposed changes within the code.
- [x] I have tested my proposed changes, and have included unit tests where possible.
- [x] I am willing to help maintain this change if there are issues with it later.
- [x] I give this submission freely and claim no ownership.
- [x] It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1)
- [x] I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
Please make sure you [Sign Off](https://github.com/pi-hole/pi-hole/wiki/How-to-signoff-your-commits.) all commits. Pi-hole enforces the [DCO](https://github.com/pi-hole/pi-hole/wiki/Contributing-to-the-project).
---
**What does this PR aim to accomplish?:**
Replace the ancient `init.d` script for starting and controlling the `pihole-FTL` process by a modern `systemd` unit. This should resolve some problems as discussed [here](https://discourse.pi-hole.net/t/service-pihole-ftl-active-exited/8335) or [here](https://discourse.pi-hole.net/t/pihole-ftl-is-working-but-webmin-says-the-service-is-not-running/8368).
This now also makes the `status` command behave correctly, as `systemd` can use the PID file of FTL to find out if it is actually running or not:
Also, since *FTL*DNS is a very important part of your system, the unit ensures that it will be automatically restarted whenever something unexpected happens. As an example, I sent `SIGKILL` to FTL and as you can see, `systemd` took care about immediately restarting the service:
Note that we do not restart `pihole-FTL` automatically after having received `SIGTERM` as this is the correct way of terminating the resolver (e.g. through `service pihole-FTL stop`).
**How does this PR accomplish the above?:**
I wrote a systemd unit for `pihole-FTL` and modified the installer to replace the old init.d script.
**What documentation changes (if any) are needed to support this PR?:**
All commands should work as before.
2 Likes
system
May 5, 2018, 9:32am
9
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.