It seems that Valkey 8.1.4 breaks rubygem-redis-client. It seems the test suite timeouts for some reasons: ~~~ ... snip ... + ruby -Ilib:test -e $'\n Dir["./test/**/*_test.rb"]\n .reject{|i| i.start_with?("./test/sentinel/")}\n .each &method(:require)\n' starting redis... started with pid=1355 Waiting for redis (port 16380)... timedout. Running test suite with driver: RedisClient::RubyConnection ... snip ~~~ Reproducible: Always
Is this a TLS test? Starting with Fedora 43 and valley 8.1, optional features are split into sub-packages, so valkey-rdma and valkey-tls So you probably need to BuildRequires: valkey-tls Notice: if the test suite use a dedicated configuration, it needs to load the optional module: loadmodule /usr/lib64/valkey/modules/tls.so
(In reply to Remi Collet from comment #1) > Is this a TLS test? This is likely the relevant code starting the server: https://github.com/redis-rb/redis-client/blob/v0.22.2/test/support/servers.rb#L48-L62 There are multiple `tls` options, so I guess the answer is positive. > Starting with Fedora 43 and valley 8.1, optional features are split into > sub-packages, so valkey-rdma and valkey-tls > > So you probably need to BuildRequires: valkey-tls Will try that 👍 A bit surprising, but I see this is likely just buildroot behavior due to `Supplements`.
> So you probably need to BuildRequires: valkey-tls This won't help on itself. It seems I'll need to dig deeper :(
The log confirms issues with TLS: ~~~ 414:M 16 Oct 2025 10:17:15.127 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. 414:M 16 Oct 2025 10:17:15.127 * oO0OoO0OoO0Oo Valkey is starting oO0OoO0OoO0Oo 414:M 16 Oct 2025 10:17:15.127 * Valkey version=8.1.4, bits=64, commit=00000000, modified=0, pid=414, just started 414:M 16 Oct 2025 10:17:15.127 * Configuration loaded 414:M 16 Oct 2025 10:17:15.128 * Increased maximum number of open files to 10032 (it was originally set to 1024). 414:M 16 Oct 2025 10:17:15.128 * monotonic clock: POSIX clock_gettime 414:M 16 Oct 2025 10:17:15.128 * Running mode=standalone, port=16380. 414:M 16 Oct 2025 10:17:15.128 # Missing implement of connection type tls 414:M 16 Oct 2025 10:17:15.128 # Failed finding TLS support. ~~~ So I guess I should figure out how to load the module.
Ok, this helps: ~~~ diff --git a/test/support/servers.rb b/test/support/servers.rb index b810d89..fb4bef8 100644 --- a/test/support/servers.rb +++ b/test/support/servers.rb @@ -58,6 +58,7 @@ module Servers "--save", "", "--appendonly", "no", "--dir", "tmp/", + "--loadmodule", "/usr/lib64/valkey/modules/tls.so" ] end ~~~ However, I can't help myself, but this feels weird. Why there should be specified some module path?
This is short reproducer: ~~~ $ redis-server --tls-port 16380 | cat 848:M 16 Oct 2025 10:43:25.745 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. 848:M 16 Oct 2025 10:43:25.745 * oO0OoO0OoO0Oo Valkey is starting oO0OoO0OoO0Oo 848:M 16 Oct 2025 10:43:25.745 * Valkey version=8.1.4, bits=64, commit=00000000, modified=0, pid=848, just started 848:M 16 Oct 2025 10:43:25.745 * Configuration loaded 848:M 16 Oct 2025 10:43:25.745 * Increased maximum number of open files to 10032 (it was originally set to 1024). 848:M 16 Oct 2025 10:43:25.745 * monotonic clock: POSIX clock_gettime 848:M 16 Oct 2025 10:43:25.746 * Running mode=standalone, port=6379. 848:M 16 Oct 2025 10:43:25.746 # Missing implement of connection type tls 848:M 16 Oct 2025 10:43:25.746 # Failed finding TLS support. ~~~ There is no custom config used and I believe for such case, the module should be loaded automatically when the `--tls-port 16380` is specified.
Sorry for the inconvenience, but modules are designed for flexibility of optional features Other stacks works the same (module in sub-package with configuration file to load so installed = enabled), ex httpd + mod_*, php + ext We was used to see redis/valkey as a monolithic server. More modules are coming (bloom, json, ldap, rdma, search, tls...) so we need a flexible way to manage them. > the module should be loaded automatically when the `--tls-port 16380` is specified. This is not handled in the code, so some change needed upstream.
(In reply to Remi Collet from comment #7) > Sorry for the inconvenience, but modules are designed for flexibility of > optional features > > Other stacks works the same (module in sub-package with configuration file > to load so installed = enabled), ex httpd + mod_*, php + ext > > We was used to see redis/valkey as a monolithic server. > > More modules are coming (bloom, json, ldap, rdma, search, tls...) so we need > a flexible way to manage them. No worries. I just wish more people were using mass-prebuild, so such changes are caught prior they cause breakage. > > the module should be loaded automatically when the `--tls-port 16380` is specified. > > This is not handled in the code, so some change needed upstream. If I understand correctly, this is a bit experimental WIP. I'm considering to wait for fix which would improve this.
Changes have been reverted in F43+ F43: https://bodhi.fedoraproject.org/updates/FEDORA-2025-9663174730 Rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2025-4cb8b4ec97 Modules are kept (rdma), but TLS is now build statically (as in previous versions) Mostly because not supported in sentinel