Re: system lags and dysfunctional after cygwin update

[Ben Altman <benalt at gmail dot com>]

On 5/12/2016 11:57 AM, Warren Young wrote:
> On May 12, 2016, at 8:35 AM, Ben Altman <benalt@gmail.com> 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.
>
> Relevant:
>
>    http://unix.stackexchange.com/questions/246338/is-the-shell-ksh93-dead
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:
>
>    https://cygwin.com/faq/faq.html#faq.using.bloda
>
> 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.
Ben

Attachment: cygcheck.out
Description: Text document

--
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