root@blackPI:~# nc -vz 127.0.0.1 4711
nc: connect to 127.0.0.1 port 4711 (tcp) failed: Connection refused
root@blackPI:~# nc -vz 127.0.0.1 14434
Connection to 127.0.0.1 14434 port [tcp/*] succeeded!
root@blackPI:~# ip -br a s lo
lo UNKNOWN 127.0.0.1/8
root@blackPI:~#
see my posting above, no firewall
14434 is the server-port of my qBittorrent-Instance
by the way, see my EDIT above, it's not a network-issue, it's a problem of pihole, right?
Those results didn't produce any hints.
Could you also provide
ls -lah /var/log/pihole*.log
From your latest debug log mADg1Qm1, pihole-FTL is reported as running:
*** [ DIAGNOSING ]: Pi-hole processes
[✓] lighttpd daemon is active
[✓] pihole-FTL daemon is active
But at the same time, it seems it failed to bind any of its ports, 53 and 4711, and possibly 67 and 547 if Pi-hole has been configured for DHCP/DHCPv6 (click for debug log details):
*** [ DIAGNOSING ]: Ports in use
udp:192.168.3.102:5353 is in use by dotnet
udp:0.0.0.0:5353 is in use by dotnet
udp:0.0.0.0:5353 is in use by avahi-daemon
udp:0.0.0.0:3478 is in use by dotnet
udp:0.0.0.0:59312 is in use by avahi-daemon
udp:0.0.0.0:68 is in use by dhclient
udp:192.168.98.1:14434 is in use by qbittorrent-nox
udp:10.0.9.1:14434 is in use by qbittorrent-nox
udp:10.0.8.1:14434 is in use by qbittorrent-nox
udp:192.168.99.1:14434 is in use by qbittorrent-nox
udp:192.168.3.102:14434 is in use by qbittorrent-nox
udp:127.0.0.1:14434 is in use by qbittorrent-nox
udp:0.0.0.0:55553 is in use by openvpn
udp:0.0.0.0:530 is in use by iodined
udp:0.0.0.0:51820 is in use by <unknown>
udp:*:51820 is in use by <unknown>
tcp:0.0.0.0:22 is in use by sshd
tcp:0.0.0.0:8888 is in use by rpimonitord
tcp:0.0.0.0:8090 is in use by dotnet
tcp:0.0.0.0:666 is in use by apache2
tcp:0.0.0.0:667 is in use by apache2
tcp:0.0.0.0:2525 is in use by master
tcp:0.0.0.0:55552 is in use by stunnel4
tcp:192.168.98.1%wg0:14434 is in use by qbittorrent-nox
tcp:10.0.9.1%tun1:14434 is in use by qbittorrent-nox
tcp:10.0.8.1%tun0:14434 is in use by qbittorrent-nox
tcp:192.168.99.1%dns0:14434 is in use by qbittorrent-nox
tcp:192.168.3.102%wlan0:14434 is in use by qbittorrent-nox
tcp:127.0.0.1%lo:14434 is in use by qbittorrent-nox
tcp:0.0.0.0:55554 is in use by openvpn
tcp:127.0.0.1:3306 is in use by mysqld
tcp:0.0.0.0:5900 is in use by vncserver-x11-c
tcp:0.0.0.0:45678 is in use by apache2
[✓] tcp:0.0.0.0:80 is in use by lighttpd
tcp:[::]:22 is in use by sshd
tcp:[::]:2525 is in use by master
tcp:*:7777 is in use by qbittorrent-nox
tcp:*:9090 is in use by systemd
tcp:[::]:5900 is in use by vncserver-x11-c
[✓] tcp:[::]:80 is in use by lighttpd
There may be a port conflict over 5353 (avahi and dotnet both claiming the offcial mDNS port), but that certainly is not related to Pi-hole.
More often than not, that would suggest a firewall on the machine hosting Pi-hole would be blocking Pi-hole's ports.
But it's strange that pihole-FTL would not even log its new startup attempts, as your log still shows it as having been terminated on 2022-07-09 as its last entry:
That was the solution.
The Setup of pihole do not check if rights on folder
/var
and
/var/log
are set correctly.
When you start it with sudo -u pihole pihole-FTL debug
the result:
[2022-07-14 00:19:16.302 26693M] Using log file /var/log/pihole/FTL.log
!!! WARNING: Writing to FTL's log file failed!
FATAL: Opening of FTL log (/var/log/pihole/FTL.log) failed!
Make sure it exists and is writeable by user pihole
I am wondering why before update of pihole, everything worked well.
I never changed right on /var and /var/log after installing pihole first time.
I suppose that FTL could start also without writing logfile, or there was a change in coding of FTL in the update.
Have a look on the timestamp of the log-File, and the last entry in log-file --> 09th July
That was exactly the date/time when I made the update via pihole up
So, something happend while update.
Before, FTL had a working access to /var/log/pihole/FTL.log. So the update changed something.
After Update, i noticed immediately that one logfile in /var/log/pihole had root as owner and group, not pihole (I dont remember which file).
That's why I mentioned in my first posting that i started pihole up with root-user.
Between 9th July and today, you released a new version of pihole to correct the non-working log-rotation.
I suppose that another effect of the rotations-error was that the rights of /var/log were changed.
Owner and Group of /var and /var/log is root
because pihole and FTL work with user pihole, pihole user can only access FTL-log when /var and /var/log/ have the allowance to read and list these folders for "others" ("r" and "x" for others)
I am fully aware of that.
See my very first reply here:
Note that even your first debug log contained the correct permissions for both of the log files, which have always been listed correctly since.
It doesn't seem likely that permissions on those files have been the cause for your observation, which leaves me without an explanation for that recent FATAL error of yours.
EDIT:
That leaves /var/log/pihole/ (the new target directory for Pi-hole's log files) as a possibilty for incorrect permissions:
No, the debug log does not contain directory permissions at all, only files.
But I realise now that I should have spotted that deviation from the results of one of the commands I've asked you to run - my bad:
as opposed to:
Still, I do not have an explanation how that directory may have ended up with wrong permissions. It certainly was created correctly when I did my updates..
@blacksun , I wonder if you use some sort of logtoram or tmpfs for the logs that might kick in too late or interfere otherwise.
What does below one show?
i developed some thoughts
I think you do neither check folder-permissions nor change permissions on them, right?
If an Update for pihole is available, this cannot be done with user pihole.
So everybody has to use a higher privileged user, root, pi, etc.
these user has always access to the folders and files which pihole.
So you do not notice wrong permissions. When running pihole as service, the pihole user is used. So if there is a permission-problem, this occurs only when running in normal mode.
Because nobody else than me had the problem, I think you do not have to change anything.
For the future, an idea would be a permission check on all folders which are used by pihole. This check should check for permission for pihole user.
This check should run while installation, and also when updating.
Did you perhaps apply that workaround and create the folder manually, perhaps while logged in as root?
No again - the update process takes care of rights and permissions.
As suggested by our update note, running pihole -up is enough - no need to switch to another user:
