[Apparmor-general] apparmor-parser gone wild?!

[John Johansen]

Christian Boltz wrote:
> Hello,
> 
> top shows the following output on a quite new server with openSUSE 11.0 
> after running aa-logprof:
> 
> top - 20:27:06 up  8:09,  4 users,  load average: 1.99, 1.52, 0.73
> Tasks: 115 total,   3 running, 112 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.0%us, 50.1%sy,  0.0%ni, 49.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   6097424k total,  1587960k used,  4509464k free,    38372k buffers
> Swap:  2104460k total,        0k used,  2104460k free,   469516k cached
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 13000 root      20   0  861m 855m  924 R  100 14.4   6:59.00 /sbin/apparmor_parser -I/etc/apparmor.d -r
>     1 root      20   0   864  328  272 S    0  0.0   0:00.44 init [3]
>     2 root      15  -5     0    0    0 S    0  0.0   0:00.00 [kthreadd]
> .....
> 
> As you can see, apparmor_parser takes 100% of the cpu and 14.4% of the 
> available memory (the server has 6 GB RAM!).
uhm, yeah this is a little ugly, there is a "bug" in the dfa generation
that causes some policies to consume unbelievable amounts of ram and
cpu.  It is a problem that I am actively working on now.  While I think
this is the problem with your current policy I can't be sure without
you sending me your profiles.

> 
> To make it even worse, it doesn't response to kill, not even kill -9 :-(
> Since init 6 also doesn't do anything, I had to reboot the server the
> hard way.
> 
ugh, this should not be the case.  The parser doesn't do anything that
should cause it to be unkillable.  Can you reliably reproduce

> Is this a known problem? How can I avoid it?
> 
The excessive computation and memory consumption is likely a known
problem, that it is unkillable is not and should not occur, so it is
important to see if we can reliably replicate.

> I can provide my profiles off-list (at least the httpd2-prefork profile
> contains customer names, so I don't want to send them on the list).
> 
yes, please send them to me and I will do some testing against your
policy.  This should also enable me to make some recommendation about
what you can do until I get this nasty bug fixed.

regards
john