systemd-resolved is listening on port 53, too about comitup HOT 15 CLOSED

Ok, so there is port contention for DHCP. I don't know why you see this and I don't.

Note that hotspot dhcp responsibility was moved from NetworkManager to Comitup in v1.6. If you have upgraded from v1.5, you need to manually remove the "dnsmasq sabotage" file stored under /etc/NetworkManager.

It will be a couple of weeks before I could investigate.

from comitup.

Can you post the contents of your /etc/network/interfaces file? resolv.conf?

Have you edited resolved.conf or systemd.network?

from comitup.

$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

$ ls /etc/network/interfaces.d/
50-cloud-init.cfg

$ cat /etc/network/interfaces.d/50-cloud-init.cfg 
# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

I haven't edited those files.

I can send you image I run on the Raspberry Pi. Or my way of building the image (which is a bit convoluted).

from comitup.

FWIW, the systemd-resolved service is disabled in a Comitup Raspbian image run.

I've added a note to the package install instructions to disable that service.

from comitup.

hm. would it be better to express that conflict in systemd terms with a Conflicts= stanza?

from comitup.

Comitup already requires systemd.

from comitup.

Sure. What I'm wondering is whether the comitup.service unit file should have a Conflicts=systemd-resolved.service line.

from comitup.

"Configures negative requirement dependencies. If a unit has a Conflicts= setting on another unit, starting the former will stop the latter and vice versa"

I'm not sure that's an improvement, but it's worth looking into someday.

from comitup.

it would then stop the offending service and allow comitup to run.
Do you not see that as an improvement?

from comitup.

Only if there is an assurance that the opposite doesn't happen.

from comitup.

I've added a note to the package install instructions to disable that service.

That helps but a list of specific commands to run like e.g. here https://askubuntu.com/a/907249/980058 would be useful for the non-experts I guess.

from comitup.

I think what would really help is to express that conflict in terms of systemd, i.e. Conflicts=systemd-resolved.service

from comitup.

In the general case, the two services are not incompatible - systemd-resolved can be configured to coexists. Thanks for pointing out the issue. #120 remains with the mitigations implemented.

from comitup.

In the general case [...]

sure. I guess I'm mostly interested in the default case, rather than a situation that you can end up with with manual intervention. That is, whatever ends up being the default configuration visible to the user based on what upstream ships (or maybe what distributions make out of it).

For my future self: here is another thing to consider to work around this bug: https://unix.stackexchange.com/a/304798/71928

from comitup.

For additional future reference, the recommended "it just works" option is the Comitup iso image.

from comitup.