Cygwin in a Production Environment?

not-so-anonymous Anonymous Coward asks: "I'm working for a company that does all of its programming and script development in a Unix environment (90% of our work is either Bash or Perl scripts that communicate with an Oracle database). We've recently gotten a new customer and for reasons beyond our control, the server must be a Windows box. Since we want to reuse our existing scripts that we've spent a considerable amount of time developing, we're looking into Cygwin as an option. Has anyone run Cygwin in a production server environment for any extended period of time? If so, what were your experiences with it?"

using cygwin to run RSYNC

[stonebeat.org]

We have been using cygwin dll to run RSYNC on Windows servers without any issues.

PostgreSQL on cygwin

[barries]

cygwin is a really nice emulation layer, but it is an emulation layer and is not 24x7 ready. The timekeeping and IPC mechnisms aren't fully reliable for production-ready use, IMHO. It is amazing for what it does.

We've been running several production PostgreSQL-on-cygwin servers and have been experiencing random corruption and poor timekeeping. There's a bug (hopefully fixed now) in cygwin timekeeping that causes a rollover after 49 days of uptime. PostgreSQL on cygwin also experiences odd table and index corruption problems that I've never seen with it on Linux/FreeBSD.

We're cutting to Oracle for business reasons, or we'd switch to the newly free Win32 PostgreSQL ASAP.

Have you considered MS' Services for Unix? We've not used it, but I'd be interested in hearing about how well it works.

- Barrie

What are you doing with it?

[Eneff]

If you're just running shell scripts, you're probably going to be able to make the transition with a minimum of effort. Cygwin is a bit slow, though. It's good for most purposes, but don't depend on it to do more than administrative tasks.

At least, in my experience. I use it for development and it makes my life livable.

SFU?

[m0rph3us0]

Services For Unix is now free.

Re:What are you doing with it?

[MBCook]

There are other things to be aware of too. Cygwin is nice (I use it myself on my personal laptop) but you should look into the tools you want on Windows. Yes you can get bash and perl, but there are limitations to considder. For example, IIRC, the fork() call on Windows is VERY slow for some reason that I don't remember.

If the Windows environment becomes that much of a problem (and don't forget to try, as another poster suggested, things like Services For Unix (SFU)), set up a demo of the two things side by side to show the customer just how much more efficent running it on the Unix of your choice is than making it run on Windows. That might convince them if it comes to that.

Speaking of which, I would love to know WHY the client has to have Windows. Maybe there is something there that you can deal with that you don't realize.

Re:cygwin terminal

[algae]

Cygwin also comes with a win32 native (ie, doesn't need Cygwin/X) rxvt terminal that's far far better that the default cmd.exe style cygwin terminal. You can also incorporate ssh-agent if you remote into lots of machines. Here's my startup shortcut:

C:\cygwin\bin\rxvt.exe -e ssh-agent bash --login -i

IIRC, rxvt isn't installed by default, but it's available under 'shells' when you run the cygwin setup.

Larger thoughts...

[ComputerSlicer23]

I think Cygwin will work just fine. I've known a number of people who used it for extended periods of time. It'd be more helpful to know precisely what it is you are planning on doing to know for sure if it will work.

However, in a larger context:

Uhhh, you are taking on a customer for whom you have no tools and no infrastructure for? Who doesn't fit your current model, and fundamentally doesn't fit how you do business? Unless you are laying the ground work to bring in lots more revenue at a lower cost in the future, this might be stupid to do.

Now, a company has to grow, but remember the princepal that says, "Not all customers are profitable". You don't want customers who don't make you money. I remember a story about an advertising company that eliminated 70% of their existing customers and have revenue plumet, but their profits jumped by 30% (as a dollar value, not as a percentage of revenue, they made 2.5Mil instead of 1.5Mil in profit, I believe revenue went from 30Mil to 12Mil).

I know on more then on occasion, the smartest thing the guys in charge where I work is to fire customers. Some customers aren't worth the time or the trouble to deliver service to.

This isn't an anti-Window post, it's merely a matter of considering weather or not this is an area you are planning to expand into, or if this is a one-off, non-scalable solution for a single customer just to get the business.

We run into this quite often, around it's driven by sales people whose sales goals are about bringing in revenue, not bringing in profit. If it costs us $1000 in to bring in $500 in revenue, that's a stupid business proposition. If it's a big chunk of revenue, and you can build it while making money go for it.

Kirby

Cygwin Threading problem

[a11]

Under Windows XP only, cygwin dll has a problem with locking threads after they have terminated.

If you spawn a bunch of processes (such as in a common loop), each of those will use up at least 1 TID. Any call to create new threads made through the cygwin dll makes that TID non-reusable in windows, and will eventually crash your box.

Shell Script that crashes your box:
integer i=70000
while ((i -= 1)) ;do
echo hello\\nworld | cat|cat|cat|grep h >&- #spawn some processes
done

While cygwin has its problems, I've had many more w/ Services for UNIX

24x7

[sICE]

Hi,
I already made a post [slashdot.org] in a thread [slashdot.org] about SFU [microsoft.com] that was looking like (disclaimer: i love cygwin):

1) WSFU is faster (IO/API/...)
2) WSFU is better integrated with win32 architecture (OLE/ODBC/...)
3) WSFU make a lot of things easier than cygwin with windows

