重启redis需要很长时间答案

【问题标题】：restarting redis taking long time重启redis需要很长时间
【发布时间】：2017-10-24 14:15:56
【问题描述】：

我在我的 django 项目中使用 redis 作为 celery 的代理。作为我部署过程的一部分，我在最后重新启动服务，所以 redis、celery、gunicorn (django) 等从 redis 开始。但是我遇到了 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"

这开始看起来很奇怪。到底是什么原因造成的？

【问题讨论】：

为什么你认为你重启了redis？
一个好点，现实是我可能不知道，这是我正在考虑改变的事情，现在主要是要找出问题所在
Redis 正在将缓存的全部内容写入磁盘。然后它必须从磁盘读取整个缓存。在慢速硬盘上可能真的很慢
@e4c5 是的，我想就是这样，它正在尝试将缓存写入磁盘但由于只读文件系统错误而失败

标签： python django redis celery

【解决方案1】：

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

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

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

我会说我不喜欢默认绑定到 0.0.0.0 的 redis，尤其是当它有能力完全破坏你的服务器时。但是根据我所读到的内容，该论点已被彻底完成，并且在以后的版本中情况有所改善。

【讨论】：