This bug surfaced when starting ~50 LXC container with LXD in parallel multiple times:
# Create the containers for c in c foo{1..50}; do lxc launch images:ubuntu/xenial $c; done
# Exectute this loop multiple times until you observe errors. for c in c foo{1..50}; do lxc restart $c & done
After this you can
ps aux | grep apparmor
and you should see output similar to:
root 19774 0.0 0.0 12524 1116 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo30 root 19775 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo26 root 19776 0.0 0.0 13592 3224 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo30 root 19778 0.0 0.0 13592 3384 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo26 root 19780 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo43 root 19782 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo34 root 19783 0.0 0.0 13592 3388 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo43 root 19784 0.0 0.0 13592 3252 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo34 root 19794 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo25 root 19795 0.0 0.0 13592 3256 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo25
apparmor_parser remains stuck even after all LXC/LXD commands have exited.
dmesg output yields lines like:
[41902.815174] audit: type=1400 audit(1480191089.678:43): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lxd-foo30_</var/lib/lxd>" pid=12545 comm="apparmor_parser"
and cat /proc/12545/stack shows:
[<ffffffff8c9b9378>] aa_remove_profiles+0x88/0x270 21:19 brauner [<ffffffff8c9ac3e4>] profile_remove+0x144/0x2e0 21:19 brauner [<ffffffff8c8319b8>] __vfs_write+0x18/0x40 21:19 brauner [<ffffffff8c832108>] vfs_write+0xb8/0x1b0 21:19 brauner [<ffffffff8c833565>] SyS_write+0x55/0xc0 21:19 brauner [<ffffffff8ce952f6>] entry_SYSCALL_64_fastpath+0x1e/0xa8 21:19 brauner [<ffffffffffffffff>] 0xffffffffffffffff
This looks like a potential kernel bug.
This bug surfaced when starting ~50 LXC container with LXD in parallel multiple times:
# Create the containers ubuntu/ xenial $c; done
for c in c foo{1..50}; do lxc launch images:
# Exectute this loop multiple times until you observe errors.
for c in c foo{1..50}; do lxc restart $c & done
After this you can
ps aux | grep apparmor
and you should see output similar to:
root 19774 0.0 0.0 12524 1116 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/ lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo30 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo26 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo30 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo26 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo43 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo34 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo43 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo34 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo25 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo25
root 19775 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19776 0.0 0.0 13592 3224 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19778 0.0 0.0 13592 3384 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19780 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19782 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19783 0.0 0.0 13592 3388 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19784 0.0 0.0 13592 3252 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19794 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19795 0.0 0.0 13592 3256 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/
apparmor_parser remains stuck even after all LXC/LXD commands have exited.
dmesg output yields lines like:
[41902.815174] audit: type=1400 audit(148019108 9.678:43) : apparmor="STATUS" operation= "profile_ load" profile= "unconfined" name="lxd- foo30_< /var/lib/ lxd>" pid=12545 comm="apparmor_ parser"
and cat /proc/12545/stack shows:
This bug surfaced when starting ~50 LXC container with LXD in parallel multiple times:
# Create the containers ubuntu/ xenial $c; done
for c in c foo{1..50}; do lxc launch images:
# Exectute this loop multiple times until you observe errors.
for c in c foo{1..50}; do lxc restart $c & done
After this you can
ps aux | grep apparmor
and you should see output similar to:
root 19774 0.0 0.0 12524 1116 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/ lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo30 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo26 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo30 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo26 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo43 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo34 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo43 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo34 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo25 lxd/security/ apparmor/ cache /var/lib/ lxd/security/ apparmor/ profiles/ lxd-foo25
root 19775 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19776 0.0 0.0 13592 3224 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19778 0.0 0.0 13592 3384 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19780 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19782 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19783 0.0 0.0 13592 3388 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19784 0.0 0.0 13592 3252 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19794 0.0 0.0 12524 1208 pts/1 S+ 20:14 0:00 apparmor_parser -RWL /var/lib/
root 19795 0.0 0.0 13592 3256 pts/1 D+ 20:14 0:00 apparmor_parser -RWL /var/lib/
apparmor_parser remains stuck even after all LXC/LXD commands have exited.
dmesg output yields lines like:
[41902.815174] audit: type=1400 audit(148019108 9.678:43) : apparmor="STATUS" operation= "profile_ load" profile= "unconfined" name="lxd- foo30_< /var/lib/ lxd>" pid=12545 comm="apparmor_ parser"
and cat /proc/12545/stack shows:
[<ffffffff8c9b9 378>] aa_remove_ profiles+ 0x88/0x270 3e4>] profile_ remove+ 0x144/0x2e0 9b8>] __vfs_write+ 0x18/0x40 108>] vfs_write+ 0xb8/0x1b0 565>] SyS_write+0x55/0xc0 2f6>] entry_SYSCALL_ 64_fastpath+ 0x1e/0xa8 fff>] 0xffffffffffffffff
21:19 brauner [<ffffffff8c9ac
21:19 brauner [<ffffffff8c831
21:19 brauner [<ffffffff8c832
21:19 brauner [<ffffffff8c833
21:19 brauner [<ffffffff8ce95
21:19 brauner [<fffffffffffff
This looks like a potential kernel bug.