Debian User Forums

Fontenele wrote: 2025-01-12 00:47 dnsmasq: failed to create listening socket for 192.168.122.1: Address already in use

ss -p -o | grep 192.168

journalctl -b 0 -g 192.168 --no-pager

CwF wrote: 2025-01-12 03:18

Fontenele wrote: 2025-01-12 00:47 dnsmasq: failed to create listening socket for 192.168.122.1: Address already in use

Who's that?
maybe something like

Code: Select all

ss -p -o | grep 192.168

udp ESTAB 0 0 192.168.100.6%enp4s0:bootpc 192.168.100.1:bootps
tcp ESTAB 0 0 192.168.100.6:35000 34.206.101.32:https users:(("firefox-esr",pid=6385,fd=113)) timer:(keepalive,1min31sec,0)
tcp ESTAB 0 0 192.168.100.6:53790 185.70.42.37:https users:(("firefox-esr",pid=6385,fd=116))

or

Code: Select all

journalctl -b 0 -g 192.168 --no-pager

This one gave a bunch of info, especifi for 192.168.122 gave this:

sudo journalctl -b 0 -g 192.168.122 --no-pager
jan 11 22:36:20 revolutions avahi-daemon[874]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1.
jan 11 22:36:20 revolutions avahi-daemon[874]: Registering new address record for 192.168.122.1 on virbr0.IPv4.
jan 11 22:36:20 revolutions dnsmasq[6137]: failed to create listening socket for 192.168.122.1: Address already in use
jan 11 22:36:20 revolutions libvirtd[2691]: erro interno: Processo filho (VIR_BRIDGE_NAME=virbr0 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper) inesperado status de saída 2:
dnsmasq: failed to create listening socket for 192.168.122.1: Address already in use
jan 11 22:36:20 revolutions avahi-daemon[874]: Leaving mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1.
jan 11 22:36:20 revolutions avahi-daemon[874]: Withdrawing address record for 192.168.122.1 on virbr0.
jan 12 07:08:44 revolutions sudo[1638429]: marcelo : TTY=pts/0 ; PWD=/home/marcelo ; USER=root ; COMMAND=/usr/bin/journalctl -b 0 -g 192.168.122 --no-pager

Rebooted?

Yes

gooksin wrote: 2025-01-12 09:11

Code: Select all

de gen. 12 09:45:44 XXX systemd-networkd[512]: wlp3s0: DHCPv4 address 192.168.1.67/24, gateway 192.168.1.1 acquired from 192.168.1.1
de gen. 12 09:45:46 XXX named[1011]: listening on IPv4 interface wlp3s0, 192.168.1.67#53
de gen. 12 09:45:52 XXX named[1011]: listening on IPv4 interface virbr0, 192.168.122.1#53
de gen. 12 09:45:53 XXX dnsmasq[1243]: failed to create listening socket for 192.168.122.1: Address already in use
de gen. 12 09:45:53 XXX libvirtd[1009]: internal error: Child process (VIR_BRIDGE_NAME=virbr0 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper) unexpected exit status 2: 
                                          dnsmasq: failed to create listening socket for 192.168.122.1: Address already in use
de gen. 12 09:45:53 XXX named[1011]: no longer listening on 192.168.122.1#53

The named deamon is loaded before, as you can see. There were no issues with that before yesterday's upgrade to 12.9

Aki wrote: 2025-01-12 16:01 Hello,

gooksin wrote: 2025-01-12 09:11

Code: Select all

de gen. 12 09:45:44 XXX systemd-networkd[512]: wlp3s0: DHCPv4 address 192.168.1.67/24, gateway 192.168.1.1 acquired from 192.168.1.1
de gen. 12 09:45:46 XXX named[1011]: listening on IPv4 interface wlp3s0, 192.168.1.67#53
de gen. 12 09:45:52 XXX named[1011]: listening on IPv4 interface virbr0, 192.168.122.1#53
de gen. 12 09:45:53 XXX dnsmasq[1243]: failed to create listening socket for 192.168.122.1: Address already in use
de gen. 12 09:45:53 XXX libvirtd[1009]: internal error: Child process (VIR_BRIDGE_NAME=virbr0 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper) unexpected exit status 2: 
                                          dnsmasq: failed to create listening socket for 192.168.122.1: Address already in use
de gen. 12 09:45:53 XXX named[1011]: no longer listening on 192.168.122.1#53

The named deamon is loaded before, as you can see. There were no issues with that before yesterday's upgrade to 12.9

