Re: A walking "bug" on Cygwin home page
On 2013-08-17 12:05-0400 Christopher Faylor wrote: On Sat, Aug 17, 2013 at 01:13:14PM +0200, Angelo Graziosi wrote: Have you noticed the walking "bug" appeared today on the Cygwin Home Page (http://www.cygwin.com). I initially thought that it was a real insect inside my PC monitor, but then I realized it was a "graphical" bug walking on the same path, an horizontal "8". I wonder if it doesn't hide some new malaware... It's a well known fact that all software (and web sites) have bugs. Chris, I think you will want to take the original question concerning malware more seriously. If you actually take the time to look at cygwin.org it appears that either the developer of that website has an extremely weird sense of humor or else that website has been hacked into and defaced. Which? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: Home directory issue
On 2013-07-08 13:21-0400 Larry Hall (Cygwin) wrote: I believe you have drawn the opposite conclusion from what I was trying to convey. It is best to _not_ have HOME set in your Windows environment prior to running 'setup.exe'. If you do have it set, 'setup.exe' will use that directory as your home rather than the default '/home/'. Your original message (especially the last part) was pretty clear, but I just reversed the meaning. Sorry. I actually ran setup.exe from a bash/wine environment, and for that the HOME environment variable (as printed out by printenv |grep HOME ) was not set. So there is likely some other reason (which may or may not be related to a Wine bug) that I got the same symptoms as the OP. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: Home directory issue
On 2013-07-08 11:09-0400 Larry Hall (Cygwin) wrote: On 7/2/2013 7:50 PM, L. V. Lammert wrote: After installing Cygwin on a new system that is in a domain, there is something that is breaking with user setup. * The user home directory is not getting created * /usr/loca/bin & /usr/bin are not prepended to PATH * The user home directory is/cygdrive/Users/, instead of/home/ * The path IS correct in/etc/passwd (/home/) Is the HOME environment variable set in your Windows environment? If not, check the postinstall scripts in '/etc/postinstall', paying particular attention to those that don't end in '.done'. If you have some of these, run them yourself with 'sh ' and then move the script to '.done' Run the scripts in the order they appear. Otherwise, if HOME is defined in the Windows environment, just remove the definition. You may find you have to rerun some of the postinstall scripts to "recover", particularly '000-cygwin-post-install.sh'. Or you can try wiping the installation and starting over. I experienced all the same symptoms reported by the OP with my setup.exe on Wine attempt. So you have given me hope that some of the errors I saw were due to not setting HOME. Could you be more specific about exactly how HOME should be set "in your Windows environment". Under Wine I can get into a cmd environment. From there the top-level directory of the Cygwin installation directory that I usually create with setup.exe is designated as z:\home\wine\newstart\cygwin That same directory is designated as /z/home/wine/newstart/cygwin from the bash/wine environment. What exact cmd command should I use to set HOME for user "wine" before I run a setup.exe from cmd to establish a Cygwin installation tree from scratch whose top-level is given above? Would it be set HOME=z:\home\wine\newstart\cygwin\home\wine or something else? I prefer the bash environment so if I set the HOME environment variable from there would setup.exe (run from bash) pick that up and use it? If so, would it be set by export HOME=/z/home/wine/newstart/cygwin/home/wine or something else? (As you can probably tell, I am having some difficulty in sorting out the differences in the way directories and environment variables are specified, at the bash/linux, bash/wine, cmd/wine, and cygwin/wine levels.) Are there any other environment variables that should be set as well before running setup.exe for a fresh install? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: Failure with fork() (Cygwin on Wine install now sort of works)
On 2013-07-05 16:48-0400 Christopher Faylor wrote: On Fri, Jul 05, 2013 at 12:11:10PM -0700, Alan W. Irwin wrote: On 2013-07-04 13:39-0700 Alan W. Irwin wrote: So if the consensus here after looking at the setup_install.out results is that cygwin on Wine is more or less installed properly from these results (except for the rename issue above which I can fix by doing that rename manually as suggested by the error message), then the next order of business [...] I have now looked more carefully at the setup_install.out results that are wrapped inside a tarball I attached to a previous post in this thread. At the same time I have also looked at the resulting files in my cygwin install tree. It turns out that because of errors the first install script created an empty /etc/fstab rather than the desired result and also was unable to create the /dev directory. The /dev directory is a pseudo-directory created on-the-fly by the Cygwin DLL. I was really curious about the implications of that so had some further questions, but I am going to drop those questions because they are a distraction from the principal point I want to make. In sum, if any Cygwin developer here feels moved to help debug Wine so that the Cygwin install works properly on it, the best thing you could do would be to follow the steps I detailed at at <http://bugs.winehq.org/show_bug.cgi?id=24018>) with Wine-1.6-rc4 patched with Andrey Turkin's patch, and with Cygwin updated with the recent snapshot cygwin1.dll that contains the fork fix. Then run that exact same setup.exe procedure (with the fork fix applied in the same way) on Microsoft Windows. Such direct comparisons between Wine and Microsoft Windows results would be a great help in figuring out which of the many error messages that show up in a fresh install of Cygwin on Wine should actually be of concern to Wine developers. (I cannot do such comparisons myself because I don't have ready access to Microsoft Windows, i.e., I have been running Linux since 1996 and my only Windows experience is running MinGW/MSYS on Wine off and on as a build and test platform for software for the last couple of years). Alan ______ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: Failure with fork() (Cygwin on Wine install now sort of works)
On 2013-07-04 13:39-0700 Alan W. Irwin wrote: So if the consensus here after looking at the setup_install.out results is that cygwin on Wine is more or less installed properly from these results (except for the rename issue above which I can fix by doing that rename manually as suggested by the error message), then the next order of business [...] I have now looked more carefully at the setup_install.out results that are wrapped inside a tarball I attached to a previous post in this thread. At the same time I have also looked at the resulting files in my cygwin install tree. It turns out that because of errors the first install script created an empty /etc/fstab rather than the desired result and also was unable to create the /dev directory. These issues very likely had follow-on effects for several of the other postinstall scripts that were run (for example, all the read-only filesystem error messages when any attempt was made to write to /dev.) Anyhow, it now seems likely there are at least a couple of Wine bugs that are still preventing a clean postinstall phase for setup.exe on Wine, and the rest of this story will continue for now at http://bugs.winehq.org/show_bug.cgi?id=24018. Meanwhile, I thank the people here that (a) helped to fix the Cygwin fork bug, and (b) gave me good directions for trying out that fix before it becomes part of an official Cygwin release. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: Failure with fork() (Cygwin on Wine install now sort of works)
Addendum. I just noticed the request for cygcheck results at http://cygwin.com/problems.html. Accordingly, I put /z/home/wine/newstart/cygwin/bin at the top of my MSYS (on Wine) PATH, then executed bash.exe-3.1$ cygcheck.exe -s -v -r >cygcheck.out That generated a response to the terminal which was cygcheck: Wrong architecture. Only ix86 executables supported. For the record, I am using 32-bit Cygwin on 32-bit Wine on 64-bit (x86_64) hardware. My Linux platform is Debian wheezy with mostly 64-bit libraries installed, but 32-bit Wine was built specifically with some extra 32-bit libraries I specifically installed for that purpose. So I don't know the source of that interesting message. Note, that message occurs for the part of the cygchek results that depend on cygwin1.dll. If I fail to put cygwin/bin on my PATH, then cygcheck complains that cygwin1.dll is not available but also does not generate the above message. I attach the cygcheck.out file generated as above in case somebody can spot anything wrong in that report with my initial Cygwin on Wine install. But superficially, it looks OK to me so it is possible that my Cygwin on Wine installation is fine. Note, my original message to this list with plain cygcheck.out attached (as requested on the problems page) bounced for some reason so I am trying a compressed version of cygcheck.out this time. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ cygcheck.out.gz Description: compressed output from cygcheck for Cygwin on Wine -- 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
Re: Failure with fork()
I will attempt to answer the further posts that have come in since my last post. My background is I help to develop, build, and test a number of free cross-platform software projects (e.g., PLplot). Those projects are mostly developed on Linux, but I want to make sure they work well on various Windows platforms such as "bare" Windows with Windows proprietary compilers, MinGW with MSYS, and Cygwin. I leave checking of Windows proprietary compiler results and any Microsoft version of Windows to others (I don't have the money or desire to get involved with such tests), but I would like to help out with testing the MinGW/MSYS case and also the Cygwin case using Wine. As a result I am a fairly heavy but non-sophisticated user of Wine, and I have had good success with building and testing a variety of software projects for the combination of MinGW, MSYS, and Wine. I have recently tried to extend that success to the Cygwin on Wine platform, but so far no luck. One poster here suggested I would probably encounter a whole series of Cygwin on Wine showstopper bugs (like unpeeling an onion). That negative view should be answered. Historically there has been a lot of interest in running Cygwin on Wine by Wine developers. According to their bugzilla they encountered a few fairly minor problems in the past such as the inability to resize the setup.exe GUI. (I actually haven't bothered to test whether that bug still exists since I didn't care about that, but it is likely some of those bugs have disappeared because Wine-1.6 is generally a huge advance on previous versions of Wine. So the only Cygwin on Wine showstopper on the list of Wine bugs I am aware of was wine bug 24018 <http://bugs.winehq.org/show_bug.cgi?id=24018> which is actually a Cygwin regression introduced a couple of years ago, but now fixed by the recent efforts here. However, because that regression persisted so long (because of a failure to communicate the problem to the Cygwin developers who very quickly fixed it once they became aware of it), the Cygwin on Wine combination has essentially been untested for the last three years. As a result there has been a chance for additional regressions to creep in. But I doubt very much that there is a huge list of such regressions that are actual showstoppers, and it is more likely there is only one showstopper (the hang I am encountering now) or else no showstoppers (because I am doing something wrong due to my lack of knowledge of Cygwin). To figure out which is the case, it is definitely time for a wine expert with some interest in Cygwin (or Cygwin expert with some interest in Wine) to take over now. I have already informed the wine-devel list of this thread, and will follow up with an additional post there summarizing the current situation to maximize the chances that some volunteer with the necessary expertise will step forward. Once someone else has demonstrated setup.exe works on Wine-1.6 at least as well as it did in the past for older Cygwin and Wine versions, and assuming I can mimic that setup.exe success, then I have every expectation of success with the builds and tests of free software on the Cygwin/Wine platform. The reason for such confidence is such build efforts would use a tool chain that is similar to the MinGW/MSYS one that has already proved to work so well on Wine-1.6, and because such build efforts would only involve a small subset of Cygwin beyond that toolchain which should reduce the likelihood of running into Cygwin or Wine bugs during such software builds. One of the goals of that effort would be to help the PLplot project's Arjen Markus (the OP) who is currently our only tester of PLplot on Cygwin (on a Microsoft Windows platform in his case) to make sure PLplot builds and tests on Cygwin without issues regardless of whether the underlying Windows platform is Microsoft or Wine. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: Failure with fork()
On 2013-06-27 23:42-0700 Alan W. Irwin wrote: I am getting absolutely nowhere. A script run by setup.exe in the latter part of the install steps appears to hang now with or without updating cygwin1.dll to the fork-fixed version. I got this result for two versions of wine which I have heavily tested in other ways, wine-1.5.19, and a wine-git version near wine-1.6.0-rc1. Here are the last few messages before the hang: Installing file cygfile:///usr/share/man/man1/xzfgrep.1.gz AddAccessAllowedAce(, group) failed: 1337 Installing file cygfile:///usr/share/man/man1/xzgrep.1.gz AddAccessAllowedAce(, group) failed: 1337 Installing file cygfile:///usr/share/man/man1/xzless.1.gz AddAccessAllowedAce(, group) failed: 1337 Installing file cygfile:///usr/share/man/man1/xzmore.1.gz AddAccessAllowedAce(, group) failed: 1337 AddAccessAllowedAce(, group) failed: 1337 Extracting from file://Z:\home\wine\newstart\cygwin\packages/http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/release/zlib/zlib0/zlib0-1.2.8-1.tar.bz2 Installing file cygfile:///usr/bin/cygz.dll AddAccessAllowedAce(, group) failed: 1337 AddAccessAllowedAce(, group) failed: 1337 Visited: 51 nodes out of 2986 while creating dependency order. Dependency order of packages: base-cygwin sed gzip libpcre0 gettext grep libmpfr4 gawk tzcode libgmp3 libattr1 libncurses10 texinfo _update-info-dir libreadline7 terminfo libstdc++6 libncursesw10 libiconv2 libintl8 bash coreutils cygwin libgcc1 dash rebase _autorebase alternatives findutils base-files libbz2_1 bzip2 libpopt0 cygutils diffutils dos2unix editrights zlib0 file groff ipc-utils less liblzma5 login xz man mintty run tar vim-minimal which running: Z:\home\wine\newstart\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/000-cygwin-post-install.sh" There is no obvious chance that I can see before that hang where I can overwrite cygwin1.dll with the corrected version. However, if I exit the hang, overwrite cygwin1.dll, and run the above script by hand it still hung (no cpu activity and no change in the cygwin tree that changes its total size as measured to the nearest byte with "du -s --bytes cygwin") for ~20 minutes before I gave up. By the way, after exiting after the first hang, if I simply overwrite cygwin1.dll with the corrected version, then run setup.exe the install stage errors out immediately with the message "Can't open package database for writing. File exists." It's for that reason that I tried to run the hanging script by hand to see if I could get any further. I didn't get these hangs a month ago when I tried all this before with wine-1.5.19. Instead, at that time I got the exact error message when running the above script concerning an unhandled page fault that others have described at http://bugs.winehq.org/show_bug.cgi?id=24018 and which the fork-fixed cygwin1.dll is supposed to fix. So presumably Cygwin's bash.exe or some application executed by the above script has changed in the last month to cause the different wine symptoms. Or I am inadvertently doing something different than I did a month ago. So unless someone can suggest a method to get around the "Can't open package database for writing. File exists." message, and assuming that method doesn't subsequently run into the script hang (which is a big if), then I think it is time for someone with a lot more wine and cygwin expertise than me to take over here to attempt to try and figure out a way to run setup.exe on Wine with fork-fixed cygwin1.dll overwriting the buggy version. I did a few more experiments. If cygwin/bin is on the PATH, the explicit MSYS bash version runs the script with no issues. So it is likely the hang is caused by the Cygwin version of bash rather than something run in the script. I also was able to get around the "Can't open package database for writing. File exists." issue. I searched for anything associated with databases by using find cygwin -iname "*db*" which found cygwin/etc/setup/installed.db.new cygwin/etc/setup/installed.db which were identical. If I removed cygwin/etc/setup/installed.db, then I could rerun setup.exe without the error message showing up. However, as some of the applications were installed on top of the same applications that had been installed for the previous setup.exe run, I got occasional messages about overwriting files in use. I just answered all those error boxes as "continue" and that allowed the second try for setup.exe to get as far as the first try. However, it got absolutely no further because the same script hung again! Also, all these installs on top of the old installs presumably overwrote cygwin1.dll with the fork-buggy version again. So it is very likely that cygwin/etc/setup/installed.db is probably not the right workaround. Instead, presumably something changed by the hanging script or some script that setup.exe would normally
Re: Failure with fork()
I am getting absolutely nowhere. A script run by setup.exe in the latter part of the install steps appears to hang now with or without updating cygwin1.dll to the fork-fixed version. I got this result for two versions of wine which I have heavily tested in other ways, wine-1.5.19, and a wine-git version near wine-1.6.0-rc1. Here are the last few messages before the hang: Installing file cygfile:///usr/share/man/man1/xzfgrep.1.gz AddAccessAllowedAce(, group) failed: 1337 Installing file cygfile:///usr/share/man/man1/xzgrep.1.gz AddAccessAllowedAce(, group) failed: 1337 Installing file cygfile:///usr/share/man/man1/xzless.1.gz AddAccessAllowedAce(, group) failed: 1337 Installing file cygfile:///usr/share/man/man1/xzmore.1.gz AddAccessAllowedAce(, group) failed: 1337 AddAccessAllowedAce(, group) failed: 1337 Extracting from file://Z:\home\wine\newstart\cygwin\packages/http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/release/zlib/zlib0/zlib0-1.2.8-1.tar.bz2 Installing file cygfile:///usr/bin/cygz.dll AddAccessAllowedAce(, group) failed: 1337 AddAccessAllowedAce(, group) failed: 1337 Visited: 51 nodes out of 2986 while creating dependency order. Dependency order of packages: base-cygwin sed gzip libpcre0 gettext grep libmpfr4 gawk tzcode libgmp3 libattr1 libncurses10 texinfo _update-info-dir libreadline7 terminfo libstdc++6 libncursesw10 libiconv2 libintl8 bash coreutils cygwin libgcc1 dash rebase _autorebase alternatives findutils base-files libbz2_1 bzip2 libpopt0 cygutils diffutils dos2unix editrights zlib0 file groff ipc-utils less liblzma5 login xz man mintty run tar vim-minimal which running: Z:\home\wine\newstart\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/000-cygwin-post-install.sh" There is no obvious chance that I can see before that hang where I can overwrite cygwin1.dll with the corrected version. However, if I exit the hang, overwrite cygwin1.dll, and run the above script by hand it still hung (no cpu activity and no change in the cygwin tree that changes its total size as measured to the nearest byte with "du -s --bytes cygwin") for ~20 minutes before I gave up. By the way, after exiting after the first hang, if I simply overwrite cygwin1.dll with the corrected version, then run setup.exe the install stage errors out immediately with the message "Can't open package database for writing. File exists." It's for that reason that I tried to run the hanging script by hand to see if I could get any further. I didn't get these hangs a month ago when I tried all this before with wine-1.5.19. Instead, at that time I got the exact error message when running the above script concerning an unhandled page fault that others have described at http://bugs.winehq.org/show_bug.cgi?id=24018 and which the fork-fixed cygwin1.dll is supposed to fix. So presumably Cygwin's bash.exe or some application executed by the above script has changed in the last month to cause the different wine symptoms. Or I am inadvertently doing something different than I did a month ago. So unless someone can suggest a method to get around the "Can't open package database for writing. File exists." message, and assuming that method doesn't subsequently run into the script hang (which is a big if), then I think it is time for someone with a lot more wine and cygwin expertise than me to take over here to attempt to try and figure out a way to run setup.exe on Wine with fork-fixed cygwin1.dll overwriting the buggy version. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: Failure with fork()
On 2013-06-27 15:56-0500 Yaakov (Cygwin/X) wrote: On 2013-06-27 15:33, Alan W. Irwin wrote: I think you keep assuming I have some version of Cygwin already installed when that is not the case. It is the last stage of the initial attempt at installation using setup.exe that fails on Wine due to the fork bug. Furthermore, when I download setup.exe from http://cygwin.com/setup.exe it contains the fork bug. That version is self-contained, i.e., only setup.exe needs to be downloaded, not cygwin1.dll in addition. I presume that is because setup.exe uses a static version of the cygwin library as a matter of convenience rather than depending on an external cygwin1.dll that could be separately downloaded. There is no such thing as static linkage of Cygwin. setup.exe is in fact a native Windows (MinGW) executable, due to the fact that it needs to be able to run before Cygwin is installed, or while upgrading cygwin1.dll. Therefore, if you are seeing fork() errors when running setup, they are actually coming from the postinstall scripts which are run after installing files. In that case, the best solution may be something along the lines of (untested): 1) Open the Wine equivalent of taskmgr.exe. 2) Run setup.exe again and install just the Base packages. 3) During postinstall, kill any bash.exe processes ASAP. 4) setup.exe should list some postinstall errors before completion, which can be ignored for now. 5) After setup.exe is finished, replace C:\cygwin\bin\cygwin1.dll with the latest snapshot DLL. 6) Run setup.exe again with the same options; the postinstall scripts should (in theory) run properly this time. 7) Launch Cygwin Terminal once to set up your environment. 8) Run setup.exe one more time to install additional packages. Once the relevant snapshot is released I will let you know how far I get with a variant of the above I have thought of which is replacing cygwin1.dll on the fly when the individual step of the initial run of setup.exe that installs cygwin1.dll is completed. That method takes advantage of the fact that the fork issue only occurs during the final step of the install and presumably nothing is using cygwin1.dll when the prior step that installs cygwin1.dll is completed. So ideally this method would be completely error free, but I will see about that, and if not I will fall back to trying your method. Thanks to you and the many (!) other posters here for clarifying the issue (i.e., that the fork issue I see as a result of running setup.exe is in one of the invoked commands that are linked to cygwin1.dll that is downloaded by setup.exe and not in setup.exe itself.) More later. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: Failure with fork()
On 2013-06-27 21:13+0200 marco atzeri wrote: Il 6/27/2013 9:01 PM, Alan W. Irwin ha scritto: I have now found the snapshots page, and the latest one contains 013-06-18 Christopher Faylor * dcrt0.cc (child_info_fork::alloc_stack): Don't subtract 4096 from stack pointer since getstack() already does that. Could someone confirm that is the fork fix of interest here? Of course not. Corinna solved the problem today and cygwin1-20130619.dll.bz2 was built last 19th June so you need to wait the next one. Sorry about that. Didn't check the date, and it looked promising because of that reference to fork and the stack. I am somewhat confused by the remark at http://cygwin.com/faq-nochunks.html#faq.setup.snapshots that "You cannot use Cygwin Setup to install a snapshot." So what exactly is installed by a snapshot? Is it just the core part of Cygwin? It is just the core cygwin1.dll The easy way is copy the new one on the current one. Of course all cygwin processes must be shutdown before.. I think you keep assuming I have some version of Cygwin already installed when that is not the case. It is the last stage of the initial attempt at installation using setup.exe that fails on Wine due to the fork bug. Furthermore, when I download setup.exe from http://cygwin.com/setup.exe it contains the fork bug. That version is self-contained, i.e., only setup.exe needs to be downloaded, not cygwin1.dll in addition. I presume that is because setup.exe uses a static version of the cygwin library as a matter of convenience rather than depending on an external cygwin1.dll that could be separately downloaded. I have looked at the table of contents of the latest cygwin-inst-20130619.tar.bz2 since that appears to be the most complete recent snapshot version. Although it does contain a number of *.exe files and other core components of cygwin as advertised it is missing many components of Cygwin that I need. Also, it is missing the key setup.exe core component which precludes any chance of installing the rest of what I need based on this snapshot version of Cygwin. So the question still remains how do I gain access to a version of setup.exe with the fork fix that will allow me to not only initialize my Cygwin distribution for Wine without the fork abort, but also subsequently update it to install all components of Cygwin that I need? Alan ______ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: Failure with fork()
On 2013-06-27 21:00+0200 marco atzeri wrote: Il 6/27/2013 8:35 PM, Alan W. Irwin ha scritto: Are there daily snapshot builds of the CVS version I could access? daily not, but on reasonable schedule (aka when Corinna or Christopher release one) http://cygwin.com/snapshots/ just wait for the next cygwin1-20130xxx.dll.bz2 and replace the installed cygwin1.dll with the new one I haven't even gotten as far as an initial install because of this fork bug. From the Linux command line here is what I did some time ago (for a wine-git version very close to wine-1.6.0-rc1 and for (presumably) the latest stable release of setup.exe downloaded from http://cygwin.com/setup.exe) when I first ran into the fork bug: wineconsole setup.exe The setup GUI fired up, I went through all the screens without issues, but then the final screen completely bombed out due to this fork bug. Any attempts to use setup.exe afterward failed immediately (presumably because that aborted last screen of the GUI did not complete some critical task.) So I think I have to do a complete installation from cygwin-inst-MMDD.tar.bz2, and assuming that contains setup.exe, run that version from wineconsole to obtain a a Cygwin system where I select the further packages I need to have installed (the build tools as well as some important library dependencies such as pango, cairo, and Qt4) so that I can build further software on the Cygwin platform. Do you agree this is the right approach? Also, I think the current snapshot actually does contain the fork bug fix, but I have asked for confirmation of that in my last post. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: Failure with fork()
On 2013-06-27 11:35-0700 Alan W. Irwin wrote: The only Windows platform available to me is Wine. And I have no Cygwin on Wine experience at this stage because this fork bug shut me out. But now that it is fixed in CVS, how do I get access to the fixed version of setup.exe? Are there daily snapshot builds of the CVS version I could access? Never mind. I have now found the snapshots page, and the latest one contains 013-06-18 Christopher Faylor * dcrt0.cc (child_info_fork::alloc_stack): Don't subtract 4096 from stack pointer since getstack() already does that. Could someone confirm that is the fork fix of interest here? I am somewhat confused by the remark at http://cygwin.com/faq-nochunks.html#faq.setup.snapshots that "You cannot use Cygwin Setup to install a snapshot." So what exactly is installed by a snapshot? Is it just the core part of Cygwin? Is there enough included in cygwin-inst-MMDD.tar.bz2 so I can run setup.exe from the installed version of that tarball to download and install or update additional Cygwin components that I might need? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: Failure with fork()
I have been following this thread with great interest via the archive, but now I have newly subscribed to this list to ask additional questions. Corinna said "Should be fixed in CVS. Thanks (to Arjen) for the report." My thanks to Arjen for getting this thread started, and my thanks to Corinna for so swiftly finding the fix. I would now like to test this fix from a broader perspective of attempting to run the fixed setup.exe version on Wine. My background is I have had considerable success with using the combination of MinGW, MSYS, and Wine as a build and test platform for free software. I would like to similarly attempt to use the combination of Cygwin and Wine as a build and test platform for free software but I was stopped from doing that because the last stage of running Cygwin setup.exe on Wine ran into this fork issue. The only Windows platform available to me is Wine. And I have no Cygwin on Wine experience at this stage because this fork bug shut me out. But now that it is fixed in CVS, how do I get access to the fixed version of setup.exe? Are there daily snapshot builds of the CVS version I could access? Or do I have to build the CVS version of Cygwin from scratch on (the Wine version of) Windows using MinGW and MSYS, and if so is there a website with directions for how to do that? Sorry for the Cygwin newbie questions, but I am quite experienced with the Unix command line and building software both on Linux and on the bash.exe command line accessible with MinGW/MSYS/Wine so I hope I will only need hints to get started with (a) building the CVS version of Cygwin with the fork fix, and (b) building and testing software for the Cygwin on Wine platform. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Background process with Cygwin
I have been beating my head on a wall for two weeks and have googled til my fingers bled. I am running windows server 2003 with cygwin. I am attempting to get a bash script to continue to run in cygwin even after I have logged out. I have tried several different tactics. The most recent and closest to success has been using the “nohup” command. I am opening a cygwin bash window and typing the following: $ nohup mycommand.bash & The script runs in the background but the bash window stays open. When I log out or try to close the window I executed nohup from, I get the following error…… $ 3 [main] ? child_copy: cygheap read copy failed, 0x611688E0..0x611706D0m dibe 0, windows pid 0, Win32 error 5 1876 [main] bash 5072 child_copy: dll data read copy failed, 0x61102000..0x61106BA0, done 0, windows pid 5072, Win32 error 5 The window will stay up for a few minutes and then go away and the script that was running is now dead. I am not an expert by any means so any help regardless of how elementary is appreciated. I know I am not the first squirrel to try to crack this nut so I figured I would toss this out in hopes some “big brain” would take notice and pity. _ Rediscover Hotmail®: Get quick friend updates right in your inbox. http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates1_042009 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Re: username should be lower-case for $USER
...snip... > If the user ID is created with lower-cased letters, it will be stored > and reported in lower-cased letters. At least that is how the Windows > 2003 Active Directory where I work expresses its user IDs. ...snip... U-huh. Just played around in the GUI and that seems to be true. I reckon I was getting confused with some APIs returning in upper. The comparisons Certainly are case insensitive, tho. TFT! -doug -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Re: username should be lower-case for $USER
Hi all, My first constructive post to this group outside of my inane question asking... > TDavid Smiley wrote: > > I am new to Cygwin. I noticed that the $USER environment variable has > > my username in upper-case. So it is "DSMILEY". > > As David said, that's because you created your username in ALL UPPERCASE when setting up the user > on Windows. > > The only way to "fix" this for you would be to rename your Windows user to have a lower-case name. > (If windows allows that operation..) As covered later in this thread the user is logging into a domain. Windows is indeed case insensitive WRT logins and can even be forced into case insensitive mode for passwords programatically (as demonstrated by the l0phtcrack algorithm). But I have never seen a DOMAIN report the user id back in lowercase, even when it was specifically entered in lower case (I may be wrong about this - please let me know if you have contrary evidence). There is another workaround, tho! In my environment I log into the domain with a login in the form "AA", but need my Cygwin environment to recognise me as "sybase". So I simply edited the leading column of my record in /etc/passwd and changed the contents "sybase". Since the other tokens linking me record to the domain account were unchanged Cygwin sees me as "sybase", but the domain sees me as myself. This has been working for well over a year. If anyone sees any problems with it I'd be glad to hear form them. -doug echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' |dc -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Read not honouring "-r"?
Hi All, Gerald, you are gold! For some reason I expected to see ^M's in the file if it was DOS format. Opening filesystems.cfg in Ultraedit failed to prompt with "Do you want to convert filesystems.cfg to DOS format?", so it was DEFINITELY in DOS format (as if there is any doubt). Consequently running dos2unix on filesystems.cfg fixed it straight away. The other responses are very interesting too. Also - using "cat filesystems.cfg | while read" isn't an option because we need variables set inside the while loop to be visible outside it (oh the joys of porting existing Solaris scripts). Thanks everyone how made suggestions, etc. Interested to hear about anything else related. Best regards, -doug -Original Message- From: Williams, Gerald S (Jerry) [mailto:[EMAIL PROTECTED] Sent: Tuesday, 19 September 2006 11:24 PM To: cygwin@cygwin.com Subject: RE: Read not honouring "-r"? Doug Irwin wrote: > One would expect a "read -r fs t2 t3" to process this without > attempting to expand slashes. But I can't seem to get this bit > working... And I can't seem to find any doco on doing that in Cygwin. > > I've attached the files I am testing with in the hope that someone can > help me work this out. > > No doubt I have missed something rather obvious. "-r" has nothing to do with it: CR/LF line endings are the culprit. This seems to be particularly tied to ksh, and specifically when you use "<" to redirect a file. If you simply pipe the output of grep to the while loop, it works. Interestingly, sh, bash, and zsh all give the behavior you were expecting. So for the short term, run d2u on filesystems.cfg. If you plan to continue using ksh, you may want to follow up and try to understand the discrepancy--there may be an option that allows you to get the behavior you want (and if not, it may be worth having KSH's behavior changed to be more consistent with other shells, but that's something for the maintainer and/or upstream KSH support to decide). gsw -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Read not honouring "-r"?
Hi Larry, Sorry about the double post - the mailserver reported that it had (a) stripped the attachments and (b) blocked the post. It obviously lied. If you call it with pdksh instead you should get: / 200 200 200 200 200 200 sr/bin 200 200 usr/lib 200 200 So it sounds pdksh related. Cygcheck.out attached in case it's of use. Apologies again for the double post. Thanks and regards, -doug cygcheck.out Description: cygcheck.out -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Read not honouring "-r"?
All, I am working on a script which monitors mounts for free space. It does this by reading from a config file (surprise) consisting of mount, threshold, threshold. One would expect a "read -r fs t2 t3" to process this without attempting to expand slashes. But I can't seem to get this bit working... And I can't seem to find any doco on doing that in Cygwin. The files I am using are tagged on the and in the hope that someone can help me work this out. Sorry, but the mailservers blocks them otherwise :( No doubt I have missed something rather obvious. Any assistance greatly appreciated! Regards, -doug -- test.sh -- #!/bin/ksh FSCFG=./filesystems.cfg grep -v '^#' $FSCFG > /tmp/fscfg$$ while read -r fs t2 t3 do echo "$fs" echo "$t2" echo "$t3" done < /tmp/fscfg$$ -- filesystems.cfg -- / 200 200 /c 200 200 /d 200 200 /usr/bin200 200 /usr/lib200 200 -- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Read not honouring "-r"?
All, I am working on a script which monitors mounts for free space. It does this by reading from a config file (surprise) consisting of mount, threshold, threshold. One would expect a "read -r fs t2 t3" to process this without attempting to expand slashes. But I can't seem to get this bit working... And I can't seem to find any doco on doing that in Cygwin. I've attached the files I am testing with in the hope that someone can help me work this out. No doubt I have missed something rather obvious. Any assistance greatly appreciated! Regards, -doug test.sh Description: test.sh filesystems.cfg Description: filesystems.cfg -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: 1.5.18-1: incorrect cron "script not found" message (Win2k).
This went quiet on the server until this weekend. Same kind of thing in the logs, tho :( Larry (or anyone else) - have you had an opportunity to look at this? Thanks again. -doug echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' |dc -Original Message----- From: Irwin, Doug Sent: Thursday, 10 August 2006 8:28 AM To: cygwin@cygwin.com Subject: RE: 1.5.18-1: incorrect cron "script not found" message (Win2k). Hi Larry, > Nope. You were right. I was conveniently looking at another > cygcheck.out. > I hate when that happens. LOL! NP! In my role as DBA that happens frequently... To me! :D > There's nothing obvious from the configuration. I assume that only > HA\sybase has cron jobs running or have you enabled permissions for it > locally that would allow it to switch users for other crontabs? Does > it work more reliably with a local user? How about with > cygwin-1.5.21? Yep, just HA\sybase. Exact same setup on a Win2k3 machine works fine. As for 1.5.21... I haven't tried :D Thanks for looking into this! -doug echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' |dc -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: 1.5.18-1: incorrect cron "script not found" message (Win2k).
Hi Larry, > Nope. You were right. I was conveniently looking at another > cygcheck.out. > I hate when that happens. LOL! NP! In my role as DBA that happens frequently... To me! :D > There's nothing obvious from the configuration. I assume that only > HA\sybase has cron jobs running or have you enabled permissions for it > locally that would allow it to switch users for other crontabs? Does > it work more reliably with a local user? How about with > cygwin-1.5.21? Yep, just HA\sybase. Exact same setup on a Win2k3 machine works fine. As for 1.5.21... I haven't tried :D Thanks for looking into this! -doug echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' |dc -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: 1.5.18-1: incorrect cron "script not found" message (Win2k).
Hi Larry, > Looks like you sent the cygcheck output for ZIGGY rather than > server2... > > -- > Larry Hall http://www.rfk.com > RFK Partners, Inc. (508) 893-9779 - RFK Office > 216 Dalton Rd. (508) 893-9889 - FAX > Holliston, MA 01746 Come again? Just checked the original sent's cygwin.out and it looks OK to me... Which isn't to say I didn't mess up! -doug echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' |dc -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.5.18-1: incorrect cron "script not found" message (Win2k).
Hi All, I hate difficult-to-reproduce issues :( It makes accurate reporting difficult... We have a crontab which runs scripts that check whether a DBMS is accessible, doesn't have inappropriate locks in certain DBs, dumps databases, etc. During the time database dumps are running some of our scripts occasionally raise "not found" messages, which are emailed to us. Here's an example: > -Original Message- > From: Cron Daemon [mailto:[EMAIL PROTECTED] > Sent: Sunday, 6 August 2006 9:51 PM > To: Database Admin > Subject: Cron <[EMAIL PROTECTED]> /apps/sybase/sysdba/scripts/syblocks.scr -dPROD_COPY -sSERVER2 > /apps/sybase/sysdba/logs/SERVER2/syblocks.err > > /apps/sybase/sysdba/scripts/syblocks.scr: not found It's the same message we get if we schedule something that doesn't exist... But the script DOES exist. And it ran three minutes ago and runs three minutes hence (crontab is 0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 7-22 * * *). Sometimes it's this script. Sometimes it's a different script. It does not happen every night. We have two other servers running the same DBMS/Cygwin/script/crontab config (names are obviously a little different). Some of those other servers deal with bigger databases. The main difference between the servers is that server2 runs Windows 2000, while server1 and server3 run Windows 2003. I've spent some serious time searching Cygwin.com and the web in general but can't seem to find any cases where this happens (i.e., where the script DOES exist and usually runs OK). If there's any more info I can provide to clarify things, please let me know. Sorry that I can't outline how to reproduce this... Wish I could. Has anyone comes across this kind of thing before? Thanks in advance for any assistance anyone can provide. Best Regards, -doug echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' |dc cygcheck.out Description: cygcheck.out -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Re: 1.5.18-1: syslogd and cron message issue (XP/2000).
Hi Rene, Thanks for taking the time to look at this. In the end I have switched to using syslog-ng. That seems to quite nicely address the issue... And provide a whole other bunch of functionality on top. Still, be interested in hearing anything relevant to this that anyone might come up with! Thanks again and best regards, Doug Irwin > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of René Berber > Sent: Sunday, 2 April 2006 14:37 PM > To: cygwin@cygwin.com > Subject: Re: 1.5.18-1: syslogd and cron message issue (XP/2000). > > René Berber wrote: > [snip] > > After compiling and installing the changed version I'm > getting this ugly message: > > > > Apr 1 18:33:31 b kernel: cron[2812]: segfault at 004060C2 > rip 00402986 rsp > > 0022E850 error 6 > > > > But cron is working normally, so it may be just a non > related problem (possibly > > due to using a Cygwin snapshot because I've seen a couple > of these before). > > Take that back, cron is not working. > -- > René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.5.18-1: syslogd and cron message issue (XP/2000).
I have set up /etc/syslog.conf to exclude logging cron messages but still seem to be getting them. In syslogd I have tried the following: *.*;cron.none /var/log/messages *.info;cron.none /var/log/messages *.*;cron.warn /var/log/messages *.info;cron.warn /var/log/messages Several variations thereof and other entirely different entries. I am stopping the cron service, then the syslogd service and starting them in the order syslogd, cron between changes. The crontab simply has * * * * * /usr/bin/date >> /date.log What is getting logged is soemthing along the lines of this: Mar 23 16:52:00 DOUG /USR/SBIN/CRON : PID 4844 : (doug) CMD (/usr/bin/date >> /date.log) I've had no luck filtering it out so far. I have spent several days researching cron and syslogd (both for Cygwin and Linux) on the net. While there's a lot of very useful information I haven't been able to resolve this specific issue. I have attached the standard cygcheck.out, in case that's of any use. Thanks in advance to anyone who is able to make suggestions or give advice. Best regards, Doug Irwin cygcheck.out Description: cygcheck.out -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Problem with syslogd and cron...
Pop. Any thoughts? Anyone? -doug > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Irwin, Doug > Sent: Thursday, 23 March 2006 16:57 PM > To: cygwin@cygwin.com > Subject: Problem with syslogd and cron... > > Hi all, > > I have the following... > > In the crontab: > 1-59 * * * * /echo_the_date.ksh >> /echo_the_date.log > > In /echo_the_date.ksh: > #ksh > /bin/date > > In /etc/syslog.conf: > *.*;cron.none /var/log/messages > > My question is, why do I still get this logged into > /var/log/messages? > Mar 23 16:52:00 DOUG /USR/SBIN/CRON : PID 4844 : (doug) CMD > (/echo_the_date.ksh >> /echo_the_date.log) > > Any thoughts? > > Thanks in advance! > > -doug > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problem with syslogd and cron...
Hi all, I have the following... In the crontab: 1-59 * * * * /echo_the_date.ksh >> /echo_the_date.log In /echo_the_date.ksh: #ksh /bin/date In /etc/syslog.conf: *.*;cron.none /var/log/messages My question is, why do I still get this logged into /var/log/messages? Mar 23 16:52:00 DOUG /USR/SBIN/CRON : PID 4844 : (doug) CMD (/echo_the_date.ksh >> /echo_the_date.log) Any thoughts? Thanks in advance! -doug -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
g77, iargc, getarg don't work for shared linking on Cygwin
win) compiled by GNU C version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65446 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/as.exe -o /cygdrive/c/DOCUME~1/HP_EIG~1/LOCALS~1/Temp/ccMT8siq.o /cygdrive/c/DOCUME~1/HP_EIG~1/LOCALS~1/Temp/ccmrjVaM.s /usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe -Bdynamic --dll-search-prefix=cyg -o tstarg.exe /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. /cygdrive/c/DOCUME~1/HP_EIG~1/LOCALS~1/Temp/ccMT8siq.o libchkargs.dll.a -lfrtbegin -lg2c -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc The last line is the key one so I repeat it in wrapped form for clarity. /usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe -Bdynamic \ --dll-search-prefix=cyg -o tstarg.exe \ /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o \ -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 \ -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 \ -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. \ /cygdrive/c/DOCUME~1/HP_EIG~1/LOCALS~1/Temp/ccMT8siq.o \ libchkargs.dll.a -lfrtbegin \ -lg2c -lgcc -lcygwin -luser32 -lkernel32 \ -ladvapi32 -lshell32 -lgcc Version information: The above results were obtained with a Cygwin version installed as of 2005-11-14. The setup for that environment showed a version of 2.510.2.2. The particular g77 package version used for the above results was gcc-g77-3.4.4-1, but we also got similar (bad) results for gcc-g77-3.3.3-3. Background information: I am one of the developers for PLplot, a scientific plotting package that has been ported to many different Unix and Linux platforms. In our experience, the fortran interface to PLplot has failed command-line parsing (iargc returning -1 and getarg returning blanks) only for the specific combination of shared libraries and the Cygwin platform. I have no direct experience with Cygwin, but I am reporting the above results from one of our PLplot developers who does have access to that platform. Please let me know if there is any other information you require to verify this Cygwin-specific g77 bug. "info g77" specifically mentions that there are unique linking requirements to initialize iargc and getarg properly. In particular, "main" (provided by libg2c) has to be called and libg2c linked correctly. Apparently some aspect of that has not been done correctly for the shared linking case for the g77 Cygwin package. Michael Lemke has recognized this special g77/Cygwin problem before, see his post to this list at http://www.cygwin.com/ml/cygwin/2001-04/msg01313.html. I don't fully understand the linking issues presented there, but the conclusion was "The only way out of this I see is to make libg2c itself a dll." I notice that the package gcc-g77-3.4.4-1 only includes a static version of libg2c so if the above post is correct, that is the source of the problem. For my own Debian stable system, libg2c appears both in static and shared form so there should be no fundamental g77 issues in creating a dll version of libgc2 for the g77 Cygwin package. Furthermore, many other Cygwin packages have dual static and dll libraries as well so I presume it will be straightforward to do the same for the Cygwin/g77 libgc2 library. Thanks in advance for any help with this issue. We will be happy to try any temporary workarounds you propose. Command-line parsing is important for PLplot users (and presumably many other fortran users) because it helps tremendously with ease of use. Of course, one fall back is to restrict our Cygwin platform use to static library builds of PLplot, but that restrics PLplot in a number of other ways (e.g., are python and java interfaces require shared linking). Alan __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bash page fault on Win98SE when running non-Cygwin programs
On Fri, 17 Jun 2005 21:49:39 -0400, Christopher Faylor wrote: >Corinna managed to narrow down the problem with 16-bit programs so there >will be a fix in the next snapshot (and eventually in 1.5.18) but >without specific information about failing 32-bit programs there will be >no fix forthcoming for that problem. Since all of cygwin consists of >32-bit programs, this problem cannot be too prevalent. As it turns out, the 32-bit program that I thought was causing the problem was actually running a a very old EMX (remember EMX?) binary, which was the real culprit. My apologies for the misdirection. >Please try the 2005-Jun-18 snapshot when it eventually shows up at ><http://cygwin.com/snapshots/>. The cygwin1 DLL in this snapshot has fixed the problem, at least for the 16-bit programs I have tried. My thanks to you and Corinna. >In case it isn't obvious, this is a Windows 98/Me bug, not a Cygwin bug. >That hardly matters, since we still have to deal with it, but I thought >I should mention this fact in the interests of full disclosure. A Windows bug? I'm shocked. Shocked! /Irwin Meisels irwinm at rogers dot com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
bash page fault on Win98SE when running non-Cygwin programs
When running some non-Cygwin programs from bash (seems to be mostly a problem with 16-bit programs, but also some 32-bit programs), bash gets an invalid page fault in KERNEL32.DLL and pops up a fault dialog. Also, quitting the fault dialog doesn't work - I just get another page fault dialog each time I quit the current one. I can sometimes start up another bash and kill the first one, but in most cases, the machine locks up and I have to reset it. However, cygcheck works OK (output follows). Has anyone else seen this? /Irwin Meisels irwinm at rogers dot com Cygwin Configuration Diagnostics Current System Time: Thu Jun 09 14:52:35 2005 Windows 98 SE Ver 4.10 Build Path: C:\cygwin\bin C:\cygwin\bin c:\usr\games\bin C:\cygwin\usr\local\bin c:\WINDOWS c:\WINDOWS\COMMAND c:\USR\BIN c:\PROGRAM FILES\EXECUTIVE SOFTWARE\DISKEEPERLITE\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 500(irwin) GID: 544(unknown) 544(unknown) Output from C:\cygwin\bin\id.exe (ntsec) UID: 500(irwin) GID: 544(unknown) 544(unknown) SysDir: C:\WINDOWS\SYSTEM WinDir: C:\WINDOWS USER = `irwin' PWD = `/usr/games/foo' HOME = `/c/irwin' MAKE_MODE = `unix' MANPATH = `:/usr/ssl/man' TERM = `cygwin' CMDLINE = `bash --login -i' OLDPWD = `/c/irwin' TEMP = `/c/WINDOWS/TEMP' W = `/cygdrive/g/levels' PS1 = `% ' !C: = `C:\cygwin\bin' WINBOOTDIR = `C:\WINDOWS' SHLVL = `1' BLASTER = `A220 I5 D1 H7 P300 T6' COMSPEC = `C:\WINDOWS\COMMAND.COM' PROMPT = `$p$g' LESS = `cMifnR' TMP = `/c/WINDOWS/TEMP' _ = `/usr/bin/cygcheck' SYSTEMROOT = `C:\WINDOWS' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\Software\Cygnus Solutions HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/games (default) = `c:\usr\games' flags = 0x000a HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/c (default) = `c:' flags = 0x000a HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/h (default) = `h:' flags = 0x000a HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/f (default) = `f:' flags = 0x000a HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd FAT32 8197Mb 70% CPUN d: hd FAT32 1503Mb 87% CPUN e: hd FAT988Mb 35% CPUN f: hd FAT 1019Mb 98% CPUN g: hd FAT32 540Mb 1% CPUN h: cd CDFS 634Mb 100%CDROM i: net NTFS 10076Mb 66% CP CSPAirwin j: net NTFS 56342Mb 82% CP CSPAmnt1 c:\usr\games /usr/games system binmode c: /c system binmode h: /h system binmode f: /f system binmode C:\cygwin / system binmode C:\cygwin/bin /usr/binsystem binmode C:\cygwin/lib /usr/libsystem binmode . /cygdrive system binmode,cygdrive Found: C:\cygwin\bin\awk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cpp.exe Found: C:\cygwin\bin\find.exe Found: c:\WINDOWS\COMMAND\find.exe Warning: C:\cygwin\bin\find.exe hides c:\WINDOWS\COMMAND\find.exe Found: C:\cygwin\bin\gcc.exe Found: C:\cygwin\bin\gdb.exe Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\mv.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe Found: c:\USR\BIN\tar.exe Warning: C:\cygwin\bin\tar.exe hides c:\USR\BIN\tar.exe 7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll - os=4.0 img=1.0 sys=4.0 "cygcrypt-0.dll" v0.0 ts=2003/10/19 3:57 21k 2001/06/20 C:\cygwin\bin\cygintl.dll - os=4.0 img=1.0 sys=4.0 "cygintl.dll" v0.0 ts=2001/6/20 13:09 22k 2001/12/13 C:\cygwin\bin\cygintl-1.dll - os=4.0 img=1.0 sys=4.0 "cygintl-1.dll" v0.0
Hey there...you ready yet....brumidi compress gingham vought vague dodecahedra
Cygwin, extended warranty coverage for your vehichle. Save-up to 60% on extended warranty coverage starting today. You get 24-Hour Roadside Assistance, Car Rental Benefits, Trip Interruption Benefits, Extended Towing Benefits http://viewvista2112.net/autosite -- If this message has reached you in error, we apologize. Please see address below to have your address deleted from further promotions...thanks http://viewpubliconline.net/dev/rv.php clear
