Mailing List Archives
Authenticated access
|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Condor-users] Issue introduced in 7.2.3 (Windows) and transfer_output_remaps
- Date: Wed, 20 May 2009 15:46:57 -0700
- From: Andrew Cunningham <andrewc@xxxxxxx>
- Subject: [Condor-users] Issue introduced in 7.2.3 (Windows) and transfer_output_remaps
We are running a Windows only grid of 4 machines and we are seeing a very strange problem with 7.2.3 that seems to have been introduced since 6.9.3 ( we upgraded all machines to 7.2.3)
Our vanilla universe .sub file has a line
transfer_output_remaps = "VA14.va1=VA14_$$(arch)_$$(opsys).va1"
This worked as expected under 6.9.3
Now under 7.2.3 when we submit the job it is correctly matched with a machine, but never goes into the run state, it is rejected for 'unknown reasons' and stays in the idle state.
condor_q -analyze
The response is one I have never seen....
-- Failed to fetch ads from: <192.168.0.11:2638> : CARDIFF
CEDAR:6001:Failed to connect to <192.168.0.11:2638>
( The machine CARDIFF is the machine that submitted the job)
If we then change the line to , say,
transfer_output_remaps = "VA14.va1=VA14_INTEL_WINNT51.va1"
or remove transfer_output_remaps completely
and submit the job again, the job immediate is matched , goes into the run state, and completes as expected.
(condor_q -analyze does not report any errors, as expected)
This is 100% reproducible, and as I said, has only emerged as a problem after upgrading all machines to 7.2.3. I can only conclude some strange bug introduced with Macro substitution.
Andrew