Hello, the crash log contains a very interesting detail - you killed aa-status while it worked on the profile /usr/bin/python2.7//null-5ec//null-5ed//null-5...5ef//null-667//null-668//null-574fe (the line was shortened when python created the crash log, there were probably more null-* nesting levels)
Those null-* profiles are used in complain mode to track exec events. In your case, there must have been *lots of* exec events, which leads to *lots of* those null-* profiles, nested as deep as the exec chain goes. Please provide the output of wc -l /sys/kernel/security/apparmor/profiles time aa-status # be patient, please ;-) I'm quite sure aa-status is _not_ in an endless loop - it's "just" busy with reading a very long list of profiles. That said - we are probably wasting CPU cycles if you only check for --enabled. That's not really noticable with 50 or 100 profiles loaded, but with > 1000 profiles (in your case mostly null-*) it might take some time. I opened https://bugs.launchpad.net/apparmor/+bug/1516400 for that. BTW: Do you really have a profile for /usr/bin/python2.7? That's probably a bad idea ;-) and I seriously recommend to delete and unload it (unless you have a _very good_ reason for what you are doing). The usual recommendation is to create a profile for the python scripts, and then have an ix (inherit) rule for the python interpreter. (This also means you have to run those scripts using "./myscript.py", not "python myscript.py".) Regards, Christian Boltz -- So we have unequivocal proof that I'm more dangerous to my own machine than any of the updates we've rolled out to Tumbleweed in the last 14 months. [Richard Brown in opensuse-factory]