The interesting detail is it would always stop at exactly 64 sockets
open; which is the maximum number for which select() doesn't have to
spawn a second thread.
Problem disappeared. Given the traces I got the reproduction would
involve somebody's deranged trojan SSH scanner.
64 to too low for Fai
IP address. Only private key
authentication allowed.)
On 4/1/14, Joshua Hudson wrote:
> Hi. I'm getting a situation on one machine where sshd will fail to
> accept connections in a way that says "connection refused" even though
> it is listening. The server shows a large (58)
Hi. I'm getting a situation on one machine where sshd will fail to
accept connections in a way that says "connection refused" even though
it is listening. The server shows a large (58) number of connections
in CLOSE_WAIT.
A Google search leads me to
http://www.cygwin.com/ml/cygwin/2010-01/msg01235
We had a weird incident involving ctime changing unexpectedly when
mtime did not.
On a normal UNIX system, we'd immediately say somebody changed the
file and set mtime back, but on Cygwin, ctime appears to be synthetic.
How exactly does ctime work on Cygwin? I can't find any useful
documentation
/bin/rebaseall worked. Great, thanks man!
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Whenever cygwin hasn't been running for awhile, launching it yields a
lot of STATUS_ACCESS_VIOLATION in bash.exe
$ cat bash.exe.stackdump
13779031 [main] bash 4212 exception::handle: Exception: STATUS_ACCESS_VIOLATION
13779775 [main] bash 4212 open_stackdumpfile: Dumping stack trace to bash.exe.st
1. no _CS_PATH
2. no sys_siglist
3. no confstr
4. no memopen
_CS_PATH and confstr looks easy enough to give it the values it wants.
Removed code that handles sys_siglist
Not sure what to do about memopen
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: ht
7 matches
Mail list logo
