Hello, I think I might have found why Eterm is behaving like this and have also a solution.
>From the source tarball listed in the page: https://packages.debian.org/jessie/eterm at the link in the right : eterm_0.9.6.orig.tar.gz <http://http.debian.net/debian/pool/main/e/eterm/eterm_0.9.6.orig.tar.gz> My modification is to just change the line 1564 in src/command.c from unsigned short i; to unsigned long i; and recompile, it works for me. The problem was that, a few lines further 1564, eterm tries to close all the possible file descriptors from 0 up to 65536. But when using a short integer, there is an overflow, and when i is at the value 65535 the i++ instruction puts it at 0, so the loop is beginning again for over 65536 iterations and over and over and forever. That's why you could see its process consuming 100% of the CPU. Besides that, I'm surprised that the compiler does not warn about comparing a long int to a short int in a for loop !! Let me know if it works for you. regards -- *Arnaud Ceyrolle*
