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
I haven’t updated my RO images to Stretch yet, but timekeeping and handling the RO status have nothing to do with emoncms, that’s the OS. Even “ntp” will not work on RO OS’s without installing the “ntp-backup” mod. Any changes made to overcome the RO changes should be part of those RO changes, otherwise those changes are incomplete.
Just adding “ntp” to the dependencies will not make the fake-hwclock file writable, nor will it include Glyns more recent hack to reset the time after boot as that too is a separate bespoke mod, AFAICT adding ntp to the dependencies here in the emoncms install guide has no purpose, unless emoncms is dependent on it regardless of whether it’s an RO OS or not.
Questioning the necessity of the packages is a good thing, we should only be installing what is necessary to this part of the install, as a rule rather than justifying why it should be removed, we should be removing everything we cannot justify keeping in.
Perhaps we should even include a little table or list of dependencies and why they are needed and what they do as part of the guide, that would help with questions like these and a couple of years down the line we will all know why we included certain packages. Take the dio PECL package as an example, if it was documented that we were installing that to support accessing the serial port direct from emoncms, it may have been dropped in any one of the many documentation revisions there has been over the years.
From another recent discussion about installling emoncms
I get the impression he was rather stressed by the issue he was battling when he wrote that comment, but tone aside, its a fairly valid point.
No worries, NTP has now been removed from the dependency list in the messy sudo-code-dump.
It’s great that we are having these conversations, because writing & updating the build guide should be a shared responsibility.
Paul
I agree
That is a very good idea!
Yes I’d agree with that. I’ve been in that place too which is partly why I’ve been trying to rationalise it and attempted to make it consistent.
Yes, sorry about that. It’s just quite annoying having to figure out dependencies from a list of packages for a specific Linux distribution and then ending up with something that doesn’t work as intended - the process of then figuring out if it is a missing dependency or actually a bug is rather annoying and IMHO unnecessary.
Apart from NTP I think the “ufw” package is also unnecessary as it is completely unrelated to the emoncms installation/functionality and is just confusing if one tries to figure out the general dependencies for installation on other OSes.
I’ve created PR #807 with these/some fixes/improvements to the LinuxInstall guide: remove ntp, ufw from package list; clean up sudo-code by rostwald · Pull Request #807 · emoncms/emoncms · GitHub
It’s probably worth pointing out that I didn’t write or maintain the Linux docs, as I don’t have a Linux installation to test.
I just wrote the messy sudo-code-dump. 
To be fair - those code-dumps are better than nothing at all (e.g. just a install-script and no documentation at all) and at least you put them in the docs.
It might be that I’m more old-fashioned about becoming root to get the job done and drop privileges afterwards instead of wasting my time typing sudo a couple hundred times a day. So if I see instructions that begin with sudo on each and every line, my eyes begin to bleed 
sudo, as in the command? or pseudo, as in artificial? (to avoid any possible confusion)