This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: system lags and dysfunctional after cygwin update

On May 13, 2016, at 8:02 AM, Ben Altman <> wrote:
> Doing a ksh --version gives me:  version         sh (AT&T Research) 93u+ 2012-08-01
> I haven't upgraded yet

ksh93u+ is the latest stable version.  Everything after that are beta versions which have been in beta for many years, which may be a hint that theyâre not quite ready for prime time.

> I was compiling under 32-bit Cygwin and if successful would try it on the 64-bit version.

Cygwin 32 and Cygwin 64 are somewhat incompatible.  They share a filesystem and can run each othersâ programs, but a whole bunch of other stuff will not work correctly between them.  If you must have both installed, treat them as wholly independent worlds, except possibly in terms of sharing files.

And not necessarily even then, since files produced from 32-bit Cygwin may not be compatible with a consumer linked against 64-bit Cygwin, nor vice versa.  The most obvious case is compiler object files, but there are other cases.

Itâs best if you install only one or the other, not both.

That option isnât always available.  Those of us maintaining packages typically need both installed, for example.

> The current version I am using will not work with 64-bit Cygwin.

We canât help you if you wonât provide details.

I infer from your prior posts that you are a programmer.  How do you like âdoes not workâ when you get it in a bug report?

Give us the sort of bug report you wish youâd receive from your users.

> I am not sure what is involved in packaging ksh with Cygwin

> I was under the impression that if the licensing wasn't GNU it would be a problem even though it is open source.

Not exactly.  The license merely has to be *compatible* with the GPL as far as binary distribution goes, since the binaries distributed in the Cygwin package repo are linked to cygwin1.dll, which is GPLâd.

But after taking a peek at the AST license, itâs pretty clear itâs incompatible with the GPL.

So, new advice: switch to mksh. :)

> I renamed my cygwin directory...a complete reinstall...this did not fix the problem.

So that would exonerate Cygwin, then, unless your contention is that a fresh installation somehow causes problems on only your machine, and not on all the others Cygwin is installed on every day.

No.  The problem must be in the environment external to Cygwin.

> typing a simple command like "ls" will take upwards of 20 seconds and all the other side effects. I'll see about doing the strace with the script though I will probably have to do it next week though.

You can do the strace test with ls.  Simpler tests are better.

> My script runs VPNClient

Ah hah!

Many VPNs areâstringent in that they try to force *everything* through the VPN.  So, if Cygwin is trying to do AD lookups to map NTFS ACLs to human readable names in ls, and there is no AD server on the other end of the VPN that can answer those questions, you could very easily get that sort of symptom.

Solution: test with and without the VPN.

For instance, reboot cleanly, bring up the VPN, then say âls -lâ.  If that gives the same symptom, you know itâs something like I described above.

It is possible the new AD-aware permission handling in Cygwin 1.7.34 is causing a problem for you.  If you canât fix the VPN or the AD setup, you could adjust the /etc/nsswitch.conf file as described here to revert to the old /etc/passwd based permission handling:

In effect, /etc/passwd and /etc/group act as static AD caches that can work while the AD server is unavailable.
Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]