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/etermat the link in the right :
eterm_0.9.6.orig.tar.gzMy 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