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

Mosquitto sends LWT when persistent client restarts #1273

yschroeder opened this issue May 11, 2019 · 6 comments


None yet
4 participants
Copy link

commented May 11, 2019

I am trying to use LWT with a persistent client (clean_session=False). When this client disconnects cleanly and then is started again later, its LWT will fire when connecting.

This is my example code with the Paho Python client:

import time

from paho.mqtt.client import Client

mqttc = Client(client_id="foobar", clean_session=False)
mqttc.will_set("foobar_topic", payload="foobar crashed", qos=0, retain=False)
mqttc.connect_async("localhost", 1883)


mqttc.publish("foobar_topic", payload="foobar online", qos=0, retain=False)





I also tried to reproduce this script as closely as possible with mosquitto_pub:

$ mosquitto_pub --will-topic foobar_topic --will-payload crashed --will-retain -i foobar -t foobar_topic -m online -h localhost -r --disable-clean-session


  • Listen to foobar_topic: mosquitto_sub -h localhost -t "foobar_topic"
  • Run above Python script
  • Subscriber will see foobar online
  • Run above script again
  • Subscriber will see foobar crashed and foobar online

In the last step I expect the subscriber to only see foobar online as I correctly disconnected from the broker (according to the Mosquitto log).

If I try the same with the listed mosquitto_pub command afterwards, I also get the foobar crashed message on the first run, consecutive runs only print online.

I am not entirely sure if the bug lies within the Python library or Mosquitto. It is somewhat strange, that the last will fires on the first run of mosquitto_pub. However, I cannot reproduce the problem with only using mosquitto_pub. After a short investigation with Wireshark I found that mosquitto_pub is ignoring the --disable-clean-session and sets the flag even when told not to do so.

As this happens exactly when a new client with id foobar connects, independently of being Python or mosquitto_pub, I believe the problem lies within Mosquitto. The persistent Python client exited cleanly and thus Mosquitto should not have published any LWT. Or am I missing something?

Mosquitto Version: 1.6.2


This comment has been minimized.

Copy link

commented May 11, 2019

Further, when the client crashes before disconnecting, Mosquitto logs:

Mai 12 00:37:12 hostname mosquitto[7986]: 1557614232: Socket error on client foobar, disconnecting.

But does not send the LWT. It only sends the LWT on the next connection of a client (either Python or mosquitto_pub).


This comment has been minimized.

Copy link

commented May 12, 2019

It is possible to reproduce with mosquitto_sub

$ mosquitto_sub --will-topic foobar_topic --will-payload crashed --will-retain -i foobar -t foobar_topic -v -h localhost -r --disable-clean-session

When terminating mosquitto_sub with CTRL-C, the LWT is not sent, but only when the command is repeated and the program reconnects


This comment has been minimized.

Copy link

commented May 12, 2019

Good find! Is there a way to gracefully terminate mosquitto_sub? Sending SIGTERM does not work...

I guess these are multiple problems:

  1. Mosquitto sending LWT for persistent clients at the wrong point in time (on reconnect, instead of on connection loss)
  2. Disconnect by the Python client is not considered "clean" (although the Mosquitto log and Wireshark look like it was)
  3. mosquitto_pub ignores the --disable-clean-session flag (works with mosquitto_sub)

This comment has been minimized.

Copy link

commented May 16, 2019

Experiencing the same behaviour, persistent clients fire their LWT message after reconnection

@ralight ralight added this to the 1.6.3 milestone May 21, 2019


This comment has been minimized.

Copy link

commented May 21, 2019

Thanks for all the details everyone, I've just pushed a change that fixes all those points. You can try it on the fixes branch. This will be part of 1.6.3.


This comment has been minimized.

Copy link

commented Jun 19, 2019

Just a head-up that I also consider the bug fixed. I tested the fixes branch and it shows the expected behaviour.

On a side note: This bug was actually a regression, it worked fine 1.5.8.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.