It's probably a "bottom half", which is tightly bound to the CPU where the interrupt landed. And probably the memcg iteration uses a spin lock, which disables

It's probably a "bottom half", which is tightly bound to the CPU where the interrupt landed. And probably the memcg iteration uses a spin lock, which disables bottom half execution. On NT, this style of problem would be slightly less likely. The job object, which is NT's memcg equivalent, is a handle based object that naturally goes away when the owning process dies. I also bet systemd would have native mechanisms to clean this memcg state up if it was used for this purpose. Seems like a bug in the AWS ecs code.