km4hr wrote:
Phil Betts-2 wrote:
km4hr wrote:
Perhaps you missed my suggestions here:
http://cygwin.com/ml/cygwin-xfree/2009-02/msg00222.html
Try the telnet check first to see if the port is accessible from
Windows
because that only takes a few seconds. (Make sure you run the cygwin
telnet.exe)
Phil,
Thanks for hanging in there.
I tried your telnet suggestion. I get the following:
$telnet xxx.xxx.xxx.xxx 6000
trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
The above is all I get. A login prompt never appears. I waited for
several minutes.
When I press Ctrl-c I get:
"Connection closed by foreign host.
If I telnet using an unopen port I the response gets past the
"trying"
statement.
Your quoting went a bit wrong there.
Sorry, I should have explained that that was the expected outcome. If
you get the "Connected to" message, the port is open and you can close
the connection. The proper way to terminated a telnet session from that
situation is to press Ctrl-] (the "Escape character" mentioned in the
message). You then get a telnet prompt, where you just type quit.
You wouldn't normally expect a prompt (unless the port was 23 - telnet's
own). In theory, if you knew enough about the protocol expected on the
opened port, you could simulate a normal connection and debug the
connection using telnet, but you have to have a certain masochistic
streak to try it!
So, now we know that the port is accessible from Windows. In that case,
it *should* work, so something else is interfering.
Have you investigated the BLODA angle? Prime suspects are anti-virus
and
other "security" software, but hardware drivers have caused problems
too.
These programs inject themselves into every running process at a fairly
low level and, whilst they are mostly benign, can cause nasty, spurious
problems, particularly when the code you are trying to run is slightly
off the beaten track. X and XCMCP probably falls into that category for
Windows machines.
The usual advice is to uninstall these, rather than just disable them.
The faulty components are frequently left in place when "disabled".
Once
you have ruled out a candidate, you can reinstall it. If you do find
one
that is causing the problem, it may be possible to configure it in a way
which avoids the problem (e.g. disabling real-time virus scanning).
You can often spot BLODA by running the program which is failing, and
then seeing which DLLs are loaded using something like Process Explorer.
Any unexpected DLLs, particularly if not under C:\Windows or C:\cygwin
are prime suspects. In your case, because the -query option is failing,
you won't get chance to see the DLLs before X terminates, so you could
just start a normal server (e.g. via startxwin.bat) instead.
You may find that an app that is not on the BLODA is causing the
problem.
If so, a message to the main cygwin list would be appreciated so that
the
BLODA can be updated.
If the BLODA hunt fails, you could try running the server via strace so
that the point of failure might be spotted, but I'm not familiar with
the
source. Yaakov or Jon would probably be better at making sense of that.
Phil
--
This email has been scanned by Ascribe PLC using Microsoft Antigen for
Exchange.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/