Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
mosquitto dies after SIGHUP on Raspberry Pi #849
I've a quite strange behavior on my RPi running Raspian Stretch since the last update a few days ago: mosquitto dies after SIGHUP (happens every morning due to the logrotate script).
I just cloned the repo and built from source and found the same behavior. My configuration is
This configuration opens two listeners, the default listener at port 1883 without tls and without passwords and a second listener at port 8883 with tls and with passwords.
I started debugging on the RPi and inserted some printf's and found that mosquitto died in security_default.c, mosquitto_security_apply_default, line 864 (line 870 in my fork at github.com:wollud1969/mosquitto) since context->listener is null.
The listener is not set.
For easier debugging I switched to my laptop (Debian Stretch), prepared an environment with exactly the same configuration (well, nearly the same: paths for persistence, pwfile, certs and keys are different, content is the same).
But on the laptop I got the following output:
Here, the listener is set.
I found a difference in the evaluation of the configuration between RPi and laptop:
I got in the logfile:
So, appearently it trys to open the default listener on port 1883 and an additional listener on port 1883, which fails.
On the laptop this works, only one listener is opened on port 1883. Actually, when I change the first listener statement on the laptop to port 1884 no listener on port 1883 (default listener) is opened at all.
I'm trying to track this down even more but currently I got lost in all the context and HASH stuff. But maybe someone else has an idea why mosquitto dies on the RPi on a SIGHUP. I'm trying to continue in understanding the internals of mosquitto while tracking down this even closer but so far I want to share this intermediate results with you.
Well, it appears that the context with the missing listener was loaded from the database. It wasn't a current context. Maybe it remained from before the update and the context structure has been changed in between or so. Has it?
Is there a tool to dump the database and inspect it?