Condor_compile windows

This includes machine state, as well as the state of jobs submitted by users. This is the simplest situation, because the only change needed is to turn on the logging of historical information. The following sections describe how to configure a machine to run a HTCondorView server and to configure a pool to send updates to it. Here are brief explanations of the entries that must be customized:. The directory where historical data will be stored. This directory must be writable by whatever user the HTCondorView collector is running as usually the user condor.

There are a few problems putting these files into either of those directories. A boolean value that determines if the HTCondorView collector should store the historical information. It is False by default, and must be specified as True in the local configuration file to enable data collection. This is the same user that owns the CollectorLog file in the log directory. The user is usually condor. In this example, the HTCondorView collector uses port The full host name is optionally followed by a colon and port number.

This is only necessary if the HTCondorView collector is configured to use a port number other than the default. It is acceptable to place it in the global configuration file. The HTCondorView collector will ignore this setting as it should as it notices that it is being asked to forward ClassAds to itself. A query to the HTCondorView collector will verify that it is working. A query example:. HTCondor jobs are formed from executables that are compiled to execute on specific platforms.

This in turn restricts the machines within an HTCondor pool where a job may be executed. This allows Windows executables to run on a Linux machine, and Linux executables to run on a Windows machine. In older versions of HTCondor, other parts of the system were also referred to as virtual machines, but in all cases, those are now known as slots. A virtual machine here describes the environment in which the outside operating system called the host emulates an inner operating system called the inner virtual machine , such that an executable appears to run directly on the inner virtual machine.

In other parts of HTCondor, a slot formerly known as virtual machine refers to the multiple cores of a multi-core machine. Also, be careful not to confuse the virtual machines discussed here with the Java Virtual Machine JVM referenced in other parts of this manual.

Targeting an HTCondor job to run on an inner virtual machine is also different than using the vm universe. The vm universe lands and starts up a virtual machine instance, which is the HTCondor job, on an execute machine. HTCondor has the flexibility to run a job on either the host or the inner virtual machine, hence two platforms appear to exist on a single machine.

Since two platforms are an illusion, HTCondor understands the illusion, allowing an HTCondor job to be executed on only one at a time. HTCondor must be separately installed, separately configured, and separately running on both the host and the inner virtual machine. This specifies host names or IP addresses of all inner virtual machines running on this host. An example configuration on the host machine:.

This specifies the host for the inner virtual machine. An example configuration on an inner virtual machine:. Given this configuration, as well as communication between HTCondor daemons running on the host and on the inner virtual machine, the policy for when jobs may execute is set by HTCondor.

The inner virtual machine is further provided with a new syntax for referring to the machine ClassAd attributes of its host. The START policy on the inner virtual machine ought to use this syntax to avoid starting jobs when its host is too busy processing other items. MPI applications are a common use for the dedicated scheduler, but parallel applications which do not require MPI can also be run with the dedicated scheduler.

We recommend that you select a single machine within an HTCondor pool to act as the dedicated scheduler. This becomes the machine from upon which all users submit their parallel universe jobs.

The perfect choice for the dedicated scheduler is the single, front-end machine for a dedicated cluster of compute nodes. For the pool without an obvious choice for a submit machine, choose a machine that all users can log into, as well as one that is likely to be up and running all the time.

See Directories for more information. Each execute machine may have its own policy for the execution of jobs, as set by configuration. Each machine with aspects of its configuration that are dedicated identifies the dedicated scheduler. And, the ClassAd representing a job to be executed on one or more of these dedicated machines includes an identifying attribute.

Each execute machine defines the configuration variable DedicatedScheduler , which identifies the dedicated scheduler it is managed by. The local configuration file contains a modified form of. If running personal HTCondor, the name of the scheduler includes the user name it was started as, so the configuration appears as:.

All dedicated execute machines must have policy expressions which allow for jobs to always run, but not be preempted. The resource must also be configured to prefer jobs from the dedicated scheduler over all other jobs.

Therefore, configuration gives the dedicated scheduler of choice the highest rank. It is worth noting that HTCondor puts no other requirements on a resource for it to be considered dedicated.

Job ClassAds from the dedicated scheduler contain the attribute Scheduler. The attribute is defined by a string of the form. Different resources in the pool may have different dedicated policies by varying the local configuration.

