Unable to start pihole-FTL after server reboot, port 53 already in use

Some others have mentioned the same kind of issue, but I've not found a solution that matches my issues exactly. Upon a reboot, the Pi-hole interface will load but is very sluggish. As the title says, pihole-FTL won't start and it says that port 53 is already in use. What I found from "netstat -tanp | grep LISTEN" is the following:

tcp 0 0* LISTEN 1479/dnsmasq is nowhere even close to the IP I'm using on the server, so I dug a little deeper and found the entry to be in /var/lib/libvirt/dnsmasq/default.conf, but the service is also disabled. I also confirmed that under Settings - DHCP, DHCP is not enabled. If I kill the running process, I can then start pihole-FTL.

[cshoults@pihole1 rc.d]$ sudo systemctl list-unit-files | grep dnsm
dnsmasq.service disabled

(partial configuration file)
##OVERWRITTEN AND LOST. Changes to this configuration should be made using:
##virsh net-edit default
##or other application using the libvirt API.
##dnsmasq conf file created by libvirt

[cshoults@pihole1 rc.d]$ sudo systemctl status pihole-FTL.service
‚óŹ pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/rc.d/init.d/pihole-FTL; bad; vendor preset: disabled)
Active: active (exited) since Tue 2022-08-02 15:46:59 EDT; 31min ago
Docs: man:systemd-sysv-generator(8)
Process: 2310 ExecStart=/etc/rc.d/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)
Tasks: 0
Aug 02 15:46:59 pihole1.battletech-live.net systemd[1]: Starting LSB: pihole-FTL daemon...
Aug 02 15:46:59 pihole1.battletech-live.net pihole-FTL[2310]: Not running
Aug 02 15:46:59 pihole1.battletech-live.net su[2329]: (to pihole) root on none
Aug 02 15:46:59 pihole1.battletech-live.net pihole-FTL[2310]: FTL started!
Aug 02 15:46:59 pihole1.battletech-live.net systemd[1]: Started LSB: pihole-FTL daemon.

CentOS 7, x86_64

The only things I've really done are to set up the OS, install Pi-hole, set up unbound and add adlists to Pi-hole.

You will need to keep the dnsmasq process disabled (or remove it entirely) or you will likely have this problem again on next reboot.

Even though dnsmasq.service was disabled, it looks like libvirtd.service was causing it to start. I've disabled that service. Maybe that's enough to stop the issue.