Phantom Duplicated MQTT Topics after reboot

glyn.hudson · 20 May 2017 13:07

A while back MQTT input script was changed to use systemd, it should wait for msql and redis to be running:

emoncms/emoncms/blob/master/scripts/mqtt_input.service#L32


      
          #  See COPYRIGHT.txt and LICENSE.txt.
          #
          #  ---------------------------------------------------------------------
          #  Emoncms - open source energy visualisation
          #  Part of the OpenEnergyMonitor project:
          #  http://openenergymonitor.org
          ###
          
          [Unit]
          Description=Emoncms MQTT Input Script
          After=mosquitto.service mysql.service redis-server.service
          Documentation=https://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/MQTT.md
          
          [Service]
          Type=idle
          ExecStart=/usr/bin/php /var/www/emoncms/scripts/phpmqtt_input.php
          
          # Uncomment instead of above to use standard log file, else use systemd log
          # Type=forking
          # ExecStart=/bin/sh -c '/usr/bin/php /var/www/emoncms/scripts/phpmqtt_input.php 2>&1 > /var/log/mqtt_input.log &'

However, redis and apache get started in rc.local after the log folders are created in /var/log, this is need since the /var/logis mounted in ram as tmpfs. I can’t see any harm in added a delay into the MQTT input systemd service to ensure all services are up and running properly.

Are you familiar with how to delay a systemd service from starting? It looks like we would need to involve a .timer file

kevin · 20 May 2017 20:55

Why not just change the MQTT script to start from rc.local too?

pb66 · 20 May 2017 21:24

Or better still write a new service and prioritize it to run early in the boot process just to create all these log files before any of the affected services need them, that way the system can work as it was intended rather than being undermined by all the entries in rc.local that could then be totally removed. No delays, no restarting of services, everything would effectively work just as if the logfiles were never lost.

glyn.hudson · 20 May 2017 21:53

Mmm yeah good suggestions, either of those options could work. However it could get tricky trying to upgrade existing emonPi’s. Before we get carried away it would be good to establish if this is indeed the cause of the issue. I’m struggling to recreate this issue.

borpin · 22 May 2017 18:14

I suspect this is a linked topic