One possible scenario for the use of a dedicated resource is to only run jobs that require the dedicated resource. To enact this policy, configure the following expressions:. This prevents other jobs from preempting it based on user priorities. While the first example works nicely for jobs requiring dedicated resources, it can lead to poor utilization of the dedicated machines. A more sophisticated strategy allows the machines to run other jobs, when no jobs that require dedicated resources exist.

The machine is configured to prefer jobs that require dedicated resources, but not prevent others from running. To implement this, configure the machine as a dedicated resource as above, modifying only the START expression:. A third policy example allows all jobs. The machine does not preempt jobs that must run on dedicated resources, while it may preempt other jobs as defined by policy.

So, the default pool policy is used for starting and stopping jobs, while jobs that require a dedicated resource always start and are not preempted. Locally, the configuration is modified to this hybrid policy by adding a second case. RANK is a floating point value, so there is no harm in assigning a very large value.

The dedicated scheduler can be configured to preempt running parallel universe jobs in favor of higher priority parallel universe jobs. By default, the dedicated scheduler will never preempt running parallel universe jobs. These variables have no default value, so if either are not defined, preemption will never occur. Note that preempting one node of a running parallel universe job requires killing the entire job on all of its nodes.

So, when preemption occurs, it may end up freeing more machines than are needed for the new job. Also, as HTCondor does not produce checkpoints for parallel universe jobs, preempted jobs will be re-run, starting again from the beginning.

Thus, the administrator should be careful when enabling preemption of these dedicated resources. Enable dedicated preemption with the configuration:. In this example, preemption is enabled by user-defined job priority. If a set of machines is running a job at user priority 5, and the user submits a new job at user priority 10, the running job will be preempted for the new job.

The old job is put back in the queue, and will begin again from the beginning when assigned to a newly acquired set of machines. In some parallel environments, machines are divided into groups, and jobs should not cross groups of machines. That is, all the nodes of a parallel job should be allocated to machines within the same group. The most common example is a pool of machine using InfiniBand switches. For example, each switch might connect 16 machines, and a pool might have machines on 10 switches.

If the InfiniBand switches are not routed to each other, each job must run on machines connected to the same switch. The submit description file for a parallel universe job which must not cross group boundaries contains. These jobs are considered the lowest possible priority, but when machines would otherwise be idle, the resources can be put to good use. The rest of this section provides an overview of how backfill jobs work in HTCondor, details for configuring the policy for when backfill jobs are started or killed, and details on how to configure HTCondor to spawn the BOINC client to perform the work.

Machines in this state can be configured to enter the Backfill state, which allows the resource to attempt a background computation to keep itself busy until other work arrives either a user returning to use the machine interactively, or a normal HTCondor job.

This section briefly lists these expressions. A boolean value to determine if any backfill functionality should be used. The default value is False. A string that defines what backfill system to use for spawning and managing backfill computations. A boolean expression to control if an HTCondor resource should start a backfill client. A boolean expression that is evaluated whenever an HTCondor resource is in the Backfill state.

A value of True indicates the machine should immediately kill the currently running backfill client and any other spawned processes, and return to the Owner state. A detailed explanation of this system is beyond the scope of this manual. BOINC grew out of the relatively famous SETI home computation, where volunteers installed special client software, in the form of a screen saver, that contacted a centralized server to download work units.

However, instead of being tied to the specific radio telescope application, BOINC is a generic infrastructure by which many different kinds of scientific computations can be solved. However, the BOINC installation on any given machine must be configured so that it knows what computations to work for instead of always working on a hard coded computation. A given BOINC client can be configured to donate all of its cycles to a single project, or to split the cycles between projects so that, on average, the desired percentage of the computational power is allocated to each project.

The BOINC software downloads the appropriate platform-specific application binary and some work units from the central server for each project. BOINC participants must register at the centralized server for each project they wish to donate cycles to.

The process produces a unique identifier so that the work performed by a given client can be credited to a specific user. BOINC keeps track of the work units completed by each user, so that users providing the most cycles get the highest rankings, and therefore, bragging rights.

Because BOINC already handles the problems of distributing the application binaries for each scientific computation, the work units, and compiling the results, it is a perfect system for managing backfill computations in HTCondor. In HTCondor Version 9. Additionally, a local directory on each machine should be created where the BOINC system can write files it needs. This is the same restriction as placed on the spool or execute directories used by HTCondor.

The details of this process vary from project to project. Each of these variables is described as either a required or an optional configuration variable. This variable is only used if the HTCondor daemons are running as root. For example:. If this variable is not defined, stdout will be discarded.

