Package Details: pi-hole-ftl 5.25.1-1

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: 55
Popularity: 0.58
First Submitted: 2017-05-07 15:23 (UTC)
Last Updated: 2024-02-21 10:15 (UTC)

Dependencies (6)

Required by (63)

Sources (7)

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 .. 43 Next › Last »

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.

max.bra commented on 2022-01-02 23:09 (UTC) (edited on 2022-01-02 23:10 (UTC) by max.bra)

no, i missed https://github.com/pi-hole/pi-hole/commit/a1ee7d92a9b2c3535b228d7af88990a0bd84250c#diff-9145b80c4d37b5798da3f3abbe7404f68b96963007340e4095524141efffd6bc because i have no warning at all...

Mettacrawer commented on 2022-01-02 19:53 (UTC) (edited on 2022-01-02 19:54 (UTC) by Mettacrawer)

I put another round of updates on (ran "yay -Suy" again) and I'm able to start pihole-FTL.service without using setcap on /usr/bin/pihole-FTL (I used "setcap -r /usr/bin/pihole-FTL"). I still get warnings about two capabilities missing.

$ journalctl -b -0 -u pihole-FTL | grep CAP
Jan 02 14:35:37 example.com pihole-FTL[846]: [2022-01-02 14:35:36.996 846M] WARNING: Required Linux capability CAP_IPC_LOCK not available
Jan 02 14:35:37 example.com pihole-FTL[846]: [2022-01-02 14:35:36.996 846M] WARNING: Required Linux capability CAP_CHOWN not available

Is there a reason /usr/lib/systemd/system/pihole-FTL.service does not contain CAP_IPC_LOCK and CAP_CHOWN?

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