v246: Issue with TMPO [solved]

After upgrade to firmware v2.4.6 I recognized today that no more TMPO data was registered; the persisted information seems to have stopped at the time of the upgrade.
ps shows that the tmpo-daemon is running
684 flukso    5280 S    /usr/sbin/fluksod -u flukso
but there is no activity in the storage folders
/usr/share/tmpo/sensor/0
There is actually a difference to a backup I made prior to the update, but this "newer" content seems to stop at timestamp 1436876800 (14.07.2015 14:26:40) - no more readings persisted after this point in time... (luckily I have my parallel MQTT tracker running, so I know there were readings)
(also a reboot did not change this behavior - everything else seems to run smoothly)

gebhardm's picture

May this be a user:group issue? The /usr/share/tmpo folder and its subfolders are owned by flukso:flukso, everything else is root:root?!

icarus75's picture

I'll look into this later today. Make sure to keep your FLM online.

icarus75's picture

Could you patch tmpod.lua with this commit? Let me know whether the patch fixes the issue at your side.

gebhardm's picture

This one alone didn't do it, I had to change line 131 in the same manner...

  1.                 if tonumber(section) -- sensor entries only
  2.                 and params.enable
  3.                 and params.enable == 1

But now it seems to work again :-)

gebhardm's picture

Hmm, it registered three MQTT messages and went silent again (also after full reboot) :-/

gebhardm's picture

I tried by deleting the content of the /usr/share/tmpo/sensor/<sensor id>/0/8 folders, as they where empty prior to the patch, but this after reboot had also no effect - tmpod restart "works", but no readings are saved.

icarus75's picture

Can you undo the change you made to line 131 and try again? Please note that it can take up to 256secs for a block8 to be written to flash.

gebhardm's picture

Undone the line 131 change and restarted the tmpo-daemon; now there are indeed readings again; I'll keep watching for the night...

gebhardm's picture

Seems solved - the "it can take up to 256secs" cured my errorenous gut feeling misbehaviour which is fed by keeping in parallel my store on second base ;-)
I hereby declare the issue closed :-)

For all others:

  1. Log into your FLM via ssh: ssh root@<your FLM IP address>
  2. Provide password (default: root)
  3. root@flukso:# cd /usr/sbin
  4. root@flukso:/usr/sbin# vi tmpod.lua
  5. Use arrow down key to go to line 154
  6. Go via right arrow key to the "1" - press i for <insert>
  7. Change the "1" to 1 using backspace and arrow keys (trust yourself) - it should read now:
  8.      and params.enable == 1
  9. Press ESC
  10. Press :
  11. Type wq to write and quit vi (lovely editor, isn't it?)
  12. At the command prompt type
  13. root@flukso:/usr/sbin# ps | grep tmpod
  14. root@flukso:/usr/sbin# kill <process id of  /usr/sbin/tmpod -u flukso>
  15. Type now at the prompt
  16. root@flukso:/usr/sbin# /usr/sbin/tmpod -u flukso
  17. to start the tmpo-daemon again.

That should fix it.

icarus75's picture

Better still: I'll shortly release a 247 fixing this one.

gebhardm's picture

Still registers readings, so everything fine for now :-)
By the way, my query script also works as a daemon, exactly like the tmpod - so https://github.com/gebhardm/flmlocal/blob/master/usr/sbin/queryd.lua may be an alternative to the tmpod-integration of a query functionality (and already available); a ln -s /usr/sbin/queryd /usr/sbin/luad makes it automatically startable, if you dare to integrate it into the startup routine...