#1094321 valkey-server: Valkey with RediSearch module loaded pins core to 100% after GC failure

Package:
valkey-server
Source:
valkey-server
Description:
Persistent key-value database with network interface
Submitter:
kat
Date:
2025-01-27 06:54:02 UTC
Severity:
normal
#1094321#5
Date:
2025-01-27 06:51:33 UTC
From:
To:
Dear Maintainer,

When using the Debian distribution of valkey-server with the RediSearch module compiled from sources,
RediSearch will fail to garbage collect via a fork due to restrictions imposed by the shipped systemd unit.
This failure results in the RediSearch-forked child pinning a core to 100% usage.

Reproduction steps:
 - Install valkey-server and load the upstream RediSearch module from a stable tag of RediSearch.
 - Create a RediSearch index (via FT.CREATE)
 - Cause a manual garbage collection to happen via the following valkey commands inside of valkey-cli:
   - `FT.CONFIG SET FORK_GC_CLEAN_THRESHOLD 0` # set the threshold to 0 for repro purposes
   - `_FT.DEBUG GC_FORCEINVOKE` # invoke the gc

 The above steps should cause an output in the Valkey logs such as "* Module fork exited pid: 0000, retcode: -1, bysignal: 31"

This problem seems to stem from the `SystemCallFilter=~ @privileged @resources` line in the generated systemd unit, as RediSearch
expects that the `setpriority` syscall (included in the `@resources` group isn't restricted.
 -> Likely cause of hang in RediSearch: https://github.com/RediSearch/RediSearch/blob/eb14b957216bfdb02ae13fce3561e444992dd906/src/fork_gc.c#L1306

Removing that line from the unit file seems to fix the issue.