[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] Condor 7.2.*, VC90 manifest, and .NET 3


     I have been having issues with installing the new 7.2.3 version; well in fact there have been a few problems with updating to newer versions on my own XP pc. It appears that Sophos really does not like certain files, and after installation, most of the executables in condor/bin folder would just disappear. In fact this has just happened again, leaving two files – condor_c-gahp.exe wghich I have authorised in Sophos as not being suspicious. Allegedly is suffers from Sus/Behav-115 error as being a suspect file. Each time I allow a file as authorised, so my only way around this is to turn off Sophos for a moment.

  As soon as I restart the Sophos virus checker, it puts nearly all the condor executables into the naughty bin. This is not a general issue around our Labs builds.






From: condor-users-bounces@xxxxxxxxxxx [mailto:condor-users-bounces@xxxxxxxxxxx] On Behalf Of Greg.Hitchen@xxxxxxxx
Sent: 22 July 2009 09:31
To: condor-users@xxxxxxxxxxx
Subject: [Condor-users] Condor 7.2.*, VC90 manifest, and .NET 3


Hi All


Just a few observations we have made over the last few days that maybe

some of the condor team could comment on.


We have recently upgraded our windows execute nodes from 7.0.5 toco

7.2.3. We install from the Central Managers (linux with samba) using the zip file

download and DOS batch scripts. i.e. copy condor files to execute node,

install the condor service, make a few registry entries, and start condor.

We also install a scheduled task that runs every day to check the file

server for updated binaries and/or config files.


Am I right in thinking that the 7.2.* series is the first using VS2008 and

therefore needs the VC90 type manifest file?


Anyway back to what we found. On some PCs our install would run OK

but the "net start condor" would fail with errors in the System Event Log

referring to a syntax error on line 4 of the Microsoft.VC90.CRT.manifest

file. If we tried an install from the MSI download then no errors and condor

would run.


We tracked down the failures to machines that did NOT have

Microsoft .NET Framework 3.0 or above installed (i.e. they had 2.0 or

less). This corresponded to whether or not the PCs had a folder in the

C:\WINDOWS\WinSxS directory of the form



Using the MSI condor install on a PC without .NET 3.0 would also create

such a folder (and remove it when uninstalling condor). This could also

be seen in the internal structure of the MSI file when using the /a administrative

install option to just extract files and not install condor. Included in the

MSI file is a windows\system32 and windows\winsxs structure.


Googling and reading some info about these "side-by-side" manifest

files it seemed like the manifest could either be in the .exe itself or as

an external .manifest file (which seems how it was intended with the

condor zip file). Using a hex editor on the condor exes showed just a

generic reference to a manifest, and nothing specific about the VC files

msvcm90.dll, msvcp90.dll, msvcr90.dll. It seemed like the external

manifest file in the condor bin folder "should" make things work OK,

along with the 3 dlls mentioned in there as well. It seems like it doesn't.

It's like the condor exe's are only looking for system installs of the manifest

and NOT looking in the same folder as the exe's?


If we installed the latest .NET 3.5 then a WinSxS folder with VC90.CRT

would be created and our batch install would work and start condor OK.

In fact we could delete the .manifest and 3 dlls mentioned in the

condor\bin directory and condor would still work OK.


Fortunately less than 10% of PCs in our organisation currently don't

have .NET 3.0 or better installed so it's not a show stopper, but we

are still interested in comments/suggestions/explanations.


It would seem that using the zip file install method will NOT allow

condor to run unless the latest .NET update is installed (or another

application install has installed .NET or the appropriate folder containing

the necessary dlls in the WinSxS directory.


If you've read this far, thanks! :)


Even better if you can shed some light on this! :)






Greg Hitchen                                                                         greg.hitchen@xxxxxxxx
CSIRO Exploration and Mining                                         phone: +61 8 6436 8663
Australian Resources Research Centre (ARRC)             fax:       +61 8 6436 8555
Postal address:                                                                     mob:          0407 952 748
PO Box 1130, Bentley WA 6102, Australia
Street Address:
26 Dick Perry Avenue, Kensington WA 6151