Slashdot Mirror
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?"
We have been using cygwin dll to run RSYNC on Windows servers without any issues.
Consensus is good, but informed dictatorship is better
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
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.
Services For Unix is now free.
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.
Causation can cause correlation
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
Under Windows XP only, cygwin dll has a problem with locking threads after they have terminated.
;do
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))
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
I already made a post in a thread about SFU that was looking like (disclaimer: i love 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:
<Job ID="MyJobID">
<script language=PerlScript>
#
</script
-- search the web
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 .
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.
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.