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.
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
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! :)