Again, I prefer to run the stable distro versions of things to avoid random breakages.
I just wrote a little PHP script:
<?php
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?
The pecl packages are stable! I’ve offered the best solution to your problem but YMMV.
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.
Thanks guys for looking. I’m stopping for the night now, so will look again in the morning with a clearer head.
It seems Predis and Phpredis are the only 2 Redis clients for PHP “recommended by Redis” (yellow stars Redis), 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 redis@default
sudo systemctl status redis-server
@pb66, is there a simple way to test if the extension is installed correctly?
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.
<?php
$redis = new Redis();
$redis->connect('127.0.0.1', 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
pb66@test2:~$ 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.
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
/etc/php7/conf.d/redis.ini
/usr/lib64/php7/extensions/redis.so
/usr/share/doc/packages/php7-redis
/usr/share/doc/packages/php7-redis/CREDITS
/usr/share/doc/packages/php7-redis/README.markdown
/usr/share/licenses/php7-redis
/usr/share/licenses/php7-redis/COPYING
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 redis@default
● [email protected] - Redis
Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/[email protected]
└─limits.conf
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 127.0.0.1:6379
As I’ve said and demonstrated before, the service is redis@default. 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.
Try just
systemctl status | grep redis
and see if a redis service is listed.
[edit]
Well it uses it, but does not create more than one instance as explained by @TrystanLea when I asked a similar question.
[edit2]
What are the contents of the test file?
We seem to be at cross purposes. I just showed you the systemctl status of the redis service that is running: redis@default 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
i.e. redis-server instead of redis@default. 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.
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.
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.
http://localhost/emoncms/test_redis2.php
produces a blank page.
http://localhost/emoncms/test_redis.php
produces ‘no redis’.
/var/log/apache2/error_log has
[Wed Mar 06 20:18:28.584989 2019] [php7:error] [pid 1858] [client 127.0.0.1:39872] 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?
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 redis@default 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.
That was what I suspected. Is there a phpinfo file in the root you can check? I’m sure it will not list the REDIS extension.
The extension is not installed appropriately, but I have no idea how to fix that. I’d try a question on stackoverflow.com.
I did find this when searching. Useful info but does not answer the question.
Almost all* of the hits that come up are either readme files, comments, or “print” statements indicating where a possible error is. None of those should have any impact on anything (to @borpin’s point).
requires the actual name of the redis service and some EmonPi specific system files.I believe there is, but it is protected by the .htaccess so it can only be accessed by localhost does this machine have a browser? Otherwise use wget or curl to get the text.
Alternatively use php -m to list all loaded modules.
The redis-server service is just that, a service that starts Redis. Redis is still Redis once it is running. When running, Redis listens on a dedicated port for Redis commands, much like mysql listens for SQL syntax. When you use php-redis from emoncms, it communicates with the Redis server via Redis syntax via that port, not via the service unit, that could be called anything.
My questions about the service name was to try and establish if it was the right Redis, the fact the service name was different might have been significant. Certainly if there was also a redis-server service and that wasn’t running that certainly would have been significant.
Other than cause unhelpful confusion, I believe there is no harm in the name being different. The main thing is ensuring there is a Redis server installed, not a Redis client. In Debian, it is normal for xxx-server and xxx-client packages (and services) to be named as such to know which it is and thus avoid discussion such as this.
I have assumed this far that there is a Redis server installed (regardless of package name), I do not know if the Ping Pong test is conclusive, but i believe the words “redis-server” did appear in the redis@default service status output (sorry, typing on mobile keypad so browsing back whilst typing isn’t easy).
The only place the naming may be an issue in emoncms is in the admin page info reports, as that does report the status of the “redis-server” by name, but that’s just a small part that will not prevent emoncms working.
I have just looked up the Redis package on openSUSE and that is apparently version 4.0.11(openSUSE Software) We are still using 3.2.6 (Debian -- Details of package redis-server in stretch). Again no idea if that’s significant, is there any way to rollback in openSUSE, I presume not. Are you using a cutting edge version of openSUSE? The versions are more in line with Debian Buster, the next and as yet unreleased version of Debian.
There is and it didn’t show redis anywhere, which left me puzzled for a minute but then I figured it out:
$ systemctl reload apache2
and now it all works 
Or at least it starts. It gives me a login screen and after I complete the form it says:
404 Not Found: Is modrewrite
configured on your system?
To which the answer is yes, and its listed in the web-based phpinfo.