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 5/12/2016 11:57 AM, Warren Young wrote:
On May 12, 2016, at 8:35 AM, Ben Altman <> wrote:
I have been using the same version of ksh for a while
Be specific.  *Which* version?

I can see from your cygcheck.out that you arenât talking about mksh, the only ksh that ships with Cygwin.  Therefore, I assume you mean AT&T ksh93.  Which version did you come from, and which did you upgrade to?
Doing a ksh --version gives me: version sh (AT&T Research) 93u+ 2012-08-01

I haven't upgraded yet because I have not been successful in compiling it. My attempt to do so is what began this unusual behavior (when I used the setup to get bison). I was compiling under 32-bit Cygwin and if successful would try it on the 64-bit version. The current version I am using will not work with 64-bit Cygwin.

Incidentally, please consider packaging ksh93u+ (stable) or ksh93v- (beta) for Cygwin.  It would be nice to have AT&T ksh for Cygwin, if only for reference and comparison purposes.  While doing compatibility testing with mksh, itâs hard to know if any given odd behavior is due to an mksh weirdness or if itâs accurately emulating AT&T ksh.

Right now I only have a binary of ksh which I have on all my systems.I am not sure what is involved in packaging ksh with Cygwin but would definitely be interested in finding out. Though, I was under the impression that if the licensing wasn't GNU it would be a problem even though it is open source.

did an update of cygwin
 From what version?  Or if you cannot be sure, about how long ago was your last update?
I am not sure but at the time it probably was at least 6 months but could have been much longer. In the end though I renamed my cygwin directory to _cygwin and renamed the branch in the registry as well to do a complete reinstall (I did not reinstall babun however) but this did not fix the problem. I have a new laptop that I just installed cygwin on but have not yet set it up so I can run my report script that would test it out on a new installation. Another script that gives me problems though worked fine.

I can see from your cygcheck.out that you are now on 1.7.35.  Did you read the release notes that strongly recommended that you to move /etc/passwd and /etc/group out of the way?  This is especially important in an AD-based organization like yours.

What is preventing you from becoming current?  (2.5.1)  I see in your message stuff about stuck postinstall scripts, but ipso facto, those are run *after* everything is installed, so that doesnât explain it.
It might be because I ran the cygcheck from babun instead of cygwin. I have attached that cygcheck file, though the issue comes up with both.

One result is that everything takes many times longer to complete. E.g. "ls" goes from under a second to give a listing to 20 or more seconds.
The usual way to find out whatâs happening is to run the problem program under strace, then see where the strace output hangs.

Realize that this is not a general problem, so weâre going to be relying on you to do much of the debugging.

That said, I donât think strace will help here, because I donât think you actually have a Cygwin-specific problem.

Another thing that happens is that Internet Explorer stops working - it loads unresponsive and then crashes.
Cygwin cannot affect IE, nor vice versa.  The only thing that can affect both is the OS kernel or something that ties into it: hardware drivers, antimalware software, certain types of malware...

Rebooting fixes the issue until I do something in one of my scripts that triggers it again.
Are you certain about that?  I mean, if you can cause the problem within a day by running these scripts, have you tried running a whole day without running any of those scripts, but doing everything else youâd normally do in that day the same way?

Iâll bet that if you try that, youâll find that the problem reoccurs anyway.
I am pretty sure that it depends on Cygwin. Meaning I have avoided cygwin for a day without the issue occurring and can make it happen at any time I want to by running my report script (which is why I only run it at night now). It takes a couple of minutes for it to download the data and then as soon as it prints "generating reports" it hangs and everything else does too. I.e. 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.

I see that youâre running Windows 7 Enterprise.  Doesnât that get you a copy of HyperV and a license to run another copy of Windows within it?  Why not install a fresh copy of Windows and Cygwin in a HyperV VM, then see if it runs into the same problems?  Iâll bet it doesnât, which will be interesting in its own right, plus it will let you get on with your work while you debug the actual problem out in the host environment.
I'll have to look in to that, though right now my efforts are directed towards getting the laptop set up which has a few things of its own to work out due to the need to run different VPN client software. My script runs VPNClient to make sure there is a connection to the DBs but now I have to look at some other software that I was provided with.

During the update that triggered this, it got stuck in the final part dealing with the 0p_000_autorebase.dash script.
Iâm not sure chasing this will have any effect.  If I am right that there is a 3rd party agent outside of Cygwin causing the problem, any autorebase problems could well be a side effect of that agentâs behavior.  This sort of problem is generally classed as âBLODAâ within Cygwin:

Do you have any of those listed software packages installed?  Which ones?  Have you tried temporarily disabling or uninstalling them?
My organization has Symantec Endpoint Protection installed. It isn't explicitly mentioned but it is Symantec so I'll try disabling it whilst the script runs and see what happens.

I ran "cygcheck -s -v -r" and have attached the results (I replaced my organization's name with aaa and similar though it probably wasn't necessary).
I also prefer to anonymize such data on general principles.

I can see that youâre in Ohio and possibly an employee of a nonprofit volunteer-based organization, however. :)

Incidentally, this message in your cygcheck.out says you should either remove or reinstall the Cygwin ping package:

Missing file: /usr/bin/ping.exe from package ping
ping                                  1.0.2-1            Incomplete

I suspect you installed it, found that it required admin privileges, then just removed the binary so that it would stop hiding the native Windows ping.exe.  Better to remove the package in that case.
I am not sure what happened with that but you are right that the binary isn't present. Another thing to add to the list of things to work out.

Thanks again for your help.

Attachment: cygcheck.out
Description: Text document

Problem reports:
Unsubscribe info:

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