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

Comments

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.

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:What are you doing with it?

[Atzanteol]

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.

I'm not the original questioner, but may be able to give one plausible reason. Many slashdotters seem to have trouble grappling with this idea (Why can't your client just run Linux?). Typically a given client has existing infrastructure and admins. If they have lotsa Windows guys, they'll want a Windows box so they can admin it when you're done.

I work aa a consultant, and many clients will request an operating system that matches their existing systems. Unless you can really convince them otherwise, they'll look elsewhere if you don't come up with a solution on their platform.

SFU?

[m0rph3us0]

Services For Unix is now free.

cygwin terminal

[timothv]

If you use cygwin, make sure to get a better terminal for it. Puttycyg uses Putty's great terminal emulator for cygwin, and it works rather well.

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.

Re:Just Rembember

[I_Love_Pocky!]

That's not flamebait, that was a failed attempt at humor...

Much better flamebait would be:

Cygwin is known to crash regularly, but not any more regularly than any other application running under Windows. Anyone who would run Windows on a production server is asking for trouble. Clearly your best course of action is to forget this Cygwin idea, and spend your time and effort changing people's minds about this whole Windows garbage.

See, I can do a real flamebait!

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 in a thread about SFU 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 (of course), Mingw, GNU utilities for Win32
• 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 (free) or PE Explorer ($$$). 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 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

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/