Package Details: pi-hole-ftl 5.25.2-2

Git Clone URL: https://aur.archlinux.org/pi-hole-ftl.git (read-only, click to copy)
Package Base: pi-hole-ftl
Description: The Pi-hole FTL engine
Upstream URL: https://github.com/pi-hole/FTL
Licenses: EUPL-1.2
Conflicts: dnsmasq
Provides: dnsmasq
Submitter: max.bra
Maintainer: max.bra (graysky)
Last Packager: max.bra
Votes: 56
Popularity: 1.50
First Submitted: 2017-05-07 15:23 (UTC)
Last Updated: 2024-08-10 09:53 (UTC)

Required by (65)

Sources (6)

Pinned Comments

max.bra commented on 2018-02-09 16:46 (UTC) (edited on 2019-10-18 23:13 (UTC) by max.bra)

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

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 44 Next › Last »

dunster commented on 2022-03-07 20:05 (UTC)

@max.bra sorry for asking but how do I install the snapshot?

max.bra commented on 2022-03-07 19:50 (UTC)

Hi dunster. Reinstall ftl using the snapshot in this page or clean compilation with an aur helper.

dunster commented on 2022-03-07 18:23 (UTC)

@max.bra I have the same problem. How can I update to your fixed version?

max.bra commented on 2022-03-07 13:43 (UTC)

since two is enough, added shared memory cleanup to systemd service (w/o revision bump)

ferreum commented on 2022-03-06 19:35 (UTC)

I get the same problem like @cookiengineer. The root problem seems to be that pihole doesn't clean up the files itself in error conditions and doesn't handle the case that they already exist.

For example, when I had a faulty configuration (something else already used 53), so pihole-FTL failed to start up (appropriately, with different error of course). In the logs I could see systemd try to restart it, but pihole-FTL now failed multiple times because of files in /dev/shm until systemd gave up. I fixed the initial problem (freed up port 53) and started pihole-FTL again, but it would still complain about the temporary files.

Whenever such an error condition happens, I have to manually delete the files in /dev/shm to make it start up cleanly again.

max.bra commented on 2022-03-06 19:22 (UTC)

@cookiengineer I understand your despair but no one else has your problem. you should first try to figure out what is causing the mess on your system. my FTL, and that of many others, starts without any problem at every reboot/restart. you should start doing some research on shared memory (not cache).

cookiengineer commented on 2022-03-06 18:58 (UTC)

Please add an ExecStartPre line to remove the temporary caches. Otherwise this service will fail in an endless loop, because it always tries to create the temporary files.

In my /usr/lib/systemd/system/pihole-FTL.service, I added/modified the following lines, as one of the chown entries had a "-" before them, which caused the service to fail as well:

(...)
ExecStartPre=/bin/chown -R pihole:pihole /etc/pihole
ExecStartPre=/bin/chown -R root:root /etc/pihole/logrotate
ExecStartPre=/bin/rm -f /dev/shm/FTL-*
ExecStart=/usr/bin/pihole-FTL no-daemon
(...)

quark23 commented on 2022-01-07 11:03 (UTC) (edited on 2022-01-07 11:04 (UTC) by quark23)

Archlinux ARM
Service starts before network is up so it hangs. pihole -g starts it after boot.
I solved the issue by modifying the service file:
Requires=network-online.target
After=network-online.target

Mettacrawer commented on 2022-01-03 00:30 (UTC)

pi-hole-ftl 5.12.1-2 looks good to me

max.bra commented on 2022-01-02 23:19 (UTC)

Added possibly missing capabilities. thanks for reporting.
please let me know if your problem is completely solved.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 44 Next › Last »