This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Perl failure

I ran just the core part of the script,  it forks off a number of
rsync's for every machine it is checking.  When the panic happens it
kills of the parent,  but the remaining children finish successfully.

 I then brought back up the previous server that I had used (win2k
machine with cyg1.5.5).  The script ran through successfully on the
older machine.  I had to make minor changes to my Perl script:

1: I use ping to check if the machines are alive,  the older ping
response needs to be parsed differently

2: I use rsync for version control,  Rsync (old and new)  will hang
about 5% of the time on the old cygwin and about 0.5% of the time on the
new, often to the point where cygwin's kill won't kill it.  In these
cases I also call /c/windows/system32/taskkill on XP,  but I need to
call windows kill on win2k.

3: All the data that is version controlled is kept on the new cyg 1.5.19
XP server,  so I had to change the data location from a local drive on
the newer machine to a network drive on the newer machine.  

So I'm at the point where the old server works with new code (  though
it is very slow and rsync is very unreliable on it)  and a new machine
which runs great until it craps out after 1.5 hours.

I hope the above helps

Bruce D.

-----Original Message-----
From: [] On Behalf
Of Yitzchak Scott-Thoennes
Sent: Thursday, July 13, 2006 8:53 AM
Subject: Re: Perl failure

On Wed, Jul 12, 2006 at 05:08:43PM -0700, Bruce Dobrin wrote:
> Hi,
> I have a server that has been doing back end maintenance using perl on

> cygwin for 6 years now.  I recently upgraded from win2k and cyg1.5.9 
> to XP sp3 and cyg1.5.19 (to be fare,  I also cleaned up the perl code 
> a bit).  The script checks versioning and build info on about 600+ 
> windows systems.  Since the upgrade,  it gets thru about 500 of them (

> almost exactly 2 hours)  and then:
> panic: MUTEX_LOCK (45) [util.c:2266] at 
> /c/dist_and_install_files/source/dist2/ line 24, 
> <HOSTFILE> line 277.
> panic: MUTEX_LOCK (45) [op.c:354], <HOSTFILE> line 277.

This indicates EDEADLK being returned from posix_mutex_lock.
> It hits a slightly different time and position in the list each time, 
> but always after approximately 2 hours.  I found a few old mails 
> suggesting rebaseall,  which I ran to no effect.  The system pretty 
> much runs nothing but this. I've been running a version of this script

> since
> cyg1.3.9 and never had a problem like this one.
> Any suggestions?

Can you revert one or more of the many things you changed, and see if it
makes a difference?

Unsubscribe info:
Problem reports:

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]