Bug 2388485

Summary: Mosquitto fails to start when binding to a single IP address
Product: [Fedora] Fedora Reporter: Jan "Yenya" Kasprzak <kas>
Component: mosquittoAssignee: Jonathan Wright <jonathan>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 43CC: linville, pbrobinson, richmattes
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: mosquitto-2.0.22-6.fc43 Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-12-27 00:41:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jan "Yenya" Kasprzak 2025-08-14 09:46:10 UTC
When binding to a single IP address instead of INADDR_ANY, mosquitto fails to start during reboot with the following error:

mosquitto[11553]: 1755120654: Warning: Interface internal does not support IPv4 configuration.
systemd[1]: mosquitto.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: mosquitto.service: Failed with result 'exit-code'.
systemd[1]: Failed to start mosquitto.service - Mosquitto MQTT Broker.

If I log in later and run "systemctl restart mosquitto", it starts correctly. This probably means that systemd attempts to start it before the network interface "internal" is configured.

Reproducible: Always

Steps to Reproduce:
1. Use Fedora system with NetworkManager and ethernet interface named "internal" configured statically via NM (i.e. no DHCP or whatever).
2. Configure mosquitto to listen on this address:

/etc/mosquitto/mosquitto.conf:
[...]
listener 8883 10.0.0.1
bind_interface internal
protocol mqtt

3. systemctl enable mosquitto
4. reboot
5. log in and run "systemctl status mosquitto"
Actual Results:
systemctl reports failure with "exit-code" result, as described above.

Expected Results:
mosquitto should be up and running after reboot

Additional Information:
I think that in /lib/systemd/system/mosquitto.service there should be

After=network-online.target

instead of

After=network.target

My /etc/NetworkManager/system-connections/internal.nmconnection:

[connection]
id=internal
type=ethernet
interface-name=internal
uuid=7...b
autoconnect=true
name=interni

[ipv4]
method=manual
address1=10.0.0.1/24

[ipv6]
method=disabled

Comment 1 Peter Robinson 2025-08-14 10:45:02 UTC
Did this used to work, is it a regression or just something you discovered?

Comment 2 Jan "Yenya" Kasprzak 2025-08-14 12:44:20 UTC
I _think_ it started with upgrade to F40 or F41. On the other hand, I used to have a /etc/sysconfig/network-scripts based network configuration before. It might be related.

Comment 3 Jan "Yenya" Kasprzak 2025-08-14 13:52:31 UTC
According to journalctl -b, it indeed seems that network.target is reached as soon as NetworkManager is started, and it manages to configure only the loopback device before systemd attempts to start mosquitto. The "internal" device is activated much later:

Aug 13 23:30:54 my.host.name systemd[1]: Started NetworkManager.service - Network Manager.
Aug 13 23:30:54 my.host.name NetworkManager[11013]: <info>  [1755120654.0130] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
Aug 13 23:30:54 my.host.name systemd[1]: Reached target network.target - Network.
Aug 13 23:30:54 my.host.name NetworkManager[11013]: <info>  [1755120654.0155] device (lo): state change: disconnected -> prepare (reason 'none', managed-type: 'external')
Aug 13 23:30:54 my.host.name NetworkManager[11013]: <info>  [1755120654.0163] device (lo): state change: prepare -> config (reason 'none', managed-type: 'external')
Aug 13 23:30:54 my.host.name NetworkManager[11013]: <info>  [1755120654.0168] device (lo): state change: config -> ip-config (reason 'none', managed-type: 'external')
Aug 13 23:30:54 my.host.name NetworkManager[11013]: <info>  [1755120654.0180] device (lo): state change: ip-config -> ip-check (reason 'none', managed-type: 'external')
Aug 13 23:30:54 my.host.name systemd[1]: Starting NetworkManager-wait-online.service - Network Manager Wait Online...
Aug 13 23:30:54 my.host.name NetworkManager[11013]: <info>  [1755120654.0217] device (lo): state change: ip-check -> secondaries (reason 'none', managed-type: 'external')
Aug 13 23:30:54 my.host.name NetworkManager[11013]: <info>  [1755120654.0222] device (lo): state change: secondaries -> activated (reason 'none', managed-type: 'external')
Aug 13 23:30:54 my.host.name NetworkManager[11013]: <info>  [1755120654.0235] device (lo): Activation: successful, device activated.
Aug 13 23:30:54 my.host.name mosquitto[11080]: 1755120654: mosquitto version 2.0.22 starting

Comment 4 Fedora Admin user for bugzilla script actions 2025-08-15 13:40:12 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 5 Jan "Yenya" Kasprzak 2025-11-14 07:34:21 UTC
This is still broken on F43:

mosquitto-2.0.22-4.fc43.x86_64

With the above configuration bound to a single interface/address mosquitto is started too early and the startup fails. Adding After=network-online.target to the mosquitto.service unit file fixes the problem.

Comment 6 Adam Williamson 2025-12-02 03:18:26 UTC
This message is a reminder that Fedora Linux 41 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '41'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 41 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 7 Peter Robinson 2025-12-18 00:39:01 UTC
> With the above configuration bound to a single interface/address mosquitto
> is started too early and the startup fails. Adding
> After=network-online.target to the mosquitto.service unit file fixes the
> problem.

This changed upstream to network.target back in 2020 in the 1.6.10 release so it's been the situation for quite some time. It's been changed back upstream but isn't in a release as yet.

Comment 8 Fedora Update System 2025-12-18 01:16:26 UTC
FEDORA-2025-3dca4f410d (mosquitto-2.0.22-6.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-3dca4f410d

Comment 9 Fedora Update System 2025-12-19 04:24:21 UTC
FEDORA-2025-3dca4f410d has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-3dca4f410d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-3dca4f410d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Fedora Update System 2025-12-27 00:41:40 UTC
FEDORA-2025-3dca4f410d (mosquitto-2.0.22-6.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.