Version 1.00 worked efficiently on CPU cycles, but version 1.01 causes the CPU to run at 100%. This causes the CPU governor to run the CPU at its fastest speed rather than in a powersaved state.
Logged In: YES
- debian lenny (pretty clean installation)
- ibm thinkpad t41 with cpufreq (in case this matters)
This problem is resolved in SVN. It is a result of an impossible situation presented by the API, and I suspect it deserves the name "kernel bug" - A master PTY that has no open slaves will have select return with "pty is ready for read", despite the fact that an attempt to read from it will result in IO error, and the fact that it has an IO error now does not mean it will have an IO error later (client can open the slave end again through opening /dev/tty). The fact that select will not sleep means that sshpass was doing a busy loop.
The fix is to leave the file descriptor for the slave end open, thus effectively leaking it.
In the future, please report errors through the mailing list, as the bug tracker is not as vigilantly monitored.
Also, pro-to-co-ls, reporting this bug through the Debian bug tracking system (aptitude install reportbug) would have allowed the Debian team to know about it, and alert me quicker too.
Thanks, both of you, for the report,