If this macro is not defined, stderr will be discarded. If the HTCondor daemons reading this configuration are running as root, an additional variable must be defined:. A better choice would probably be to create a separate user account just for running BOINC jobs, so that the local BOINC installation is not writable by other processes running as nobody. Any files with a name that matches this convention will be read and processed. The contents of the file define the project URL and the authentication key.

The format is:. These account files can be copied to the local BOINC directory on all machines in an HTCondor pool, so administrators can either distribute them manually, or use symbolic links to point to a shared file system. Using this method gives all users access to the executables. During the installation process. Optionally, if you encounter unusual problems with re building LALSuite, you may want to try cleaning the git repository first.

NOTE : this command removes all files that are not committed, so please take case in using this - if in doubt, don't use it! The command is git clean -dxfq. If you do not have version 2. The advanced user may wish to configure and compile LALSuite in a custom manner. Here are some common things you may wish to do.

This can be done by configuring LALSuite with the additional configure flag --enable-swig-python as follows:. When using gcc or clang , LALSuite is built by default using optimizations that interfere with debugging the programs with debuggers e. If you plan to be running programs within a debugger, it is helpful to turn off the optimization. This can be achieved by configuring LALSuite as follows:.

When using gcc or clang , LALSuite can be built with yet more optimization than is enabled by default. For testing or development you may wish to install a production version of LALSuite well as a development version. The safest way to do this is to create separate directories in which to configure each version.

First it is important to clean up any previous configuration of LAL by running make distclean in the source directory:. Create another directory, in the LALSuite source directory, for the development version and configure in the same way:. Except for those items listed above, most everything works the same way in HTCondor as it does in the Unix release. This release is based on the HTCondor Version 9. For instance, all of the following work in HTCondor:.

The ability to customize job policy using ClassAds. HTCondor for Windows can run jobs at a lower operating system priority level. HTCondor correctly manages jobs which create multiple processes.

For instance, if an HTCondor job spawns multiple processes and HTCondor needs to kill the job, all processes created by the job will be terminated. Information specified by the user in the set up program is stored in the system registry.

The set up program can update a current installation with a new release using a minimal amount of effort. In order for HTCondor to operate properly, it must at times be able to act on behalf of users who submit jobs.

On Unix systems, arbitrarily changing what user HTCondor performs its actions as is easily done when HTCondor is started with root privileges. Passwords managed by HTCondor are encrypted and stored in a secure location within the Windows registry. When HTCondor needs to perform an action as or on behalf of a particular user, it uses the securely stored password to do so.

This implies that a password is stored for every user that will submit jobs from the Windows submit machine. By default, HTCondor executes jobs on Windows using dedicated run accounts that have minimal access rights and privileges, and which are recreated for each new job. As an alternative, HTCondor can be configured to allow users to run jobs using their Windows login accounts. This may be useful if jobs need access to files on a network share, or to other resources that are not available to the low-privilege run account.

A second set of configuration variables specify security for the communication among HTCondor daemons.

These variables must be set for all machines in the pool. The example above can be modified to meet the needs of your pool, providing the following conditions are met:. The chosen pool password must be stored identically for each machine. If the administrative account is shared across all machines, that is if it is a domain account or has the same password on all machines, logging in separately to each machine in the pool can be avoided.

Instead, the pool password can be securely pushed out for each Windows machine using a command of the form. Once the pool password is distributed, but before submitting jobs, all machines must reevaluate their configuration, so execute. To see whether this test worked for each machine in the pool, run the command.

Any rows in the output with the UNDEF string indicate machines where secure communication is not working properly. Verify that the pool password is stored correctly on these machines. Third party tools such as PsExec can be used to accomplish this.

In case the pool is remote and no initial communication can be established due to strong security, the pool password may have to be set using the above method and following command:. It also may be useful when the job requires an application, and the application requires registry access.

For security reasons, the profile is cleaned before a subsequent job which uses the dedicated run account begins. This ensures that malicious jobs cannot discover what any previous job has done, nor sabotage the registry for future jobs.

It also ensures the next job has a fresh registry hive. HTCondor has added support for scripting jobs on Windows. Previously, HTCondor jobs on Windows were limited to executables or batch files. Without a file name extension, the file will be treated as it has been in the past: as a Windows executable. An example that does not require administrative intervention are Perl scripts using ActivePerl.