python - 重启redis需要很长时间

Question

我在我的 django 项目中使用 redis 作为 celery 的代理。作为我的部署过程的一部分，我在最后重新启动服务，所以从 redis 开始的 redis、celery、gunicorn (django) 等。但是我遇到了 redis 不会关闭的问题。

$ sudo systemctl restart redis
$ 

在撰写本文时，它卡在那里 15 分钟。 journalctl 显示没有条目(我假设日志已经在一夜之间轮换)，systemctl status 显示 redis 单元正在停用(sig-term)但没有指示它在做什么，除了:

May 24 10:31:22 staging systemd[1]: Stopping Advanced key-value store...
May 24 10:31:22 staging run-parts[305]: run-parts: executing /etc/redis/redis-server.pre-down.d/00_example

我知道 sig-term 允许 redis 正常退出，所以想知道 celery beat 任务或 django 服务器是否正在访问它，但停止了这些服务后它仍然挂起。有什么我不知道的地方可以检查状态/它在做什么吗？

编辑:啊哈，好的，事实证明，默认情况下，redis 实际上并没有记录到 systemd，而是记录到 /var/log/redis，这实际上产生了一些信息:

31602:M 24 May 10:59:56.097 * 1 changes in 900 seconds. Saving...
31602:M 24 May 10:59:56.101 * Background saving started by pid 1151
1151:C 24 May 10:59:56.103 # Failed opening .rdb for saving: Read-only file system
31602:M 24 May 10:59:56.204 # Background saving error

我正在使用 dir 和 dbfilename 指令的默认值

# The filename where to dump the DB
dbfilename dump.rdb

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir /var/lib/redis

user@server:/var/lib/redis$ ls -l
total 252
-rw-r--r--  1 redis redis 249649 May 23 02:44 dump.rdb

归redis所有..为什么要设置为只读？

好的...所以

user@server:/var/lib/redis$ redis-cli config get dir
1) "dir"
2) "/var/spool/cron"
user@server:/var/lib/redis$ redis-cli config get dbfilename
1) "dbfilename"
2) "root"

这开始看起来很奇怪。到底是什么东西可以设置成这样？

Answer 1

它开始看起来越来越像是攻击的结果:https://github.com/antirez/redis/issues/3594

有趣的是，我在防火墙后面运行 redis。目前不确定配置是如何更改的。幸运的是，它是一个暂存服务器，上面没有任何敏感信息，所以我可以将其取下，直到我弄清楚到底是什么问题。

更新:所以在进一步调查之后，我所能确定的是，攻击一定是在服务器上安装了 redis 之后，但在防火墙被激活之前的某个时间点发生的。我使用的 redis 版本默认绑定(bind)到 0.0.0.0。我使用了一个部署脚本来设置服务器，所以漏洞时间一定是大约 10 秒。吸取教训，在安装软件包之前激活防火墙。

我会说我不喜欢默认情况下将 redis 绑定(bind)到 0.0.0.0，尤其是当它暴露在外可能会完全破坏您的服务器时。但根据我所读到的内容，争论已经结束，并且在后来的版本中有所改进。