Installing emoncms - redis problem

(Dave Howorth) #16

As I said, openSUSE uses different commands.


(Brian Orpin) #17

What does

pecl list-upgrades



What is different? pecl seems to be available?


(Dave Howorth) #18

Turns out pecl isn’t in it though :frowning: It’s in php7-devel so:

$ pecl list-upgrades
WARNING: channel "" has updated its protocols, use "pecl channel-update" to update
Channel No upgrades available

As I said, I installed the extension from the repo. The data structures in /etc/php are completely different and I shouldn’t be poking things in there anyway.

I still don’t understand why that error appears, and nobody has yet pointed me to however pecl manages multiple versions of extensions.


(Brian Orpin) #19

Which is why the instructions say to install dev (devl in openSUSE I gather).

I’d suggest uninstalling the php7-redis package version, add in the pecl version and then enable the extenstion (phpenmod usually).

You will see the command pecl channel-update is suggested in the install instructions.


(Paul) #20

I think they use different packages too.

There are different redis extensions for php and they are not all the same. The one used by emoncms is “phpredis” and another that i’m aware of is “predis”. I have no idea what it is that the opebSUSE repos are serving up, there isn’t much to go on at the openSUSE site (

“phpredis” is available from various places, direct from github, from PECL and from the Debian repos. We use the PECL route as the debian repos were always too far behind and building from source (github) was over complex.

When installing “phpredis” via PECL (known as just “redis” on PECL) there are minor additional steps, ie it needs to be enabled. The error you are seeing is because emoncms cannot create a class, that is because either the extension is not installed AND enabled, or redis-server is not installed AND running AND configured in settings.php, we can see your settings are right and that the redis-server is running so it looks likely to be the extension. But installing to openSUSE is not a well trodden path so potentially nothing is certain.

I do not know anything about openSUSE but I suspect installing PECL and then “redis” (aka phpredis) as per the emoncms guide (amended for any openSUSE differences) might be the way to go.

Whilst I’m writing I can see you’ve done just that so . . .

That warning is standard and all you need to do is follow the instruction and run pecl channel-update (using sudo if required perhaps?)

The data structures may be different, but you will still have a folder that lists all available php extensions and you will probably need to create a file in that location and the enable the extension using whatever method openSUSE uses, I can only tell you how it’s done in Debian based distros. (It maybe the same and use phpenmod too? I really have no idea)

The version is controlled by the command issued to install via PECL, pecl install redis will give you the latest stable version where as pecl install redis-4.0.2 will install v4.0.2 (for example).


(Dave Howorth) #21

Again, I prefer to run the stable distro versions of things to avoid random breakages.

I just wrote a little PHP script:


if (class_exists('Redis')) {
    echo "redis is there";
else {
    echo "no redis";

and it says:

$ php ./test_redis.php
redis is there

so I don’t understand why process_settings.php is failing to find the class?


Startup & systemd - a personal view
(Brian Orpin) #22

The pecl packages are stable! I’ve offered the best solution to your problem but YMMV.


(Paul) #23

I’m certainly no expert, but I have spent an enormous amount of time getting my head around it and then trying to relay that info to others. I was already trying to figure this one out, but the use of openSUSE is a bit of a curve ball.


(Dave Howorth) #24

Thanks guys for looking. I’m stopping for the night now, so will look again in the morning with a clearer head.


(Paul) #25

It seems Predis and Phpredis are the only 2 Redis clients for PHP “recommended by Redis” (yellow stars, I don’t know what “openSUSE php7-redis” actually is, maybe it is Predis or Phpredis just packaged up differently (or not?).

What is listed in the last section of the server information on the emoncms admin page?

Looking at nothing more than the version numbers, it could well be phpredis in another guise as the latest stable version for both phpredis and openSUSE php7-redis is 4.2.0, that can’t be just coincidence can it ???

That said, AFAIK emoncms has only been tested with 4.1.0 not 4.2.0 if that makes any difference. I’m still running 3.1.6 on my live servers as it works fine and I have been caught out by various issues with different versions on multiple occasions, very much a case of “when it ain’t broke, don’t even think about fixing it”

Can you also check the redis-server service status directly, just in case any other info pops up when checked directly rather than using [email protected]

sudo systemctl status redis-server

(Brian Orpin) #26

@pb66, is there a simple way to test if the extension is installed correctly?


(Paul) #27

That’s a bit of a loaded question. I guess something like the small script below would prove if PHP was able to connect to Redis on a basic level.

    $redis = new Redis();
    $redis->connect('', 6379);
    if ($redis->ping() === "+PONG") {
        echo "Successfully connected to Redis!".PHP_EOL;
    } else {
        echo "Failed to get response from Redis!".PHP_EOL;

Save the above code to a file called test_redis.php and run from the command line

[email protected]:~$ php test_redis.php
Successfully connected to Redis!

Note this will also fail if Redis itself is not running or contactable, it assumes a localhost instance on port 6379. It may also pass if any Redis extension is installed and working if it has the same basic functionality, that might not mean it works fully with emoncms as we do not know if/what the differences are between extensions.

The earlier test (presumably using php -i) that gave us the version number and reported the php “serialiser” was available, tells us that there is a redis extension enabled but that doesn’t confirm it was fully installed correctly, fully operational or fully compatible. It must be to a degree to report it’s enabled.

If it is fully installed correctly, fully operational or fully compatible, then it should not be throwing an error in emoncms. It would also throw the same error if Redis was not running or contactable, that’s why I asked for the confirmation of the “redis-server” service.

Making many unsupported assumptions leads me to think that the openSUSE php7-redis package is (most likely) phpredis repackaged just for that distro as it is not specifically listed at the phpredis repo. Therefore, maybe the PECL installer isn’t able to install to openSUSE or at least we do not know what the additional commands and paths might be, we know they differ for different Debian based distros but without knowing the architecture of openSUSE it’s anyone guess as to what might be needed.

Even if all the parts are present and correct, we do not yet know if 4.2.0 has any breaking changes, I suspect not, but we do not have any confirmed use with emoncms yet. If using PECL I would suggest rolling back to a known good version, I do not know if that is possible on openSUSE.

Also, what versions of PHP and Redis (server) are in play? There are reported issues with using emoncms with PHP 7.3. Most of us (I believe) are running PHP 7.0 and some running PHP 7.2 (PHP 7.1 was not widely released). As for Redis (server) I think 3.2.6 is the common “latest” (this is different to the redis extension version number).

For now, I’d say probably stick with the openSUSE version and check the test script above, the redis-server service status and the various versions (perhaps post the server info from the admin page here).

Since openSUSE seems to have systemctl, you might also be able to enable “$allow_emonpi_admin” (or something to that effect) in settings.php, that should also show the redis-server status as well as the various version numbers, I have it enabled on a hosted Debian 9.0 VM without any issues.

1 Like

(Dave Howorth) #28

The openSUSE package is Phpredis according to its README.

$ php test_redis2.php 
Successfully connected to Redis!

So that works, just like my test_redis.php did and redis-cli PING did. So we’ve established that redis works and phpredis works.

$ sudo redis-server -v
[sudo] password for root: 
Redis server v=4.0.10 sha=00000000:0 malloc=jemalloc-4.0.3 bits=64 build=74b227d9afd46dcb

The build of php7-redis is 4.0.1. The package includes the following files:

php7-redis - API for communicating with Redis servers


7 files total

and PHP:

$ php --version
PHP 7.2.5 (cli) ( NTS )

Emoncms doesn’t start - that’s what this whole thread is all about. So I’ve no idea what would be on its admin page.

$ systemctl status redis-server
Unit redis-server.service could not be found.

$ systemctl status [email protected]
[email protected] - Redis
Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/[email protected]
Active: active (running) since Mon 2019-03-04 20:02:01 GMT; 1 day 17h ago
Main PID: 14244 (redis-server)
Tasks: 4 (limit: 4915)
CGroup: /system.slice/system-redis.slice/[email protected]
└─14244 /usr/sbin/redis-server

As I’ve said and demonstrated before, the service is [email protected] Does emoncms assume it is called redis-server somewhere and need a config changing? Actually change that - I see emoncms uses redis-server heavily throughout with the text scattered throughout. Not terribly good practice IMHO, but the question becomes, how do I bring up a redis service with that name? I’ll look after lunch.

I also see some scripts are still using /etc/init.d/… style commands. I don’t know whether that’s going to work. openSUSE is pretty heavily committed to systemd. There’s not much in that directory, so /etc/init.d/redis-server restart is never going to work, for example.


(Brian Orpin) #29

Try just

systemctl status | grep redis

and see if a redis service is listed.


Well it uses it, but does not create more than one instance as explained by @TrystanLea when I asked a similar question.


What are the contents of the test file?


(Dave Howorth) #30

We seem to be at cross purposes. I just showed you the systemctl status of the redis service that is running: [email protected] There are no others.

Sorry, I didn’t understand the stuff in the link. My point was that using the particular name of a service, or anything, literally in many places in code is poor practice. It’s better to assign the name of the service to a variable (or constant) and use the variable throughout the code. That way it’s easy to change the name of the service, or whatever, if desired. Multiple occurrences of the same literal string generally ring alarm bells.

As @pb66 suggested. The 2 is simply because I already had written a different test_redis.php


(Dave Howorth) #31

i.e. redis-server instead of [email protected] I don’t see anything in the config file about the name of the service so I assume it’s simply the name of the file that is used. But in that case, all service names would include an ‘@’ so I must be missing something.


(Brian Orpin) #32

And my point is, it doesn’t. You are fundamentally misunderstanding the use of the $redis global object which is declared once in the main code. Also the declaration knows nothing about the underlying service. the fact the test script works proves that.

I think we are actually barking up the wrong tree. The error you are seeing is in the process-settings.php file.

That line of code does exactly what your test script does i.e. check for class-exists so, why it is failing is beyond me. It could be to do with namespaces (though AFAIK they are not used in emoncms). You need someone with a greater knowledge of PHP than myself.


(Brian Orpin) #33

Can you drop the test file into the emoncms folder and then navigate to it as http://localhost/emoncms/test2.php or if you get a permission issue into the root www folder.

I have a theory.


(Dave Howorth) #34

produces a blank page.


produces ‘no redis’.

/var/log/apache2/error_log has

[Wed Mar 06 20:18:28.584989 2019] [php7:error] [pid 1858] [client] PHP Fatal error: Uncaught Error: Class ‘Redis’ not found in /srv/www/htdocs/emoncms/test_redis2.php:10\nStack trace:\n#0 {main}\n thrown in /srv/www/htdocs/emoncms/test_redis2.php on line 10

line 10 is ‘$redis = new Redis();

What’s your theory?


(Dave Howorth) #35

I don’t understand this statment. I take it to be an abbreviation for ‘something1 doesn’t something2’, which in turn I take to be an assertion that I claimed ‘something1 does something2’ and you think I was wrong. But I don’t see anywhere I made such a claim in my text that you quoted, so I’m at a loss to understand what you mean.

I haven’t been considering $redis at all. I’ve no idea what it is. To understand the point I was trying to make type this:

$ grep -r redis-server /var/www/html/emoncms

and then explain to me how it is all going to work if the service is called [email protected] rather than redis-server?

BTW, apparently the @default part is the name of the instance, so you can run multiple redis instances. I don’t know how raspbian/ubuntu/debian handle that.

[edit]: BTW I agree with you that the immediate problem we’ve been investigating is something different, and now seems to be something to do with PHP environments in wwwrun’s environment.