Re: startxwin.exe no longer exists?
snip There is no reason that should happen unless the startxwin script also crashes - and that basically should never happen. The script should clean up any mess that the binary might leave, and it should handle all conditions that might result from some process it has started crashing. That is, in the script (pseudocode): # If there is an existing lock file: # Test is there also an existing X11 binary process? # yes - abort with message: X11 server already running # no - remove lock file ## # do whatever housekeeping is needed # then start binary /path/X11_server_binary $args #no matter how binary exits... rm /path/.X*lock The only time a script might not have a chance to run the last command is if it starts the server via nohup binary , assuming such a thing is even possible in cygwin, and then exits without waiting around for the binary to exit. Or, of course, if the whole system crashes, but that isn't the issue the end users are having. So you want your script to completely mask and/or destroy any evidence that something crashed?? That is very counter-productive toward anything resembling fixing a problem or even discovering a problem exists. Also, as the X server is not bound to a tty, it forks to the background on its own anyway, so your pseudocode example would delete the lock file just after the X server started. Regards, David Mathog -- Erik -- 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/
Re: startxwin.exe no longer exists?
snip So you want your script to completely mask and/or destroy any evidence that something crashed?? No, that is the log file, this is the lock file. It should rotate the log file from the previous run and delete the lock file. How often do you check your log files for crashes when you have your script hiding the fact that it crashed from you? Also, as the X server is not bound to a tty, it forks to the background on its own anyway, so your pseudocode example would delete the lock file just after the X server started. In that case the the script needs to retrieve the PID of the forked process and wait for it to exit. I would much rather have the binary process clean up after itself like it is supposed to, and figure out why the binary process is failing to do so when it doesn't than have a script that hides such failures from me. To each its own though. -- Erik -- 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/
Re: startxwin.exe no longer exists?
snip Shouldn't the startxwin script check for running instances and delete all lock-files related to non-existent instances? Why must this be a manual operation? I generally recommend against automagic cleanup of lock files from dead sessions being a general default because that also wipes out warning that something went wrong. I do it in my situation because I have it on (essentially) dumb terminals where the session working is much more important than knowing something went wrong, and the dumb terminals are on flaky power, so most of the dead sessions are due to power failure anyway. The prior startxwin.exe just worked, and this new replacement script is clearly creating problems for previously happy CygwinX users, where no problems existed before (or, at least the problems weren't visible and didn't affect normal use). I actually have no experience with startxwin; I always called the X server directly with the options I wanted. However, I can say that freeing of lock files is the job of the process that created the lock files. If you kill the process, stray lock files are a normal expectation. I would have preferred to have seen startxwin.exe retained, and this new script phased in gradually, perhaps as startxwin_new in the first release. Then, when startxwin_new stabilizes, rename the executable to startxwin_old.exe and the script to startxwin. Several updates later, quietly remove startxwin_old.exe. It seems nonsensical to treat all CygwinX users as alpha testers. I'm more than willing to help test new features, but not in the dark: Make it very clear when significant subsystems are being evolved, and provide a way to try the new without losing the old. The changes were announced, and the announcement already sited in this thread. Having read the announcement again, it looks like the replacement has as one of its goals bringing the X system more in line with general X and *nix standards, which, as far as I know, has always been a general goal of the entire Cygwin set of projects. For now, can startxwin.exe be restored under some name? -BobC That part I can't speak to except perhaps to pull it from an old version. I'm not part of the CygwinX team, and have no say in the matter. -- Erik -- 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/
Re: startxwin.exe no longer exists?
snip Apparently not. If I start an X session (using the standard menu item under the start menu) and manually shut it down, the lock file is not deleted. On a clean shutdown, the process should clean up its lock files; if it isn't, that needs to looked at and/or reported. The only caveat to that I'm aware of is if a debug flag is set, files the process uses may be intentionally left behind. However, it doesn't sound like you would be setting such flags. snip I actually have no experience with startxwin; I always called the X server directly with the options I wanted. What do you mean directly? From a mintty or such? Windows .bat/.cmd files, custom crafted shortcut on the desktop, windows registry changes... depends on the situation. The one I referenced with the dumb terminals and flaky power is a registry call in autorun starting a .cmd file. However, I can say that freeing of lock files is the job of the process that created the lock files. If you kill the process, stray lock files are a normal expectation. No they're not, unless you restrict kill to mean kill -9 or equivalent. If you kill a process using just kill, or by shutting it down normally, it should clean up its lock file. My apologies; I was only considering kill -9 as 'kill the process'. You are correct, kill -15 is also a kill, but should allow the process to exit cleanly. snip ... bringing the X system more in line with general X and *nix standards, which, as far as I know, has always been a general goal of the entire Cygwin set of projects. Then it's not succeeding. Shutting down X normally under *nix does not result in left-over lock files. I will certainly agree that shutting down X cleanly should not leave stray lock files behind. I can also say that I'm not experiencing that issue. My best guess (and this is only a guess) is that something is causing X to crash as it shuts down on your system, causing the lock files to be left behind. -- Erik -- 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/
Re: Xwin 1.14.2 (64 bit) extreme memory page faulting
snip Trying again; last time i tried it was looking like CentOS was going to skip the 5.9 release entirely... It seems it is there now and (so far) has two of the previously missing dependencies... we will see how far i get... --- Erik And that idea crashed and burned badly... After much googling and trying to force-fit the pieces anyway, it quickly became apparent that if I succeeded I would by then be running a Fedora system rather than CentOS; IS team here would have had my hide for breakfast... Next attempt: trying to get a test VM for Ubuntu or Mint; IS team may have my hide just for asking that one... Erik -- 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/
Re: Xwin 1.14.2 (64 bit) extreme memory page faulting
On Fri, Oct 4, 2013 at 10:03 AM, Ryan Johnson ryan.john...@cs.utoronto.ca wrote: On 04/10/2013 9:21 AM, Erik Soderquist wrote: if I succeeded I would by then be running a Fedora system rather than CentOS; IS team here would have had my hide for breakfast... Next attempt: trying to get a test VM for Ubuntu or Mint; IS team may have my hide just for asking that one... I suppose all of this comes in the name of security ? Sounds like you guys have the IT equivalent of the TSA... (my condolences to you and your colleagues) Ryan Actually they are quite honest about it being purely policy enforcement and software auditing. We're all network techs here, and are responsible for securing our own systems. --- Erik -- I do not think any of us are truly sane, Caleb. Not even you. Courage is not sanity. Being willing to die for someone else is not sanity. ... Love is not sane, nor is faith. ... If sanity lacks those things, Caleb, I want no part of it. -- Alexandria Terri in Weaving the Wyvern by Alexis Desiree Thorne - http://alexisthorne.webs.com/ -- 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/
Re: Xwin 1.14.2 (64 bit) extreme memory page faulting
snip The only (known) BLODA I have from that list is the McAfee A/V-firewall, which I can't remove, but I believe was completely disabled by the above described method. Unfortunately, McAfee is one of the worst offenders in my experience [1]. I seriously doubt you can disable it completely from user space, given its habits of interposing on device drivers and burrowing into other kernel bits [2]. [1] IMO it's a cure that's worse than the disease, but that's a rant for a different thread. [2] McAfee actually sued MS for anticompetitive behavior a while back, after the latter closed a bunch of security loopholes in the kernel that virus-writers love but McAfee also depended on (including the interrupt dispatch table IIRC). ... So fixing security failures is 'anticompetitive' in McAfee's book?? Wow... That is the kind of business that if i had the funds I would buy just to dismantle... I knew they were bad but didn't know they were *that* bad. snip there (or install a fresh VM image somewhere without those) and try again. If it's still a problem, somebody more familiar with X than me will have to take over... If I can get the authorization for a VM test without A/V, I will and the results will be posted here either way. Thank you for your time in looking at this. Good luck! Ryan Installed a fresh VM with a Windows XP 64 bit ISO, sp2 already applied. VM has 512 MB ram, and the only package I installed after the OS was cygwin. Issue presents in this environment as soon as Firefox connects/starts. Page Faults Delta over 5,000 minimum anytime I'm doing anything in Firefox, including typing this message, usually over 10,000. Then I went to the services applet and started disabling anything not needed to run the X server and get the connection to/from the remote host. Once nearly everything was disabled, i rebooted the VM. Currently there are only four Windows services running. They are: CYGWIN sshd, DHCP Client, Plug and Play, and Remote Procedure Call (RPC). Issue still presents. I've attached the XWin log and the cygcheck output from the VM. --- Erik vm_XWin.4.log Description: Binary data vm_cygcheck.out Description: Binary data -- 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/
Re: Xwin 1.14.2 (64 bit) extreme memory page faulting
snip Installed a fresh VM with a Windows XP 64 bit ISO, sp2 already applied. VM has 512 MB ram, and the only package I installed after the OS was cygwin. snip Followup: I confirmed that my VM host's environment's memory setting is set to lock all VM guest memory into physical ram, and doubled the VM's ram. No difference in results, issue still presents. --- Erik -- 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/
Re: Xwin 1.14.2 (64 bit) extreme memory page faulting
snip I just fired up a 64-bit Ubuntu VM I had laying around, installed firefox, and tunneled it to cygwin64/X on my win7-64 machine. X isn't even visible in the task manager when I sort descending by PF delta, CPU, or memory. This in spite of having half a dozen tabs with content (including ads, an html5 game, and a youtube video playing). Opening a couple dozen more empty tabs brought PFdelta up to the ~7k range, but the rate dropped back to ~0 as soon as the dust settled. Typing remains fully responsive, and I'm officially out of ideas. Ryan That is the kind of responsiveness I expect, and what other people I've discussed this with experience, which is why I think it is something unusual in my setup or environment... Unfortunately, I'm currently unable to find it myself, and can reliably reproduce the issue even in a virgin environment. So far, the only common factors (that I see) across each of these has been my Linux host, (CentOS 5.8 at present) and my various tabs/accounts. However, I am at a complete loss as to even guess at how these could affect page faulting on the X server. For reference: on the Linux host, when the Windows host is experiencing these page faults, the Linux host is reporting 20-30% CPU usage overall, no swap usage. --- Erik -- 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/
Re: Xwin 1.14.2 (64 bit) extreme memory page faulting
snip Huh. I have 1.14.3, not 1.14.2... have you tried upgrading just in case that's the issue? Ryan The virgin XP-64 VM is using 1.14.3, issue still presents. --- Erik -- 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/
Re: Xwin 1.14.2 (64 bit) extreme memory page faulting
On Thu, Oct 3, 2013 at 3:27 PM, Erik Soderquist erik.soderqu...@gmail.com wrote: snip Similar, to but different from Larry's suggestion, can you install Firefox on CentOS using the installer from Firefox itself, and not the distro version? I can imagine it could be something about flags or settings they used when compiling it. Jack I tried a couple times, and am willing to try again; however, I have not been able to resolve dependency conflicts to get a current version of Firefox to successfully install, let alone run. I fear this may have to wait for the host to be wiped and reloaded. Even then, I don't know what level of success I'll have, as currently it looks like it will be reloaded with CentOS 6. RHEL/CentOS are known for keeping solid and stable, not current... --- Erik Trying again; last time i tried it was looking like CentOS was going to skip the 5.9 release entirely... It seems it is there now and (so far) has two of the previously missing dependencies... we will see how far i get... --- Erik -- I do not think any of us are truly sane, Caleb. Not even you. Courage is not sanity. Being willing to die for someone else is not sanity. ... Love is not sane, nor is faith. ... If sanity lacks those things, Caleb, I want no part of it. -- Alexandria Terri in Weaving the Wyvern by Alexis Desiree Thorne - http://alexisthorne.webs.com/ -- 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/
Re: Xwin 1.14.2 (64 bit) extreme memory page faulting
On Wed, Oct 2, 2013 at 6:51 PM, Ryan Johnson ryan.john...@cs.utoronto.ca wrote: On 02/10/2013 2:50 PM, Erik Soderquist wrote: I am currently using the X server on a Windows 7 64 bit host for Firefox (in particular, occasional terminals too). snip Is there really a Firefox build for cygwin/X ? Or are you tunneling from some other machine? My apologies; Firefox is running on a CentOS host and I have tried both raw X and tunneled through ssh. I am currently tunneling though ssh as the raw X was a test only to see if it was a tunnel issue. Testing with antivirus and firewall enabled/disabled did not affect the results. (faq reference http://x.cygwin.com/docs/faq/cygwin-x-faq.html#poor-performance found during searches). If antivirus is a problem (as in BLODA), you probably need to uninstall, not just disable. They're usually too lazy to actually remove their hooks when off and just (try to) make the hooks become (mostly) no-ops instead. Not saying it's your problem, necessarily, just that merely disabling AV is not enough to rule it out. Unfortunately, uninstall is not an option for me. Corporate Policy prevents it on several levels. However, my disable of the A/V-firewall packages was by going into the Windows Services applets and disabling the services there and via a couple registry hacks and then rebooting so the A/V and firewall pieces could not load to start with. They are as ruled out as I can make them currently. I will look into the possibility of a VM to test without them entirely and see if i can still reproduce the issue. Also (not necessarily related to this particular problem), cygcheck reports a surprising selection of *nix-like utilities in c:\windows\bin. Whatever they are, they can't be helping. Those existed only on the current test machine. In theory, since they are later in the path in the cygwin environment, they should never be executed unless called by full path, but I do appreciate it being pointed out. I should have mentioned their existence on this machine to start with. I doubt it's an X-server code issue. You tried it on too many machines with problems, and too many other people aren't spamming the list about this, which suggests it's something on your side (like BLODA). Further, the only cygwin bug I've known to cause lots of paging was plugged months ago (it had to do with sparse executable files and should have been irrelevant for this situation anyway). The only (known) BLODA I have from that list is the McAfee A/V-firewall, which I can't remove, but I believe was completely disabled by the above described method. My advice: check out the cygwin FAQ about BLODA, uninstall anything listed there (or install a fresh VM image somewhere without those) and try again. If it's still a problem, somebody more familiar with X than me will have to take over... Ryan If I can get the authorization for a VM test without A/V, I will and the results will be posted here either way. Thank you for your time in looking at this. --- Erik -- 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/
