下面是/proc/sys/kernel/random/entropy_availRaspberry Pi 上的值的图表。^{这个可能不正确}的答案 将其描述为：

/proc/sys/kernel/random/entropy_avail只是为您提供当前可以从中读取的位数/dev/random。尝试读取更多内容将阻塞，直到有更多熵可用。

图案总是以每分钟减少约 130 位的方式达到相同的“稳定”锯齿图案。如果熵增长过多，则某些东西正在“吃掉”它以返回 700-800 范围。如果我重新启动设备，熵仍会每分钟被吃掉，但会以更小的块形式被吃掉，从而使其再次增长到 700-800 范围。

我该如何解释这些图表？怎么了？

我的感觉是，如果只有一个使用随机数生成器的进程，entropy_avail一旦失去平衡（通过使用设备硬件）应该会无限增长或降低到 200 的水平，届时/dev/random将停止提供值。

此外，如果任何监测方法（见下面的检查）影响熵，它应该每秒减少熵，而不是让它每隔一分钟突然增长和下降。

^{（如果我让机器闲置，稳定的“锯”模式会持续几天，我在更短的时间内截取了截图）}

图表

• 机器长时间闲置：

  

• 在 19:14:45 左右，另一台机器apt-cacher在 Pi 上访问 - 熵增长（我猜是网络使用情况）。之后在 19:16:30 下降到“正常水平”比平时更大（它也是可重复的 - 如果entropy_avail增长太大，下降得更快）：

  

• 我重新启动机器，熵增长直到达到“通常”水平：

  

  

• 它再次进入空闲状态：

  

• 再次重启后，熵减少的时间点发生了变化，但它仍然每分钟发生一次：

  

检查

• 我停止netdata（监控程序）并使用watch -n1 cat /proc/sys/kernel/random/entropy_avail. 的值entropy_avail以固定的一分钟间隔增长到 ~800 并下降到 ~680。

• 根据建议“跟踪访问 /dev/random 和 /dev/urandom 的所有进程”我在 Debian VM 上检查过（来自类似问题inotifywait的答案的想法）并且无法访问任何一个或目前下降（当然检查手动记录事件）。/dev/random/dev/urandomentropy_avail

• 我使用entropy-watcher来检查熵，建议不要使用watch. 结果仍然与每分钟稳定增长和急剧下降一致：

  833 (-62)
  836 (+3)
  838 (+2)
  840 (+2)
  842 (+2)
  844 (+2)
  846 (+2)
  848 (+2)
  850 (+2)
  852 (+2)
  854 (+2)
  856 (+2)
  858 (+2)
  860 (+2)
  862 (+2)
  864 (+2)
  866 (+2)
  868 (+2)
  871 (+3)
  873 (+2)
  811 (-62)
  

Unix StackExchange 上的两个问题描述了相同的现象（稍后发现）：

• 是什么不断消耗熵？
• 什么程序正在降低我的熵池水平？