SystemD socket activation support

[carlhoerberg]

We would like to add socket activation support, that is, systemd opens a TCP socket and listens for connections, once the first connection is made the mosquitto server is started and the server inherites the FD/socket and starts accepting the connections.

https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html#

We're willing to do the PR if you think it's a good idea to incorporate.

[karlp]

Is there anyway of doing this without making systemd a dependency? Also, what's the use case scenarion where you want this? I think the socket activation is really neat for short lived services, but for a message broker I simply don't understand why you would want the extra hassle?

[carlhoerberg]

Yes, no need for a dependency, we can just look for the environment variables at start up, LISTEN_PID (compare with current process pid), LISTEN_FDS (how many more sockets to listen for), LISTEN_FDNAMES (to map each socket to a protocol, eg tls, websocket)

It lets us start listening for packets without starting the server. At CloudMQTT we have thousands of Mosquitto servers running on each box, but we could save a lot of resources and startup time if we only started the mosquitto process for the users that are actually using their servers.

[ralight]

Dependencies aren't the worst thing in the world as long as they're optional.

I can see that this would be a useful feature for you, but I'm struggling to see that it would be something that was more widely useful. As Karl points out, long running processes are a key point of MQTT so this is trying to optimise for a degenerate case.

Maybe it would be worth canvassing the mailing list to see what the wider opinion is.

[carlhoerberg]

Yeah, faster startup time would, I guess be the benefit for other users, and decreased memory usage on development machines. The service doesn't have to start until something actually make a connection to it. I believe the code change is pretty minimal and impact zero if it's not used, aside for some more code lines and added documentation.

…

On Jul 4, 2017 00:21, "Roger Light" ***@***.***> wrote: Dependencies aren't the worst thing in the world as long as they're optional. I can see that this would be a useful feature for you, but I'm struggling to see that it would be something that was more widely useful. As Karl points out, long running processes are a key point of MQTT so this is trying to optimise for a degenerate case. Maybe it would be worth canvassing the mailing list to see what the wider opinion is. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#480 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAK_Tj1Bfhvi9eX9xQeTt6LLyqvCWh5Xks5sKWlRgaJpZM4OLjtU> .

[ralight]

Let's give it a try then and see what it looks like - if you could base your work on the develop branch that would be best.

[bwduncan]

Just wanted to add my +1 here. My use case is exactly one of dependencies: I have many services which are relying on mosquitto being started, which at the moment are failing.

Obviously I could explicitly add a dependency to start those services after mosquitto has been started, but there is still a race since it takes some time for mosquitto to start listening. Also, I have to specify the dependency for every service using mosquitto, whereas socket activation means the dependency is implicit and dependent services will simply block until mosquitto is ready. This hopefully makes the system much more resilient, which is important when it's deployed!

[pat1]

I need something different but some link with this issue is possible.
I have a lot of environmental things that have to publish data with a local queue for data sent/not sent.
When one things publish, it dequeue the message. The message have to go in a DB.
At boot, to do not have lost message, the sequence have to be:

• start mosquitto
• start consumer (subscribe)
• start producer (publish)

now I can have lost messages because things can publish before consumer can subscribe.
The only solution find for now is to use the firewall to enable local consumer before network producer.

[peterhoeg]

@carlhoerberg any progress? I would very much like to echo @pat1's sentiments that socket activation vastly simplifies dependency handling.

[carlhoerberg]

Yes, @spuun got a working solution, but I believe it needs a small clean up before submitting a PR.

…

On Mar 12, 2018 07:29, "Peter Hoeg" ***@***.***> wrote: @carlhoerberg <https://github.com/carlhoerberg> any progress? I would very much like to echo @pat1 <https://github.com/pat1>'s sentiments that socket activation vastly simplifies dependency handling. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#480 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAK_ToBo_-q_BpFYsZAMWZ5jw8VUyyuWks5tdhXdgaJpZM4OLjtU> .

[spuun]

I'll give it some attention again. I need to test a few things. You find it here: https://github.com/CloudMQTT/mosquitto/tree/systemd

[karlp]

@bwduncan if your services rely on mosquitto being up that's fine, making notifications or events for mosquitto being up sounds perfectly reasonable. But this original PR was about making mosquitto not start until someone tried to connect to it, which is completely different altogether. @peterhoeg is that what you actually want as well?

[peterhoeg]

It's really the same thing. With socket activation, the socket will be available right from the get-go so that all services depending on mosquitto will not fail if the mosquitto service isn't up.

[chris2511]

The other good thing with "socket activation" is the avoidance of race conditions. With the sockets hold by the service manager, clients can connect at any time, even if the server crashed or got killed unexpectedly.

I created PR #2346 for https://github.com/eclipse/mosquitto/tree/develop
as well as patches for the current releases 2.0.12: 4c7cd33 and 2.0.14: 4c7cd33

[qubeck]

Great that eventually something is happening on that topic again. In the past I created PR #1522 to target the generic use case to accept connections passed via UDS... @chris2511 thx, for #2346. I think this partially has the potential to render my PR obsolete (since it's also not in sync with the current codebase anymore).