Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Trouble with wills and retain, not sure where 
Ben Hardill <hardillb@xxxxxxxxx> writes:

> You MUST set the LWT before connecting, the payload, topic, qos and
> retained status are all included in the CONNECT packet and will not be
> changed if set after connection.
>
> So moving it to the on_connect callback really won't work.

Thanks.  I had it there before.  It was not clear that there wasn't a
"set lwt" messsge that could be sent later, and the paho mqtt docs
didn't say that, and paho mqtt didn't throw an exception when I called
it later.  Wrong list I know :-)  But I moved it back.

If there is a netflake and paho mqtt reconnects, it seems obvious it
should send the lwt on the new connection.

> The mosquitto log implies the client closed down cleanly so will not
> trigger the LWT. Do you have a signal handler in the python code that
> is closing the connection? If so this should be manually sending the
> offline message before exiting.

I did not write any code about signals.  I set mqtt callbacks, and
start the paho loop, and then have logic that does

while true
  poll ups
  figure out if we should send a message and if so do
  wait 2s

The paho mqtt docs did not hint at signal handling and cleanup.  That
would seem like a bug, as if the program exits without the paho mqtt
user doing an intentional clean mqtt shutdown, one wants the lwt to
fire.

> Do you see different behaviour if you kill it with -9 (you may have to
> wait 1.5 the keepalive)?

No, I get the same behavior with -9 as the impliciation SIGTERM, and
SIGINT from the terminal.

I'll watch the connection and see if there is data send on killing it,
vs just a FIN.  (This is TLS.)

I waited until after data message and keepalive happened, and hit ^C.
This got me:

  ^CTraceback (most recent call last):
    File "./ups2mqtt.py", line 324, in <module>
      time.sleep(2)
  KeyboardInterrupt

The keepalive is in the first block and the second block immediately
followed a ^C.   You can see a FIN with no data, acked followed by some
content from the broker and the broker's FI, both which elicit a reset.
So there's no graceful shutdown message.

14:55:17.611074 IP6 ups-client.64975 > broker.secure-mqtt: Flags [P.], seq 310:334, ack 53, win 16560, options [nop,nop,TS val 132 ecr 124], length 24
14:55:17.611305 IP6 broker.secure-mqtt > ups-client.64975: Flags [P.], seq 53:77, ack 334, win 16560, options [nop,nop,TS val 133 ecr 132], length 24
14:55:17.875684 IP6 ups-client.64975 > broker.secure-mqtt: Flags [.], ack 77, win 16560, options [nop,nop,TS val 133 ecr 133], length 0

14:55:28.779500 IP6 ups-client.64975 > broker.secure-mqtt: Flags [F.], seq 334, ack 77, win 16560, options [nop,nop,TS val 155 ecr 133], length 0
14:55:28.779569 IP6 broker.secure-mqtt > ups-client.64975: Flags [.], ack 335, win 16560, options [nop,nop,TS val 155 ecr 155], length 0
14:55:28.780011 IP6 broker.secure-mqtt > ups-client.64975: Flags [P.], seq 77:101, ack 335, win 16560, options [nop,nop,TS val 155 ecr 155], length 24
14:55:28.780059 IP6 broker.secure-mqtt > ups-client.64975: Flags [F.], seq 101, ack 335, win 16560, options [nop,nop,TS val 155 ecr 155], length 0
14:55:28.850469 IP6 ups-client.64975 > broker.secure-mqtt: Flags [R], seq 1296025920, win 0, length 0
14:55:28.850473 IP6 ups-client.64975 > broker.secure-mqtt: Flags [R], seq 1296025920, win 0, length 0


Do you mean to suggest that getting a FIN counts as "shouldn't publish
lwt", as opposed to an OS-level error from connection timed out?  That
seems like the wrong choice to me, based on what I want this minute, but
I should read the spec.

I can try breaking the TCP connection with a firewall and see how that
goes.

Thanks for the comments.

Greg

Attachment: signature.asc
Description: PGP signature

Back to the top