BUT, i wouldnt trade cygwin for it, note that i have both installed here. I just isolated what i needed from WSFU and was better than cygwin and added them last in my path. I dont have any preferences, but cygwin is waaay more complete, and you have the +/- the same versions of the application that runs on linux. Same config files work fine, same behaviours (which isnt the case with WSFU), etc.

For me, WSFU is just a little + to cygwin.

Now bout your particular problem (prod env, 24x7), I've experienced very few problems running CygWin in such an environment. I use it since at least 5 years (I remember downloading it at 56k, so it's probably more), but there's some things you need to be aware with cygwin:

• Versions of the applications you run: they often differs from what you're used to. Sometimes I ended up with different settings between solaris, linux, win32, etc. This is generally fixed with a recompile of the common denominator version, possibly the latest one.
• Performances: As you probably noticed from the other posts, cygwin is an emulation layer. It is slow. And I really mean slow. Something you usually do in nunux in a few seconds might take a few minutes on win32 depending on how it is coded. Forks and threads are really badly implemented. Yet nobody else did better.
• Alternatives: Frequently natives win32 programs are faster, better, or both. Have a look on google after alternatives (adding +win32 +unix, and +free if money is a problem). It will save you some time. Maintaining several branches of your scripts might be a good investment, if you factor out the common base, and manage to get them do what they should on different platforms while compiling/installing (and anyway if you start nunux/win32, you might as well just do that, you'll end up with the pot). Though it perhaps require another employee, it's worth it. For cygwin alternatives I'd recommend the SFU [microsoft.com] (of course), Mingw [mingw.org], GNU utilities for Win32 [sourceforge.net]
• The DLL Nightmare (Take II): If you dont need too much apps (.exe) relative to cygwin it could be good to just use those. Compile the stuff you want in cygwin, and modify the $INSTALL path, so you can just take that to another machine. The DLL hell here is that you'll probably not only need the cygwin dll but some more... If you have quickview installed on your machine, you can see what DLLs a program use in its Import Section (from the PE header). Else i would recommend OllyDBG [t-online.de] (free) or PE Explorer [heaventools.com] ($$$). Both can lists what DLLs an app use, just find them, and copy them in the folder, et voila! you can use it elsewhere.
• Perl: DO NOT USE the cygwin version of perl, unless you have a really good reason to do so. Instead use Active Perl [activestate.com] It's damn faster. If it's called from bash then put #!/c:/perl/bin/perl5 -- or where ever you installed it). Some other things to know about active state perl on win32:
  • Hiding the cmd.exe box when running a script: Instead of putting '.pl' at the end of your scripts, try '.wsf' and have a look at the examples given by ActiveState:
    <Job ID="MyJobID">
    <script language=PerlScript>
    # ... your code here ...
    </script

Unix for Windows from ATT

[caesar79]

If cygwin is not upto production standard, then maybe you can evaluate Unix for Windows - it was originally an ATT labs product - but now seems to have been sold. You can download a non-commercial version for free (as in beer). Check it out at http://www.research.att.com/sw/tools/uwin [att.com].

GPL Warning

[Eil]

If you can get past the horrible, horrible installation, Cygwin is a pretty nifty piece of kit.

However, in a commercial environment there is one tremendous downfall to using Cygwin. The Cygwin.dll library that does all of the translation from Unix to Windows system calls is under the GPL. NOT the LGPL. This means that if you write an application and build it against the Cygwin libraries and plan to distribute it, the only license you can legally put your software under is the GPL. This is the only case of the "virulent" nature of the GPL that we've witnessed firsthand and I must say it is a particularly nasty one.

For more info:
read the FAQ [cygwin.com].

Re:using cygwin to run RSYNC

[n9hmg]

Don't get me wrong, rsync rulz. I haven't used it myself, but I've heard cwrsync solves the remaining problems.
Cygwin will do much more, though - apache, postgresql(probably mysql too, but I haven't seen it), etc. - almost any unix app you can get the source for, you can compile(and use) in Cygwin.
I keep getting in jobs that require the use of windows. I'm a unix guy. I retain my sanity by doing everything in cygwin. I'm wasting an exceed license right now because while they can require that I have it installed, I greatly prefer cygwin X and fvwm. I build most of my applications in shell or perl, sometimes with fakes of the unix apps they'll run against, to feed in the inputs or take the outputs.

Specifically, you say your product is mostly Perl and bash? You write in two of the most-portable languages of all, and you're worried? Jeez, man, it's RedHat! I assume you're using db::oracle or some such perl module for your fancy work. Your porting is likely to be no porting at all, i.e., you'll probably be able to scp your stuff in and just run it without further work. The ease of acquisition and configuration of the platform is such that determining details is honestly trivial. Install, run, try your apps, tell us what you find out.

Re:The Cygwin vs MinGW thing

[cgf]

Msys is just an older version of cygwin with some additions that purportedly make it easier to use with mingw.

The last time I checked, msys was slower than cygwin.

Re:What are you doing with it?

[cowbutt]

For example, IIRC, the fork() call on Windows is VERY slow for some reason that I don't remember.

UNIX is designed in such a way that process creation is very cheap, therefore lots of UNIX programs use fork to achieve parallelism. OTOH, Windows is designed around the threading model, so no particular attention has been made to make process creation similarly cheap.

More info at this link [robelle.com] and this one [geeksalad.org].

--

Re:GPL Warning

[Anonymous Coward]

IF you want to develop non-open source commercial software with cygwin then purchase a license. Red Hat sells them, see http://www.redhat.com/software/cygwin/