? pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/init.d/pihole-FTL; generated)
Active: active (exited) since Sat 2019-06-29 03:02:05 AEST; 1min 17s ago
Docs: man:systemd-sysv-generator(8)
Process: 822 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)
Jun 29 03:01:59 USPH1804 systemd[1]: Starting LSB: pihole-FTL daemon...
Jun 29 03:02:00 USPH1804 pihole-FTL[822]: Not running
Jun 29 03:02:02 USPH1804 su[1003]: Successful su for pihole by root
Jun 29 03:02:02 USPH1804 su[1003]: + ??? root:pihole
Jun 29 03:02:02 USPH1804 su[1003]: pam_unix(su:session): session opened for user pihole by (uid=0)
Jun 29 03:02:05 USPH1804 pihole-FTL[822]: FTL started!
Jun 29 03:02:05 USPH1804 systemd[1]: Started LSB: pihole-FTL daemon.
If @Mcat12 method dont work, below Ubuntu user had something similar.
Solution in that thread is more like a patch and not really a fix.
If have similar issue, you need to figure out why the interface comes up late (dmesg etc).
And your netstat looks a bit fragmented.
Below how a clean netstat could look like:
I have one further question for fixing it in upcoming releases if you don't mind: When you again remove the sleep 20 in your init script (so that the command fails), what is the output in /var/log/pihole.log?
And it still came up working. So I then moved lxd back to /etc/dnsmasq.d and rebooted, it failed! So that was the problem all along.
I did a clean install of Ubuntu 18.04 Server as a VM and setup PiHole in that, I don't remember doing anything with DNS during that install so it might be a default thing I'm not sure.
Anyway, its now working and I now know it was this lxd symlink that was causing the problem all along and nothing to do with PiHole.
And if you hadn't asked me for the output of /var/log/pihole.log and I'd looked into this more we might never have gotten to the true cause of the problem.
I take it you don't need to see the output of /var/log/pihole.log anymore?
Great detective work.
I was to type up something similar to warn @DL6ER about the bind-interfaces directive in that lxd file.
If pihole-FTL tries to bind to the IP's assigned to the interfaces, it might run into troubles if an interface comes up late.
With pihole-FTL listening on all IP's 0.0.0.0, interfaces (with IP) can come and go without issues.
EDIT: I didnt think about this at the time
Instead of bind-interfaces, bind-dynamic would work better.
Enable a network mode which is a hybrid between --bind-interfaces and the default. Dnsmasq binds the address of individual interfaces, allowing multiple dnsmasq instances, but if new interfaces or addresses appear, it automatically listens on those (subject to any access-control configuration). This makes dynamically created interfaces work in the same way as the default. Implementing this option requires non-standard networking APIs and it is only available under Linux. On other platforms it falls-back to --bind-interfaces mode.