I don't have much experience with PHP, so apologies in advance for possible inaccuracies.
I operate an instance of Nextcloud in Docker and after one of the upgrades my instance started blowing up with segmentation faults.
After digging into it, my best guess is that it's caused by authenticating with Redis using false, like someone tried with null in #1808.
It's happening because configuration provided by nextcloud/docker feeds the result from PHP's getenv (which returns false if the specified env var does not exist) straight into configuration for Redis. (Discussion in #1808 makes a good point: null as a password is already odd, false even more so. In that light, PHP's built-in getenv's behavior can be seen as odd, I guess.)
Notably, my initial investigation pointed at an upgrade of phpredis to 6.0.0, versions with phpredis 5.3.7 worked fine. It's nothing more than correlation at this point though and image maintainers don't feel comfortable downgrading the library (which is understandable).
More details here: nextcloud/docker#2106
Nextcloud itself is expected to ship with a fix that prevents it from even trying false as Redis password.
Expected behaviour
An informative error message or normal operation without authentication
Actual behaviour
Segmentation fault
I'm seeing this behaviour on
- OS: Linux 5.10
- Redis: 7.2.3
- PHP: 8.2.13
- phpredis: 6.0.2
(numerous other configurations too, including with Redis 5.x; but since those were baked into the image which I used as-is, I don't have any specifics recorded)
Steps to reproduce, backtrace or example script
- Perform a clean install of Nextcloud 27.1.4 using the official Docker images (this will likely work with any variation, fpm or apache, Alpine or Debian, but the test setups used
-fpm-alpine and -fpm); make sure to configure it with Redis and without setting any password for it
- Modify the file visible inside the container as
/var/www/html/config/redis.config.php like so:
- 'password' => (string) getenv('REDIS_HOST_PASSWORD'),
+ 'password' => getenv('REDIS_HOST_PASSWORD'),
(Remove (string) basically)
- Restart the container for the changes to take effect
- Visit this installation of Nextcloud — it no longer works
(Can provide Compose files if needed, but I'll have to go look for them; plus, I'm not certain a full setup would be needed to test the hypothesis)
I've checked
I don't have much experience with PHP, so apologies in advance for possible inaccuracies.
I operate an instance of Nextcloud in Docker and after one of the upgrades my instance started blowing up with segmentation faults.
After digging into it, my best guess is that it's caused by authenticating with Redis using
false, like someone tried withnullin #1808.It's happening because configuration provided by nextcloud/docker feeds the result from PHP's
getenv(which returnsfalseif the specified env var does not exist) straight into configuration for Redis. (Discussion in #1808 makes a good point:nullas a password is already odd,falseeven more so. In that light, PHP's built-ingetenv's behavior can be seen as odd, I guess.)Notably, my initial investigation pointed at an upgrade of phpredis to 6.0.0, versions with phpredis 5.3.7 worked fine. It's nothing more than correlation at this point though and image maintainers don't feel comfortable downgrading the library (which is understandable).
More details here: nextcloud/docker#2106
Nextcloud itself is expected to ship with a fix that prevents it from even trying
falseas Redis password.Expected behaviour
An informative error message or normal operation without authentication
Actual behaviour
Segmentation fault
I'm seeing this behaviour on
(numerous other configurations too, including with Redis 5.x; but since those were baked into the image which I used as-is, I don't have any specifics recorded)
Steps to reproduce, backtrace or example script
-fpm-alpineand-fpm); make sure to configure it with Redis and without setting any password for it/var/www/html/config/redis.config.phplike so:(string)basically)(Can provide Compose files if needed, but I'll have to go look for them; plus, I'm not certain a full setup would be needed to test the hypothesis)
I've checked
developbranch