Yes please. I’m fiddling with a LLAP setup (which works) as I’ve read it is significantly less resource intensive.
Do you need redis-server as well at this point? Which should be installed first; Redis or Redis-server?
I’m getting a ’ Unable to locate package build-essentials’. Should it be build-essential (which actually gets installed as part of php7.0-dev)?
My bad, that should be redis-server not redis. I didn’t expect that “that goes something like” psudo guide to be taken literally so I was less careful.
Yes, I actually cut and pasted that from your opening post as I knew those packages were needed for compiling the redis extension from PECL, but now I checked, you are right it should be just php7.0-dev.
redis-server first would be the natural choice incase the extension tests for it, you can have redis-server without the php-redis extension but there would be no use having the extension without the server. Plus you need php-pear and the other bits to install and complile the extension.
Can I join the party? 
On my DietPi LLAP setup I have
root@DietPi-Emon:/var/www# ls -la /etc/php/7.0/{*/conf.d,*/}/*redis*.*
lrwxrwxrwx 1 root root 37 Feb 14 11:58 /etc/php/7.0/cgi/conf.d/20-redis.ini -> /etc/php/7.0/mods-available/redis.ini
lrwxrwxrwx 1 root root 37 Feb 14 11:58 /etc/php/7.0/cli/conf.d/20-redis.ini -> /etc/php/7.0/mods-available/redis.ini
lrwxrwxrwx 1 root root 37 Feb 14 11:58 /etc/php/7.0/fpm/conf.d/20-redis.ini -> /etc/php/7.0/mods-available/redis.ini
-rw-r--r-- 1 root root 18 Feb 14 11:57 /etc/php/7.0/mods-available/redis.ini
I did run ‘phpenmod redis’ after the pecl inslall of redis.
Well although I don’t know exactly what you should expect, it looks good to me as it appears to have worked and you have different end points, I’m pretty damn sure you didn’t want any “apache2” links in there so this is another very good example of why you should use the right tool for the job (post now bookmarked) and not just write your own files in.
{EDIT}
I’m glad the command worked for you, I wrote that knowing where I expected the apache2 files to reside, It wasn’t intended to be generic 
Would you therefore suggest installing by apt…
php7.0-dev
php-pear
redis-server
php-redis
And then Redis by pecl?
I’m slightly confused as there seems to be no specific installation of php-redis listed but I am sure that is just a lack of knowledge/understanding on my part.
I’m just working through it trying to make it repeatable. So far I have not done it the same way twice .
I went back and corrected my post above, I currently have
sudo apt-get install redis-server php-pear make php7.0-dev
I think make is also required to compile the extension (although it is included in some dist’s like git) and php-redis is definitely not required from apt-get as that is what you are installing with PECL.
No, it’s not you, it’s just really confusing naming
redis-server is the actual Redis database package in Debian
phpredis is the redis extension for php, it allows easy use of Redis from within php code. It’s github repo is “phpredis”, when packaged for debian it’s called “php-redis” (currently at version 3.1.1) whilst on PEAR/PECL package manager it is called just “redis” as it is a php extension.
[edit]
Similarly the “mosquitto” mqtt extension for php is called “Mosquitto-PHP” but when viewed on PECL or once installed it is just the “mosquitto” extension for php. Very different to the “mosquitto” Debian package which is THE mosquitto server package, And just to add further confusion (just in case you weren’t confused enough) the “mosquitto” php extension must be called “mosquitto-alpha” or “mosquitto-beta” to install it as it hasn’t reached a production version yet.
In testing this I am finding that installing php7.0-dev installs make and php-pear as well.
When installing redis from pecl, If I then run the command;
printf "extension=redis.so" | tee /etc/php/7.0/mods-available/redis.ini 1>&2
… then looking for the links with ls -la /etc/php/7.0/{*/conf.d,*/}/*redis*.* I get
ls: cannot access '/etc/php/7.0/*/conf.d/*redis*.*': No such file or directory
-rw-r--r-- 1 root root 18 Feb 14 14:12 /etc/php/7.0/mods-available/redis.ini
If I then run phpenmod redis and check again, I get what I expect…
lrwxrwxrwx 1 root root 37 Feb 14 14:12 /etc/php/7.0/cgi/conf.d/20-redis.ini -> /etc/php/7.0/mods-available/redis.ini
lrwxrwxrwx 1 root root 37 Feb 14 14:12 /etc/php/7.0/cli/conf.d/20-redis.ini -> /etc/php/7.0/mods-available/redis.ini
lrwxrwxrwx 1 root root 37 Feb 14 14:12 /etc/php/7.0/fpm/conf.d/20-redis.ini -> /etc/php/7.0/mods-available/redis.ini
-rw-r--r-- 1 root root 18 Feb 14 14:12 /etc/php/7.0/mods-available/redis.ini
Seems like this method may be generic to the stack used.
However when I now try and run this brand new emoncms install, I get an error with Redis enabled
[edit] I rebooted the VM and it all now works
I’ll look into that, we just need to be sure all distro’s include them all in “php7.0-dev”, that’s the benifit of listing them all, there can be nothing missed. But i’m all for reducing the list if it works for all.
Did you restart the server after installing redis and the extension? the LLMP equivalent of
sudo systemctl restart apache2
Yes several times and the redis-server service so no idea why it did not pick up the changes. It was the old ‘when all else fails turn it off and on again’
Install guide now changed to install redis via pecl instead of apt-get.
It’s a shame that we have to use pecl, as apt adds the symlinks automatically, but if they are lagging behind with upgrades…
Paul
Anyone who has installed php-redis via apt who wants to update retrospectively;
sudo apt-get remove php-redis
sudo pecl channel-update pecl.php.net && sudo pecl install redis
printf "extension=redis.so" | sudo tee /etc/php/7.0/mods-available/redis.ini 1>&2sudo phpenmod redis
Reboot, and then check the emoncms Administration page. You should see redis v3.1.6 in the PHP section.
Paul
I would use
sudo apt-get purge php-redis
sudo apt-get clean
over “delete”
purge will also remove any config files and other remnants where as remove just removes the package, well in fact it doesn’t even remove it as such, you need to run “clean” to delete the package and get your disk space back.
The same as??
pi@raspberrypi:~ $ sudo apt-get remove php-redis
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
php-igbinary
Use 'sudo apt autoremove' to remove it.
The following packages will be REMOVED:
php-redis
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 401 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 105371 files and directories currently installed.)
Removing php-redis (3.1.1-1) ...
pi@raspberrypi:~ $ sudo apt autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
php-igbinary
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 86.0 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 105367 files and directories currently installed.)
Removing php-igbinary (2.0.1-1) ...
pi@raspberrypi:~ $
Both options are 2 commands.
Paul
No. all 4 do different things
remove - just removes the package from the os not from the disk
purge - removes the package and associated files like personal settings etc
auto-remove - removes any packages that are no longer required as a result of removing packages that had previously caused other dependencies to be installed.
clean - actually removes all of the above from disk, think emptying a recycle bin in windows.
so ideally you actually need auto-remove too
sudo apt-get purge php-redis
sudo apt-get auto-remove
sudo apt-get clean
or you can of course do it in one hit with
sudo apt-get purge php-redis && sudo apt-get auto-remove && sudo apt-get clean
[edit]
Try running df -h before and after running sudo apt-get clean to see the change in avaulable space.
If I recall correctly, clean only removes the .deb packages stored in the local cache.
remove - removes the installed package, but not the cached package.
purge removes the installed package and configuratin files, but not the cached package.
purge can also be used with autoremove to delete the associated config files.
From the apt-get manpage:
clean clears out the local repository of retrieved package files. It removes everything but the lock file from /var/cache/apt/archives/ and /var/cache/apt/archives/partial/
This is where the disk space is reclaimed. Every time apt-get install runs, the .deb packages get cached.
Over time, the local cache can grow quite large. Running apt-get clean deletes all the cached packages.
One final dependency. I note that ntp is in the list.
We had a discussion a while ago about the use of ntpd or timesync for time syncronisation. Ensuring emonPi / emonBase time is synchronised with an NTP server - #11 by Paul
My suggestion is that this dependency should be broken out as a separate item with a note, as installing it may disturb a previously setup solution for time syncronisation. I’m also not sure if Rasbian Stretch includes any time sync by default.
Can you elaborate Brian?
Why would ntp disturb a previously setup solution for time synchronization. Have you a example?
Paul
I’m not convinced it’s an emoncms dependency, yes emoncms needs to know the correct time and possibly the TZ, but it get’s that from the OS, If the OS is dependent on NTP that’s a different matter and needs addressing elsewhere IMO. However, if the OS has fully functional time and date then why are we installing NTP on top?
Stretch no longer uses ntp or ntpd, the timekeeping is done via timedatectl
pi@raspberrypi:~ $ timedatectl status
Local time: Mon 2018-02-19 00:54:43 UTC
Universal time: Mon 2018-02-19 00:54:43 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
Personally I have never included ntp on my emoncms dependencies list and I’m unaware of any consequence of that, having said that it was included with wheezy and Jessie distros, but it is not in Stretch.
I too would have concerns about having 2 time syncing system active on one device, it is possible to disable the timedatectl service and install ntp, but I do not know if the ntp installer would be clever enough to disable the timedatectl or if indeed it is essential to do so, but I don’t see this as a emoncms concern as it’s an OS issue.
Which in itself maybe a problem with the RO filesystem as discussed in the linked thread.
I don’t know that it would, but equally as the move is to timedatectl, the method to synchronise time should be left to the user rather than be foisted on them with no real explanation or warning.
Totally agree.
TBH, that’s why I left NTP in the build guide, to ensure that if timedatectl couldn’t write to /var/lib/systemd/timesync/clock because of the read-only OS, then at least NTP would manage timekeeping.
But if it’s not needed, I’m happy to remove.
Paul, are any of your OS’s read-only?
Paul