Comment 7 for bug 1676565

We've now seen this issue affect both 4.8 and 4.10 series as well.

My working theory at the moment is that changes to the kernel code from 3.13 -> 4.x introduced a memory leak that's eventually overflowing.

Based on the failures we're seeing in the field, there seems to be no reliable predictor of when sysfs goes unresponsive, but the rate of occurrence is higher on machines with higher numbers of apache2 hats.

I set up a test machine with 15 hats that compiled to an ~820K cache file:

  File: '/etc/apparmor.d/cache/usr.sbin.apache2'
  Size: 819297 Blocks: 1608 IO Block: 4096 regular file

and ran apparmor_parser -rB in a loop. so far, after a dozen passes at this, the magic number at which the kernel becomes unstable is around 3 gigabytes.

Running the same test against 3.13 now, will report results