Package Details: pi-hole-ftl 4.1.2-1

Git Clone URL: https://aur.archlinux.org/pi-hole-ftl.git (read-only)
Package Base: pi-hole-ftl
Description: The Pi-hole FTL engine
Upstream URL: https://github.com/pi-hole/FTL
Licenses: EUPL-1.1
Conflicts: dnsmasq
Provides: dnsmasq
Submitter: max.bra
Maintainer: max.bra (graysky)
Last Packager: max.bra
Votes: 20
Popularity: 1.686944
First Submitted: 2017-05-07 15:23
Last Updated: 2018-12-21 22:28

Required by (56)

Sources (6)

Pinned Comments

DanSman commented on 2019-01-10 04:32

Hi

If someone has the same problem after the systemd update to 240.0-3.

dnsmasq/pi-hole-ftl couldn't start because systemd-resolved is using port 53.

I had to change:

/etc/systemd/resolved.conf

  • '#DNSStubListener=yes'
  • to
  • DNSStubListener=no

Thanks, Dan

max.bra commented on 2018-02-09 16:46

ArchLinux Pi-hole is not officially supported by Pi-hole project. In case of bugs and malfunctions please DO NOT file a report upstream. First of all check if the wiki (https://wiki.archlinux.org/index.php/Pi-hole) can help then ask here for assistance and tips. When it will be excluded that the problem does not depend on ArchLinux we will file a bug upstream.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

ChuckHL commented on 2019-01-17 16:12

Hi max.bra,

Thank you for the assistance. Just fixed what DanSman said and I was able to finish updating and working fine.

Thank you both.

max.bra commented on 2019-01-16 21:06

Hi ChuckHL, i don't think your problem it's related with packages you point at. I've same version of your problematic packets and my FTL starts. Take a look at pinned DanSman comment.

ChuckHL commented on 2019-01-16 17:06

I just upgraded my system and pihole-ftl is no longer starting.

I noticed that my system upgraded package bind-tools (bind-tools-9.13.0-2) and from that version, python3 is no longer optional, but required. It installed python-3.7.2-3 and my pihole-ftl is no longer starting.

I downgraded bind-tools to bind-tools-9.12.0-1 and removed python 3.7.2 and after rebooting, pihole was working fine.

Is there anything I need to fix so that I can reupdate bind-tools?

Regards

DanSman commented on 2019-01-10 04:32

Hi

If someone has the same problem after the systemd update to 240.0-3.

dnsmasq/pi-hole-ftl couldn't start because systemd-resolved is using port 53.

I had to change:

/etc/systemd/resolved.conf

  • '#DNSStubListener=yes'
  • to
  • DNSStubListener=no

Thanks, Dan

max.bra commented on 2019-01-01 10:30

@hakayova there was some type of problem with ftl systemd tmp file creation solved, exactly, by reinstallation of the package. the reason for all this will perhaps remain a mystery. good continuation.

hakayova commented on 2019-01-01 08:31

Thanks for your prompt reply max.bra! I did some troubleshooting via "sudo journalctl --system -u pihole-FTL.service" which complained about not being able to write PID to the file, socket to the file and connecting to the socket, etc. despite the fact that it was a system service run by root. Having seen so many problems, I reinstalled pi-hole-server and pi-hole-ftl via yaourt and was quite happy to see that it solved the problem. Not sure what caused the corruption, but it seems to be fixed now, fingers crossed. Perhaps this may inspire somebody in the future.

Thanks for providing and maintaining such a useful package for the community!

max.bra commented on 2019-01-01 01:16

hi hakayova. "pihole-FTL debug" from terminal is more useful?

hakayova commented on 2018-12-31 22:13

I am not sure how long has this problem existed, but I cannot seem to start pihole-FTL service anymore:

$ sudo systemctl start pihole-FTL.service $ Sudo systemctl status pihole-FTL.service

● pihole-FTL.service - Pi-hole FTLDNS engine Loaded: loaded (/usr/lib/systemd/system/pihole-FTL.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Mon 2018-12-31 16:04:03 CST; 3min 45s ago Process: 17651 ExecStart=/usr/bin/pihole-FTL no-daemon (code=exited, status=1/FAILURE) Main PID: 17651 (code=exited, status=1/FAILURE)

Dec 31 16:04:03 xxxx systemd[1]: pihole-FTL.service: Service RestartSec=100ms expired, scheduling restart. Dec 31 16:04:03 xxxx systemd[1]: pihole-FTL.service: Scheduled restart job, restart counter is at 5. Dec 31 16:04:03 xxxx systemd[1]: Stopped Pi-hole FTLDNS engine. Dec 31 16:04:03 xxxx systemd[1]: pihole-FTL.service: Start request repeated too quickly. Dec 31 16:04:03 xxxx systemd[1]: pihole-FTL.service: Failed with result 'exit-code'. Dec 31 16:04:03 xxxx systemd[1]: Failed to start Pi-hole FTLDNS engine.

There was a recent upgrade that may have broken it. The last time I checked, it was working, probably about a month ago. I have originally set it up using Arch Wiki about a year ago. I have also been using the FTL service > 4.0 without difficulty up until recently. I haven't changed any config files recently either.

The status command output above is not very informative. Any pointers will be greatly appreciated.

max.bra commented on 2018-12-22 19:27

@Splith Hi Splith, there is a small problem: ftl really conflicts with dnsmasq and literally replaces it by sharing its configuration files. with this premise it is difficult to make them coexist without dramatically patching the application, that does not concern us. and more, pihole(-admin) without ftl does not work ...

if you have a good idea to propose we are all available for discussion.

for your knowledge: ftl execute a dnsmasq process for real. maybe you are not in need to directly call it.

graysky commented on 2018-12-22 12:03

Since ftl is a fork of dnsmasq I think the conflicts= is accurate. As to the /etc/dnsmasq.conf being owned by this package... that is unrelated to the Arch-tweaks; upstream does that so that should be a decision upstream made see FTL-4.1.2/dnsmasq/config.h for example.

I can't speak for @max.bra, but my opinion would be to do the minimal amount of patching to get the code to run on Arch.