I have been using a standalone Emoncms (v3) on a Pi for over a year tracking some temperature sensors in my house - 5 individual feeds taken every minute. My post-Christmas project was deploying a RFM12Pi and emonTx to monitor my PV system.
Because my Pi is doing other things I upgraded to the latest Emoncms software and rfm2pigateway.py as per the instructions rather than taking the complete SD image and I wanted to ask the forum if a behaviour I am seeing is normal.
As a test I attached one CT to the emonTx v3 and everything worked first time with data arriving as expected on the input page. I left things to soak and the following day, via the 'top' display, noticed the Pi was constantly spawning 'fuser' processes from a shell script which I had not noticed before making the ssh session sluggish. After investigation I found an /etc/cron.d/php5 script housekeeping php5 session files from /var/lib/php5:
/etc/cron.d/php5:
find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)While rfm2pigateway.py is running, whether it is receiving data or not, php5 session files are created at a rate of more than one a second. /etc/cron.d/php5 is set to run at 9 and 39 minutes past the hour but due to the rate the session files are created it does not finish before the next /etc/cron.d/php5 script kicks in 30 minutes later.
The new instance together with the earlier invocation does start to make head-way and catches up with deleting, however any reprieve is short-lived leaving the script running almost all the time. I have seen over 5000 session files and with rfm2pigateyway stopped it took about 15 minutes to clear the back-log which implies it does catch-up once a second instance gets to grips with the task.
Given that the emonTx only sends data every 10 seconds the rate of session files seems excessive. I have googled in and around the topic and it seems the cron method is a Debian fix due to the ownership of /var/lib/php5 not being able to use the php5 built-in garbage collection. I have also seen suggestions of removing the fuser in the php5 script to make it execute faster and that with two instances running they could get into conflict with file locking.
Any advice on whether this is normal, changing the housekeeping job or reassurance that I am worrying about nothing gratefully received.
Re: Housekeeping php session files
I don't know about your problem.
On a different topic, the python script is not really maintained. Since I created the standalone gateway, it looks like people use either the php script as emoncms RPi module or the standalone gateaway. Since the standalone python gateway exists, there is no real need to maintain the emoncms module python script in parallel.
Is there a reason (a feature ?) you are using it in place of the php script ? If so, you may want to consider using the standalone gateway.
I don't think this is linked to your issue, though. This is just for your information.
Re: Housekeeping php session files
Ok, so it sounds like I may have two challenges. I chose the py route as I have been trying to learn the language, but it sounds like I could be leaving my system in a bit of a dead-end. I'll fire up the php route so at least I'm in a more knowledge populated area.
Maybe a php only solution will not generate so many session files . . .
Thanks for the advice.
Re: Housekeeping php session files
Many thanks Jérôme, sound advice. I switched to the php method and now I only see session files for each time I login into the emoncms system.
Re: Housekeeping php session files
Great.
If you are interested in python, you may want to have a look at the standalone gateway.
https://github.com/Jerome-github/oem_gateway