. I’ve tested on two separate rPi 3B+ devices. Same issue on both.
. Issue apparent upon fresh install, no changes, no updates.
. I’m connected over ethernet.
. Makes no difference running emonBase update as of today.
. SHHing in early during the boot process it can be observed the moment when the issue becomes apparent.
What’s in the way of myself, and others here probably, making and sticking to correct information is impetuousness.
I’ll might make more mistakes… I’ll try into the future to keep it accurate
My previous post though was accurate. Both the screenshot and clipboard are taken from the same view seconds apart on a rPi3B+ that’s been running for a while on the Jun2018 image. This could be put down as a separate bug as it’s repeatable behaviour. The behaviour was inherited from the Oct2017 image.
The comments about correct info are in no way aimed at you Dan (or others that take info at face value) I would perceive you as the victim of the mis-information rather than the perpetrator.
This is not the first time that it has been noticed that the buffer shows as “loading” whilst debugging other issues, this is the first time it has been reported that there are inconsistencies between the page and the clipboard version.
I wonder how much time has been lost pondering on why the buffer is “loading” rather than pursuing the real issue unhindered by that mis-information.
What is really frustrating for me personally is the fact I objected to the way the copy to clipboard was done at the time. The data is collected independently for each method (screen or copy) so there could potentially be vast differences, unless you open the server info dropdown and manually go through checking each and every word, you do not know if what you (the user) are offering as fact is indeed so. There is also 2 lots of code to maintain.
Regarding the issue at hand…
What I find more interesting is the fact you have 0 keys and 0 running time for Redis, the server time suggests it’s not just been rebooted, but it does differ to the previous server info so I guess you are rebooting and restarting stuff. How long has it been since you tried to restart redis or rebooted?
30% CPU load when it’s not actually doing anything (ie no keys etc) might suggest it’s sruggling to get started, perhaps that high load is it trying to connect or create a log file or something else preventing it getting up and running.
What do you see if you try to restart it from the command line?
sudo systemctl restart redis-server
have you checked the redis logs and emoncms logs?
What are your Redis settings in emoncms/settings.php?
have you tried flushing redis (very long shot but worth ruling out)
 Oh! And another long shot, are there any redis files in /var/lib ?
sudo ls -la /var/lib/redis/*
[edit2] Also was it doing this before you started the SMA inverter/pvoutput stuff? Or have you since retested on a vanilla image? It’s just that you mentioned editing the rc.local file and that is also where the redis-server (and other) logfiles are created and then the services restarted. Can you confirm there is a logfile for redis created during startup?
sudo ls -la /var/log/redis
[edit3] Issue opened about the difference in reported info
and based on the Server Information, its a “fresh install” of emonSD-13Jun18.
In the other thread that this post started in, I’m pretty sure dan mentioned he’d been able to reproduce it from a freshly imaged SD Card, so I have been assuming when he says “fresh install” above, that he really means “SD Card with a freshly written image booted up for the first time”.
@danbates, can you confirm when you say “no changes, no updates”, you mean exactly:
Write emonSD-13Jun18 image to SD Card on another machine
Aug 19 12:34:29 emonpi systemd: [/lib/systemd/system/redis-server.service:14] Unknown lvalue 'RunTimeDirectory' in section 'Service'
Aug 19 12:34:29 emonpi systemd: Starting Advanced key-value store...
RunTimeDirectory sounds important, it looks like its value couldn’t be loaded from the config?
There’s no errors in the redis-server.log indicating there’s an issue though, but probably worth checking anyway.
And then only a few months ago on the same page, it was reopened again:
So, is it worth changing the case of “RunTimeDirectory” to “RuntimeDirectory” in /lib/systemd/system/redis-server.service (should be on line 14) and see if there’s any change?
[Edit] worth noting that the actual fix in the bug report linked above is
[Edit #2] I just checked the man-page for systemd.exec and the RuntimeDirectory directive is used to create runtime folders under a root folder as defined in the following table, so likely there are runtime folders that are expected to exist but do not.
Table from man-page:
More usefully is actually understanding why “sudo ls -la /var/lib/redis/*” doesn’t work. See this post of mine here.
In previous distributions that file would have been deleted as part of the “making read-only”. It was recently discovered (in that thread I just linked to) that there was an error in the build guide which leaves that file behind causing other issues (as per that other thread). Try removing it using:
sudo rm /var/lib/redis/dump.rdb
Ok, looks like once the folder was there, all it created in that folder was the .pid file (which is normally used to track what PID the process is running under) so it probably didn’t have any consequences beyond logging an error in syslog on service startup.
See how you go removing the dump.rdb file from /var/lib/redis.