Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specifying max_qos before a listener instantiates the implicit listener, result in two listeners on the same port #2991

Open
jr1221 opened this issue Feb 3, 2024 · 2 comments

Comments

@jr1221
Copy link

jr1221 commented Feb 3, 2024

When max_qos is specified before listener 1883:
Conf:

max_qos 1
listener 1883

Result:

1706999194: mosquitto version 2.0.18 starting
1706999194: Config loaded from ./test.conf.
1706999194: Loading plugin: /usr/lib/mosquitto/mosquitto_message_timestamp.so
1706999194: Opening ipv4 listen socket on port 1883.
1706999194: Opening ipv4 listen socket on port 1883.
1706999194: Error: Address already in use

When max_qos is specified after listener 1883 (not the default in the conf file):
Conf:

listener 1883
max_qos 1

Result (intended):

1706999106: mosquitto version 2.0.18 starting
1706999106: Config loaded from ./test.conf.
1706999106: Loading plugin: /usr/lib/mosquitto/mosquitto_message_timestamp.so
1706999106: Opening ipv4 listen socket on port 1883.
1706999106: mosquitto version 2.0.18 running

Mosquitto version 2.0.18 built from source via buildroot, for aarch64. I assume this is a bug but I wanted to be sure, it is annoying because you have to move max_qos to below the listener block if you start with the default conf, but not really a problem. If anyone needs anything to debug this lmk.

@jr1221
Copy link
Author

jr1221 commented Feb 3, 2024

#2497 looks like this, and I feel like this is a bug because the per_listener setting is false.

@MattBrittan
Copy link

MattBrittan commented Feb 7, 2024

It appears this might be caused by any per_listener config line placed before a listener; as per this stack overflow question where the issue was password_file. The current behaviour is confusing, and not as per the documentation, so I also feel that it's a bug. Duplicated with 2.0.11 and 2.0.18.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants