On Mon, Oct 14, 2019 at 2:49 AM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > It's in running state, so it's not sleeping at the time you gathered > this. What you may want to do is strace the task and see what it's > doing. Is it doing syscalls and rapidly returning from them or just > spinning in userland? If it's doing syscalls, is it getting unexpected > errors that are causing it to loop? etc... > > I looked in /sys/kernel/debug/ceph/, but wasn't sure how to up the > > debugging that would be beneficial. My associate got that stack from running `trace-cmd`. I'm not sure of the details. I tried to strace the running container, but it won't let me attach, seems that you need to pass in a cap when starting the container or sideloading with connecting another container to the same namespace. This is a bit out of my area of expertise. I'll see if my associate can get a trace from it. > See here: > > https://docs.ceph.com/docs/master/cephfs/troubleshooting/#dynamic-debugging > > ...but I wouldn't turn that up yet, until you have a clearer idea of > what the task is doing. Thanks for the pointer, not at all what I was expecting. > > We don't have a crash kernel loaded, so that won't be an option in this case. > > > > Ok. It's a good thing to have if you ever need to track down kernel > crashes or hangs. You may want to consider enabling it in the future. We have a lot of things we are trying to get in place, this is one of them.
