Read this if your Mosquitto is broken

[Paraphraser]

Mosquitto quick fix

If you have just upgraded Mosquitto by doing:

$ cd ~/IOTstack
$ docker-compose pull
$ docker-compose up -d

and find that Mosquitto is no longer working, you have two options for getting your IOTstack working again:

1. Pin to version 1.6.12 (quickest)
2. Edit the configuration file (needs more thought)

Pin to version 1.6.12

1. Edit the mosquitto service definition in docker-compose.yml to pin to version 1.6.12. Something like this will get the job done:

     mosquitto:
       container_name: mosquitto
       image: eclipse-mosquitto:1.6.12
   #   image: eclipse-mosquitto
   

2. Repeat the upgrade process:

   $ docker-compose pull
   $ docker-compose up -d
   

   Mosquitto will downgrade to the previous version and resume its previous behaviour.

Edit the configuration file

The default configuration file for Mosquitto looks like this:

persistence true
persistence_location /mosquitto/data/
#log_dest file /mosquitto/log/mosquitto.log
# To avoid flash wearing
log_dest stdout

#Uncomment to enable passwords
#password_file /mosquitto/pwfile/pwfile
#allow_anonymous false

#Uncomment to enable filters
#acl_file /mosquitto/config/filter.acl

log_timestamp_format %Y-%m-%dT%H:%M:%S

The active version of the configuration file is at the path:

~/IOTstack/services/mosquitto/mosquitto.conf

You need to make the following changes to the active file:

1. Add this line (anywhere in the file):

   listener 1883
   

2. If and only if you have not implemented a password scheme for Mosquitto then allow_anonymous will still be commented-out. You need to change it to look like this:

   allow_anonymous true
   

   If you have previously implemented a password scheme for Mosquitto then allow_anonymous will be active and false, and should be left that way.

After you have edited the configuration file, apply the changes by doing:

$ docker-compose restart mosquitto

Mix-and-match

The configuration file changes described above are compatible with 1.6.12 so you can apply them while 1.6.12 is running, and take the decision to upgrade to version 2.x later.

Known issue with IOTstack Mosquitto configuration file

Under new menu (master branch), there is a known issue 258 where the active version of the Mosquitto configuration file can be overwritten by a menu run. Keep this in mind and make a backup.

Reference

See Migrating to Mosquitto 2.0.

[howwww]

Hi, and thanks for sharing! I searched all the internet what is going wrong before read this issue here! :)

I've managed to fix the issue by using the configuration method described above.
I just want to add that in order to make it work I had also to uncomment the "#password_file" line.

Please update instructions for users that have previously implemented a password scheme for Mosquitto.

[wijnsema]

Thank you for this post @Paraphraser! I searched and tried for hours before I stumbled on you advise and could fix the problem in seconds.

Of the two options I would strongly suggest the second one, adjusting the configuration, because that way you solve the problem for good, if you switch back to 1.6 this problem will pop up again in the future.

[Paraphraser]

@howwww see if this gist meets your needs.

[Paraphraser]

@wijnsema the truly cool thing (or, at least, I think it is cool) about Docker is how easy it is to revert.

Sure, once you know a solution to a problem, it is definitely better to fix it properly.

But, if something has just gone pear-shaped, reverting to "last known good" lets your IOTstack keep truckin' and your IoT devices sending their data. You then have the luxury of breathing, thinking, and taking your time.

You might, for example, want to test that the fixes you've found in a GitHub issue actually work on a test system before you put them into production. After all, there's no guarantee that they are correct for every IOTstack user's situation. 🤪

Granted, reverting doesn't always cure every evil. There was a PiHole fiasco a few versions back where the upgrade didn't work but did sufficient "damage" to the database in PiHole's volumes folder that reverting didn't work either. At least, not straight away. It took a combination of reverting and restoring PiHole's volumes folder from backup to get going again.

[wijnsema]

@Paraphraser indeed Docker is wonderful, it really changed the IT landscape, but I will not use docker-compose pull anytime soon!

Regarding fix/upgrade, it really depends on the situation. In mine, I just started with Iotstack so I want the newest versions.

Now up to my next problem, timescaledb fails to start after the docker pull, when it worked before (Segmentation fault, no idea were that comes from).

Anyway, have a nice day (or evening).

[Paraphraser]

@wijnsema I may be slightly more gung-ho with the PULLs because I run a test system in parallel with the live system. In fact, one of the main reasons why I developed Paraphraser/IOTstackBackup ahead of the game was so that I could guarantee that my test system's data and config was reasonably close to the live system. I always do a "apply mild vacuum and witness the result" on the test system before trying it on my live system. I'd be a heckofalot more cautious if I only had a single Pi to work with. 😎

[howwww]

@Paraphraser looks perfect. Keep up the good job guys, you really helping us a lot!

[bburkett52]

Thanks for the quick fix!! Really saved me!

Best regards,
~Bob

[iLeftheris]

Thanks for sharing!