Describe the bug
restartServer() says it closes all file descriptors except stdin, stdout, and stderr before execve(), but its loop only checks descriptors below server.maxclients + 1024. An inherited descriptor above that bound, without FD_CLOEXEC, remains open in the restarted Redis process.
To reproduce
On Linux with a file-descriptor limit above 1500, build Redis and run this Python launcher from the repository root in one terminal:
import os
import subprocess
socket_path = "/tmp/redis-restart-fd-repro.sock"
try:
os.unlink(socket_path)
except FileNotFoundError:
pass
for target_fd in (900, 1500):
read_fd, write_fd = os.pipe()
os.dup2(read_fd, target_fd)
os.set_inheritable(target_fd, True)
os.close(read_fd)
os.close(write_fd)
server = subprocess.Popen(
["./src/redis-server", "--port", "0", "--unixsocket", socket_path,
"--maxclients", "100", "--enable-debug-command", "yes",
"--save", "", "--appendonly", "no"],
pass_fds=(900, 1500),
)
def show_fds():
for fd in (900, 1500):
try:
value = os.readlink(f"/proc/{server.pid}/fd/{fd}")
except FileNotFoundError:
value = "closed"
print(f"FD {fd}: {value}")
print(f"Redis PID: {server.pid}")
input("Press Enter once Redis is ready to inspect inherited FDs: ")
show_fds()
input("Run DEBUG RESTART 0 in another terminal, wait for PING, then press Enter: ")
show_fds()
In another terminal, run:
./src/redis-cli -s /tmp/redis-restart-fd-repro.sock PING
./src/redis-cli -s /tmp/redis-restart-fd-repro.sock DEBUG RESTART 0
./src/redis-cli -s /tmp/redis-restart-fd-repro.sock PING
With maxclients=100, the close loop covers [3, 1124). Before restart, both FDs refer to pipes. After restart, FD 900 is closed, while FD 1500 still refers to its original pipe. In our Redis 8.10.1 replay, the PID stayed the same and the server's run_id changed; the in-range pipe's peer write failed with EPIPE, while a write to the out-of-range pipe succeeded.
Expected behavior
Both inherited pipe descriptors should be closed before execve(), as described by the comment in restartServer(). Descriptors opened by the new Redis process after restart are unrelated to this report.
Additional information
The loop in src/server.c is:
for (j = 3; j < (int)server.maxclients + 1024; j++) {
if (fcntl(j,F_GETFD) != -1) close(j);
}
maxclients + 1024 is not an upper bound on descriptor numbers a process can inherit. The same loop is present in the current unstable branch. Could the restart path close all inherited descriptors without assuming this bound?
Describe the bug
restartServer()says it closes all file descriptors except stdin, stdout, and stderr beforeexecve(), but its loop only checks descriptors belowserver.maxclients + 1024. An inherited descriptor above that bound, withoutFD_CLOEXEC, remains open in the restarted Redis process.To reproduce
On Linux with a file-descriptor limit above 1500, build Redis and run this Python launcher from the repository root in one terminal:
In another terminal, run:
With
maxclients=100, the close loop covers[3, 1124). Before restart, both FDs refer to pipes. After restart, FD 900 is closed, while FD 1500 still refers to its original pipe. In our Redis 8.10.1 replay, the PID stayed the same and the server'srun_idchanged; the in-range pipe's peer write failed withEPIPE, while a write to the out-of-range pipe succeeded.Expected behavior
Both inherited pipe descriptors should be closed before
execve(), as described by the comment inrestartServer(). Descriptors opened by the new Redis process after restart are unrelated to this report.Additional information
The loop in
src/server.cis:maxclients + 1024is not an upper bound on descriptor numbers a process can inherit. The same loop is present in the currentunstablebranch. Could the restart path close all inherited descriptors without assuming this bound?