我有一个运行内核 3.13.0-74 和 32GB RAM 的 Ubuntu 14.04.3 机器，它的特点是一个 rsyslogd 进程变得疯狂：
$ ps -auxww | grep rsyslog
syslog 16212 0.7 64.0 27966168 21070336 ? Ssl Jan04 180:31 rsyslogd -c 5 -x
$ free -m
total used free shared buffers cached
Mem: 32142 31863 278 228 9 363
-/+ buffers/cache: 31490 651
Swap: 16383 11937 4446
我知道 ps 的输出不能完全依赖等，但肯定有点高！我还有两台具有相同软件/软件（同时运行）的兄弟机器，并且在这两个兄弟机器上，rsyslogd 的表现更好（每台机器仍然使用大约 3.5GB）。
这是 rsyslogd 7.4.4，我知道在较新版本中修复了内存泄漏。
我的问题：在我急于升级之前，如果可能的话，我想收集一些证据来证明我确实遇到了那个漏洞。我现在已经让 rsyslogd 运行了，但是用不了多久它就会搅动所有的交换，所以需要尽快采取行动......
我收集证据的一件事是atop。这清楚地显示了泄漏开始发生的时间（我不记得当时对盒子做了什么特别的事情）。有趣的是，在内存开始增长的同时，磁盘写入活动急剧下降——尽管它并没有完全停止。文件系统在容量方面很好。
$ atop -r atop_20160117 | grep …在我发现一些应该在我的用例中禁用它的指导后，我正在尝试调整 AppArmor 配置文件（不太高兴裸露地运行 IPSec 守护进程）。
因此，我尝试将其置于complain模式下，这解决了问题，但没有实际揭示原因是什么；我本来希望能aa-logprof在那里帮助我，但结果空空如也。
进一步挖掘，我发现了这个确凿无疑的证据/var/log/messages（在启用complain模式之前）：
type=1400 audit(1470858266.974:84): apparmor="DENIED" operation="capable" profile="/usr/lib/ipsec/charon" pid=27117 comm="charon" capability=1 capname="dac_override"
启用complain模式产生：
type=1400 audit(1470855949.106:69): apparmor="ALLOWED" operation="capable" profile="/usr/lib/ipsec/charon" pid=4674 comm="charon" capability=1 capname="dac_override"
所以它看起来像是capability dac_override缺少的东西（事实上，如果我手动将它添加到配置文件中，它就可以工作）。
但我很困惑为什么没有明确透露这一点complain。是否complain透明启用dac_override？
我对 AppArmor 还很陌生；我今天确实花了相当多的时间尝试解析文档，但找不到任何对此行为的引用......
（Ubuntu 14.04 上的 apparmor 2.8.95~2430-0ubuntu5.3，内核 3.13.0-92）