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

LWT not sent on exceeded timeout #1143

salcedo opened this Issue Feb 3, 2019 · 4 comments


None yet
3 participants
Copy link

salcedo commented Feb 3, 2019

Mosquitto version: 1.5.5

The following code is used to test LWT functionality in mosquitto over websockets.
There is a load balancer (traefik) that directs the websockets connection to mosquitto.

import signal
import sys
import time

import paho.mqtt.client as paho

client = paho.Client(

def signal_handler(sig, frame):
    global client

    print('sending connection status: 0')
    client.publish('$CONNECTED/tracking', '0')

def publisher():
    global client

    client.username_pw_set('user', 'password')
    client.will_set('$CONNECTED/tracking', payload='0 (lwt)', retain=True,

    client.connect('mosquitto.lan', 443, keepalive=5)

    print('sending connection status: 1')
    client.publish('$CONNECTED/tracking', '1')

    while True:
        print('sending test message')
        client.publish('tracking/messages', 'test message')

if __name__ == '__main__':
    signal.signal(signal.SIGINT, signal_handler)

When there is an unclean disconnect (python script is killed with SIGKILL - not SIGINT), the LWT is sent, as expected.

However, unplugging the device's network cable to simulate a loss of connectivity results in mosquitto logging the following, and no LWT is ever sent:

1549215540: Client tracking has exceeded timeout, disconnecting.
1549215541: Socket error on client tracking, disconnecting.

Should a LWT be sent in this case? How is one to know when a client is offline if no LWT is sent on timeout?


This comment has been minimized.

Copy link

ralight commented Feb 3, 2019

It should be sent, the only case a MQTT 3.1.1 will shouldn't be sent is when the client sends a DISCONNECT. I'll take a look.


This comment has been minimized.

Copy link

ralight commented Feb 3, 2019

I've fixed this in my local branch which will be part of 1.5.6 soon. Thanks very much!

@ralight ralight closed this Feb 3, 2019

@ralight ralight added this to the 1.5.6 milestone Feb 3, 2019


This comment has been minimized.

Copy link

karlp commented Feb 4, 2019

Was this a regression? I know I've tested cable pulling before.


This comment has been minimized.

Copy link

ralight commented Feb 5, 2019

Just on websockets, yes.

ralight added a commit that referenced this issue Feb 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment