On Tue, 15 Oct 2019 at 15:30, Matt Johnston <m...@ucc.asn.au> wrote: > I think regardless of what Dropbear's doing with pipes (closed sessions etc), > there is probably something wrong with the Linux kernel. > As far as I know userspace can't trigger D state even intentionally (I'd be > interested if anyone knows a way though). > -K is unrelated, that just sends some SSH traffic at a certain interval.
Apologies for dropping in on an old thread, not sure if this is still a problem, but I came across something similar with some of my own code and remembered this thread so figured I'd add the result of what I found there in case it was helpful (probably not, but you never know...) Linux puts vfork()'s parents into the D state until the child returns: as a result if you vfork() and then fail to exec() (or more likely if the exec() call fails) without _exit() in the child Linux will leave the parent in D state permanently until the child quits. Is DROPBEAR_VFORK enabled on the example build for some reason? It shouldn't be - as far as I can tell HAVE_FORK should always be true on Linux, but I guess it could be incorrectly configured somehow. Test code: #include <unistd.h> #include <stdio.h> int main (int argc, char **argv) { char buff[1024]; if (vfork()==0) { // child process sprintf(buff, "ps auxww | grep %s", argv[0]); system(buff); // shows D process execl("/bin/invalidbinary", "invalidbinary", NULL); // note no _exit() call } // if you do stuff here, the child will take over, while the parent is stuck in D } Now it's not immediately obvious how this would happen in the dropbear code, although I might be missing something obvious, but it's one very easy way to get a D state process on Linux. Geoff