@glyn.hudson @TrystanLea could you test and see if the logrotate is working please? I’ve only checked on my Ubuntu setup so far but the permissions on the additional conf files are not correct on that.
yes looks like its working here, but there’s an issue with the emonPiLCD looking for file /home/pi/data/emonbase…
Not sure why the emonPiLCD script got that far on my system, there is a earlier check to see if the system has an LCD connected that it somehow got past even though I’ve no LCD present. After restarting the script it stopped in the right place. I’ve added a directory check as a second check just in case: check if dir exists before trying to create file · openenergymonitor/emonpi@c3ad4a5 · GitHub
Discovered another issue, not sure how I missed this one last time, there is excessive write load on the OS partition relating to writing and updating php session files when a browser window is open with an active emoncms session running (e.g looking at the feed list). Placing the /var/lib/php/sessions directory in a tmpfs solves the issue, see:
Write load from php sessions · Issue #50 · openenergymonitor/EmonScripts · GitHub
It’s an easy update to /etc/fstab if anyone is testing with this image already:
sudo nano /etc/fstab
add line at the bottom of the file:
tmpfs /var/lib/php/sessions tmpfs nodev,nosuid,size=1M,mode=1777 0 0
then reboot.
Write load testing
I’ve added my write load testing script to emoncms/usefulscripts
usefulscripts/writeloadtest at master · emoncms/usefulscripts · GitHub
to install:
cd /opt/emoncms/modules/usefulscripts
git checkout master
git pull
add apikey to writeloadtest.php:
nano usefulscripts/writeloadtest/writeloadtest.php
install service:
sudo ln -s /opt/emoncms/modules/usefulscripts/writeloadtest/writeloadtest.service /lib/systemd/system
sudo systemctl enable writeloadtest.service
sudo systemctl start writeloadtest.service
the write load stats then show up in emoncms inputs:
log them all to feeds at 60s interval so that you can keep an eye on write load over time, e.g:
the high write load in the above screenshot was caused by the php session file updates, over night I did not have a browser window open, hence lower write load.
Worth switching off the logrotate for a while and trawling the system logs for things like this.
I have updated the emonSD-02Oct19 image to include the fstab modification, fixing the php session write load issue.
I’ve added a new feature to make write load testing easier. The write load is now shown in the emoncms admin page:
The period over which the write load is recorded can be reset by clicking on the Write Load Period: Reset button.
This is currently in the emoncms master branch, I will be merging to stable soon.
@glyn.hudson and I have been working on fixing a couple of issues with the emonPiLCD script and emonPi LCD button operation on the new image.
We’ve also fixed the issue resulting from the new VirtualHost configuration where hostname/emoncms/feed/list is now hostname/feed/list by adding a htaccess redirect so that old dashboards and API’s will automatically redirect to the new locations.
We will be doing a fresh image build this week with latest changes and then repeating another set of tests - before we can hopefully launch this image properly.
Did that include making it Python 3 compatible (as 2 is dying very soon)?
I’ll get my hat…
The latest image build is now available: emonSD-17Oct19. See details in first post above.
We are in the process of repeating our testing to ensure that its all working, looking good so far.
Was this from the Stable EmonScripts branch?
yes, latest stable for all repositories
once the image is considered stable, let me know and I’ll copy it on my box as alternative dl site.
I meant the EmonScript branch used?
yes also stable branch v1.0.1-beta
The emonSD-17Oct19 image is working well in our testing here, we are happy that this has reached release point and will be the standard image shipped from our shop for new orders starting this week!