Normally named and dnsmasq daemons listen on the same port (53), unless they are configured differently, so they will conflict if they are running at the same time.

@gooksin: Do you need the named daemon (from bind9 package) running on your computer ?

@Fontenele: Is the named daemon (from bind9 package) installed in your computer ? Is its error message reported in systemd journal as for gooksin user ?

Hope this helps.

Fontenele wrote: 2025-01-12 17:38 With dnsmasq disabled, what other problems i could have with my network and Debian 12 in general?

Fontenele wrote: 2025-01-12 17:19 Bind9 package wasn't installed, installed, reboot, same problem.

Fontenele wrote: 2025-01-12 17:38 Hello there,

Searching around, in other forums, with those two commands below, i was able to start QEMU/KVM network:

Code: Select all

sudo systemctl stop dnsmasq
sudo systemctl disable dnsmasq

[...]

Fontenele

(A)> sudo systemctl stop dnsmasq
Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.
(A)> sudo systemctl disable dnsmasq
Failed to disable unit: Unit file dnsmasq.service does not exist.

Error starting domain: Requested operation is not valid: network 'default' is not active

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
    ret = fn(self, *args, **kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1402, in startup
    self._backend.create()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1373, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: Requested operation is not valid: network 'default' is not active

I respectfully suggest that the thread is not flagged as SOLVED.

I will try to find out what changed in libvirtd service, but I would appreciate your help, since I'm not really a developer.

Cheers

CwF wrote: 2025-01-13 17:21 @gooksin
I don't have any guess at the moment, but it does look like it is a generic network error underneath libvirt -which can be specific to method. I use all hardware networking so never have a ‘default’ network active, no bind9, no ‘br0’, etc.

You could look at the status with 'virsh net-list'.

As I remember, that should list states and modes of all libvirt managed networking, mine is empty since all is hardware managed. Maybe simplify, disassemble, reassemble, in order to find the failure.

Name       State   Autostart   Persistent
-------------------------------------------
 default   active   yes          yes

I do see reports of dnsmasq issues in version 2.9x, you may try to downgrade the package to confirm if that is the problem. Download the older version, remove current, install older, try again...

gooksin wrote: 2025-01-13 18:49 I will try to get feedback from the maintainers.

CwF wrote: 2025-01-13 19:09

gooksin wrote: 2025-01-13 18:49 I will try to get feedback from the maintainers.

Very good. Please post updates. It is only a work around and not solved. Let's hope the next update works.

I'll be paying attention, but as stated I don't expect to see the issue with my config.

    listen-on { 127.0.0.1; };
    listen-on { mynet; };

acl mynet {
  192.168.134.0/24;
};

gooksin wrote: 2025-01-17 09:11

CwF wrote: 2025-01-13 19:09

gooksin wrote: 2025-01-13 18:49 I will try to get feedback from the maintainers.

Very good. Please post updates. It is only a work around and not solved. Let's hope the next update works.
I'll be paying attention, but as stated I don't expect to see the issue with my config.

[..] I contacted the libvirt and dnsmasq-base developers and got useful answers from Sven Geuer (dnsmasq maintainer) and Lee Garrett (Debian developer).

First, the explanation:
The conflict between bind9 and dnsmasq-base for the use of the virbr0 (or whatever other name) interface had always been there. What changed between dnsmasq-base 2.8.x and 2.9.x was the fact that in the latter, this conflict resulted in a failure. This is, I agreed with the developers, a good thing to do to avoid further problems. Perhaps because my VMs don't access intensively to the internet, I don't recall having had any problem, though.

Now, for the possible solutions, I got these suggestions:
1. Drop bind9 and use dnsmasq globally. According to Sven, dnsmasq can also handle local zones
2. Don't use NAT for the VMs but instead give them access to the internet through a bridge interface
3. Tell bind9 not to listen to the interface (virbr0 in my case) that libvirt creates for dnsmasq-base

Since I wanted to act minimally on my, perhaps not very standard, configuration, I went for 3. It took me a while to figure out how to do that, mainly because my knowledge in these subjects is very limited. But in the end, it was as simple as adding in the named.conf.options file these two lines (they will of course be different in other configurations):

Code: Select all

    listen-on { 127.0.0.1; };
    listen-on { mynet; };

where „mynet“ is a list of subnets I want to allow queries from, defined in a previous acl clause:

Code: Select all

acl mynet {
  192.168.134.0/24;
};

I have marked again the question as solved, since I think we have a general solution.
Cheers