######################################################################
##
##  condor_config
##
##  This is the global configuration file for condor.  Any settings
##  made here may potentially be overridden in the local configuration
##  file.  KEEP THAT IN MIND!  To double-check that a variable is
##  getting set from the configuration file that you expect, use
##  condor_config_val -v <variable name>
##
##  The file is divided into four main parts:
##  Part 1:  Settings you likely want to customize 
##  Part 2:  Settings you may want to customize
##  Part 3:  Settings that control the policy of when condor will
##           start and stop jobs on your machines
##  Part 4:  Settings you should probably leave alone (unless you
##  know what you're doing)
##
##  Please read the INSTALL file (or the Install chapter in the
##  Condor Administrator's Manual) for detailed explanations of the 
##  various settings in here and possible ways to configure your
##  pool. 
##
##  Unless otherwise specified, settings that are commented out show
##  the defaults that are used if you don't define a value.  Settings
##  that are defined here MUST BE DEFINED since they have no default
##  value.
##
##  Unless otherwise indicated, all settings which specify a time are
##  defined in seconds.
##
######################################################################

######################################################################
######################################################################
##
##  ######                                     #
##  #     #    ##    #####    #####           ##
##  #     #   #  #   #    #     #            # #
##  ######   #    #  #    #     #              #
##  #        ######  #####      #              #
##  #        #    #  #   #      #              #
##  #        #    #  #    #     #            #####
##
##  Part 1:  Settings you likely want to customize:
######################################################################
######################################################################

##  What machine is your central manager?
CONDOR_HOST	= 127.0.0.1

##--------------------------------------------------------------------
##  Pathnames:
##--------------------------------------------------------------------
##  Where have you installed the bin, sbin and lib condor directories?   
RELEASE_DIR		= @prefix@

##  Where is the local condor directory for each host?  
##  This is where the local config file(s), logs and
##  spool/execute directories are located
LOCAL_DIR		= @prefix@/var
#LOCAL_DIR		= $(RELEASE_DIR)/hosts/$(HOSTNAME)

##  Where is the machine-specific local config file for each host?
LOCAL_CONFIG_FILE	= @prefix@/etc/condor/condor_config.local
#LOCAL_CONFIG_FILE	= $(RELEASE_DIR)/etc/$(HOSTNAME).local

##  Where are optional machine-specific local config files located?
##  Config files are included in lexicographic order.
LOCAL_CONFIG_DIR	= @prefix@/etc/condor/config.d
#LOCAL_CONFIG_DIR	= $(LOCAL_DIR)/config

## Blacklist for file processing in the LOCAL_CONFIG_DIR
## LOCAL_CONFIG_DIR_EXCLUDE_REGEXP = ^((\..*)|(.*~)|(#.*)|(.*\.rpmsave)|(.*\.rpmnew))$

## If the local config file is not present, is it an error?
## WARNING: This is a potential security issue. 
## If not specified, the default is True
#REQUIRE_LOCAL_CONFIG_FILE = TRUE

##--------------------------------------------------------------------
##  Mail parameters:
##--------------------------------------------------------------------
##  When something goes wrong with condor at your site, who should get
##  the email?
CONDOR_ADMIN		= root@127.0.0.1

##  Full path to a mail delivery program that understands that "-s"
##  means you want to specify a subject:
MAIL			= /bin/mail

##--------------------------------------------------------------------
##  Network domain parameters:
##--------------------------------------------------------------------
##  Internet domain of machines sharing a common UID space.  If your
##  machines don't share a common UID space, set it to 
##  UID_DOMAIN = $(FULL_HOSTNAME)
##  to specify that each machine has its own UID space.
UID_DOMAIN		= 127.0.0.1

##  Internet domain of machines sharing a common file system.
##  If your machines don't use a network file system, set it to
##  FILESYSTEM_DOMAIN = $(FULL_HOSTNAME)
##  to specify that each machine has its own file system. 
FILESYSTEM_DOMAIN	= 127.0.0.1

##  This macro is used to specify a short description of your pool. 
##  It should be about 20 characters long. For example, the name of 
##  the UW-Madison Computer Science Condor Pool is ``UW-Madison CS''.
COLLECTOR_NAME 		= My Pool - $(CONDOR_HOST)

######################################################################
######################################################################
##  
##  ######                                   #####
##  #     #    ##    #####    #####         #     #
##  #     #   #  #   #    #     #                 #
##  ######   #    #  #    #     #            #####
##  #        ######  #####      #           #
##  #        #    #  #   #      #           #
##  #        #    #  #    #     #           #######
##  
##  Part 2:  Settings you may want to customize: 
##  (it is generally safe to leave these untouched) 
######################################################################
######################################################################

##
##  The user/group ID <uid>.<gid> of the "Condor" user. 
##  (this can also be specified in the environment)
##  Note: the CONDOR_IDS setting is ignored on Win32 platforms
#CONDOR_IDS=x.x

##--------------------------------------------------------------------
##  Flocking: Submitting jobs to more than one pool
##--------------------------------------------------------------------
##  Flocking allows you to run your jobs in other pools, or lets
##  others run jobs in your pool.
## 
##  To let others flock to you, define FLOCK_FROM.
## 
##  To flock to others, define FLOCK_TO.

##  FLOCK_FROM defines the machines where you would like to grant
##  people access to your pool via flocking. (i.e. you are granting
##  access to these machines to join your pool).
#FLOCK_FROM =
##  An example of this is:
#FLOCK_FROM = somehost.friendly.domain, anotherhost.friendly.domain

##  FLOCK_TO defines the central managers of the pools that you want
##  to flock to. (i.e. you are specifying the machines that you
##  want your jobs to be negotiated at -- thereby specifying the
##  pools they will run in.)
#FLOCK_TO =
##  An example of this is:
#FLOCK_TO = central_manager.friendly.domain, condor.cs.wisc.edu

##  FLOCK_COLLECTOR_HOSTS should almost always be the same as
##  FLOCK_NEGOTIATOR_HOSTS (as shown below).  The only reason it would be
##  different is if the collector and negotiator in the pool that you are
##  flocking too are running on different machines (not recommended).
##  The collectors must be specified in the same corresponding order as
##  the FLOCK_NEGOTIATOR_HOSTS list.
FLOCK_NEGOTIATOR_HOSTS = $(FLOCK_TO)
FLOCK_COLLECTOR_HOSTS = $(FLOCK_TO)
## An example of having the negotiator and the collector on different
## machines is:
#FLOCK_NEGOTIATOR_HOSTS = condor.cs.wisc.edu, condor-negotiator.friendly.domain
#FLOCK_COLLECTOR_HOSTS =  condor.cs.wisc.edu, condor-collector.friendly.domain

##--------------------------------------------------------------------
##  Host/IP access levels
##--------------------------------------------------------------------
##  Please see the administrator's manual for details on these
##  settings, what they're for, and how to use them.

##  What machines have administrative rights for your pool?  This
##  defaults to your central manager.  You should set it to the
##  machine(s) where whoever is the condor administrator(s) works
##  (assuming you trust all the users who log into that/those
##  machine(s), since this is machine-wide access you're granting).
ALLOW_ADMINISTRATOR = $(CONDOR_HOST), $(IP_ADDRESS)

##  If there are no machines that should have administrative access 
##  to your pool (for example, there's no machine where only trusted
##  users have accounts), you can uncomment this setting.
##  Unfortunately, this will mean that administering your pool will 
##  be more difficult.
#DENY_ADMINISTRATOR = *

##  What machines should have "owner" access to your machines, meaning
##  they can issue commands that a machine owner should be able to
##  issue to their own machine (like condor_vacate).  This defaults to
##  machines with administrator access, and the local machine.  This
##  is probably what you want.
ALLOW_OWNER = $(FULL_HOSTNAME), $(ALLOW_ADMINISTRATOR)

##  Read access.  Machines listed as allow (and/or not listed as deny)
##  can view the status of your pool, but cannot join your pool 
##  or run jobs.
##  NOTE: By default, without these entries customized, you
##  are granting read access to the whole world.  You may want to
##  restrict that to hosts in your domain.  If possible, please also
##  grant read access to "*.cs.wisc.edu", so the Condor developers
##  will be able to view the status of your pool and more easily help
##  you install, configure or debug your Condor installation.
##  It is important to have this defined.
ALLOW_READ = * 
#ALLOW_READ = *.your.domain, *.cs.wisc.edu
#DENY_READ = *.bad.subnet, bad-machine.your.domain, 144.77.88.*

##  Write access.  Machines listed here can join your pool, submit
##  jobs, etc.  Note: Any machine which has WRITE access must
##  also be granted READ access.  Granting WRITE access below does
##  not also automatically grant READ access; you must change
##  ALLOW_READ above as well.
##
##  You must set this to something else before Condor will run.
##  This most simple option is:
##    ALLOW_WRITE = *
##  but note that this will allow anyone to submit jobs or add
##  machines to your pool and is a serious security risk.

ALLOW_WRITE = $(FULL_HOSTNAME), 127.0.0.1
#ALLOW_WRITE = *.your.domain, your-friend's-machine.other.domain
#DENY_WRITE = bad-machine.your.domain

##  Are you upgrading to a new version of Condor and confused about
##  why the above ALLOW_WRITE setting is causing Condor to refuse to
##  start up?  If you are upgrading from a configuration that uses
##  HOSTALLOW/HOSTDENY instead of ALLOW/DENY we recommend that you
##  convert all uses of the former to the latter.  The syntax of the
##  authorization settings is identical.  They both support
##  unauthenticated IP-based authorization as well as authenticated
##  user-based authorization.  To avoid confusion, the use of
##  HOSTALLOW/HOSTDENY is discouraged.  Support for it may be removed
##  in the future.

##  Negotiator access.  Machines listed here are trusted central
##  managers.  You should normally not have to change this.
ALLOW_NEGOTIATOR = $(CONDOR_HOST), $(IP_ADDRESS)
##  Now, with flocking we need to let the SCHEDD trust the other 
##  negotiators we are flocking with as well.  You should normally 
##  not have to change this either.
ALLOW_NEGOTIATOR_SCHEDD = $(CONDOR_HOST), $(FLOCK_NEGOTIATOR_HOSTS), $(IP_ADDRESS)

##  Config access.  Machines listed here can use the condor_config_val
##  tool to modify all daemon configurations.  This level of host-wide
##  access should only be granted with extreme caution.  By default,
##  config access is denied from all hosts.
#ALLOW_CONFIG = trusted-host.your.domain

##  Flocking Configs.  These are the real things that Condor looks at,
##  but we set them from the FLOCK_FROM/TO macros above.  It is safe
##  to leave these unchanged.
ALLOW_WRITE_COLLECTOR = $(ALLOW_WRITE), $(FLOCK_FROM)
ALLOW_WRITE_STARTD    = $(ALLOW_WRITE), $(FLOCK_FROM)
ALLOW_READ_COLLECTOR  = $(ALLOW_READ), $(FLOCK_FROM)
ALLOW_READ_STARTD     = $(ALLOW_READ), $(FLOCK_FROM)


##--------------------------------------------------------------------
##  Security parameters for setting configuration values remotely:
##--------------------------------------------------------------------
##  These parameters define the list of attributes that can be set
##  remotely with condor_config_val for the security access levels
##  defined above (for example, WRITE, ADMINISTRATOR, CONFIG, etc).
##  Please see the administrator's manual for further details on these
##  settings, what they're for, and how to use them.  There are no
##  default values for any of these settings.  If they are not
##  defined, no attributes can be set with condor_config_val.

## Do you want to allow condor_config_val -rset to work at all?
## This feature is disabled by default, so to enable, you must
## uncomment the following setting and change the value to "True". 
## Note: changing this requires a restart not just a reconfig.
#ENABLE_RUNTIME_CONFIG = False

## Do you want to allow condor_config_val -set to work at all?
## This feature is disabled by default, so to enable, you must
## uncomment the following setting and change the value to "True". 
## Note: changing this requires a restart not just a reconfig.
#ENABLE_PERSISTENT_CONFIG = False

## Directory where daemons should write persistent config files (used
## to support condor_config_val -set).  This directory should *ONLY*
## be writable by root (or the user the Condor daemons are running as
## if non-root).  There is no default, administrators must define this.
## Note: changing this requires a restart not just a reconfig.
#PERSISTENT_CONFIG_DIR = /full/path/to/root-only/local/directory

##  Attributes that can be set by hosts with "CONFIG" permission (as
##  defined with ALLOW_CONFIG and DENY_CONFIG above).
##  The commented-out value here was the default behavior of Condor
##  prior to version 6.3.3.  If you don't need this behavior, you
##  should leave this commented out.
#SETTABLE_ATTRS_CONFIG = *

##  Attributes that can be set by hosts with "ADMINISTRATOR"
##  permission (as defined above)
#SETTABLE_ATTRS_ADMINISTRATOR = *_DEBUG, MAX_*_LOG

##  Attributes that can be set by hosts with "OWNER" permission (as
##  defined above) NOTE: any Condor job running on a given host will
##  have OWNER permission on that host by default.  If you grant this
##  kind of access, Condor jobs will be able to modify any attributes
##  you list below on the machine where they are running.  This has
##  obvious security implications, so only grant this kind of
##  permission for custom attributes that you define for your own use
##  at your pool (custom attributes about your machines that are
##  published with the STARTD_ATTRS setting, for example).
#SETTABLE_ATTRS_OWNER = your_custom_attribute, another_custom_attr

##  You can also define daemon-specific versions of each of these
##  settings.  For example, to define settings that can only be
##  changed in the condor_startd's configuration by hosts with OWNER
##  permission, you would use:
#STARTD_SETTABLE_ATTRS_OWNER = your_custom_attribute_name


##--------------------------------------------------------------------
##  Network filesystem parameters:
##--------------------------------------------------------------------
##  Do you want to use NFS for file access instead of remote system
##  calls?
#USE_NFS		= False

##  Do you want to use AFS for file access instead of remote system
##  calls?
#USE_AFS		= False

##--------------------------------------------------------------------
##  Checkpoint server:
##--------------------------------------------------------------------
##  Do you want to use a checkpoint server if one is available?  If a
##  checkpoint server is not available or USE_CKPT_SERVER is set to
##  False, checkpoints will be written to the local SPOOL directory on
##  the submission machine.
#USE_CKPT_SERVER	= True

##  What's the hostname of this machine's nearest checkpoint server?
#CKPT_SERVER_HOST	= checkpoint-server-hostname.your.domain

##  Do you want the starter on the execute machine to choose the
##  checkpoint server?  If False, the CKPT_SERVER_HOST set on
##  the submit machine is used.  Otherwise, the CKPT_SERVER_HOST set
##  on the execute machine is used.  The default is true.
#STARTER_CHOOSES_CKPT_SERVER = True

##--------------------------------------------------------------------
##  Miscellaneous:
##--------------------------------------------------------------------
##  Try to save this much swap space by not starting new shadows.  
##  Specified in megabytes.
#RESERVED_SWAP		= 0

##  What's the maximum number of jobs you want a single submit machine
##  to spawn shadows for?  The default is a function of $(DETECTED_MEMORY)
##  and a guess at the number of ephemeral ports available.

## Example 1:
#MAX_JOBS_RUNNING	= 10000

## Example 2:
## This is more complicated, but it produces the same limit as the default.
## First define some expressions to use in our calculation.
## Assume we can use up to 80% of memory and estimate shadow private data
## size of 800k.
#MAX_SHADOWS_MEM	= ceiling($(DETECTED_MEMORY)*0.8*1024/800)
## Assume we can use ~21,000 ephemeral ports (avg ~2.1 per shadow).
## Under Linux, the range is set in /proc/sys/net/ipv4/ip_local_port_range.
#MAX_SHADOWS_PORTS	= 10000
## Under windows, things are much less scalable, currently.
## Note that this can probably be safely increased a bit under 64-bit windows.
#MAX_SHADOWS_OPSYS	= ifThenElse(regexp("WIN.*","$(OPSYS)"),200,100000)
## Now build up the expression for MAX_JOBS_RUNNING.  This is complicated
## due to lack of a min() function.
#MAX_JOBS_RUNNING	= $(MAX_SHADOWS_MEM)
#MAX_JOBS_RUNNING	= \
#  ifThenElse( $(MAX_SHADOWS_PORTS) < $(MAX_JOBS_RUNNING), \
#              $(MAX_SHADOWS_PORTS), \
#              $(MAX_JOBS_RUNNING) )
#MAX_JOBS_RUNNING	= \
#  ifThenElse( $(MAX_SHADOWS_OPSYS) < $(MAX_JOBS_RUNNING), \
#              $(MAX_SHADOWS_OPSYS), \
#              $(MAX_JOBS_RUNNING) )


##  Maximum number of simultaneous downloads of output files from
##  execute machines to the submit machine (limit applied per schedd).
##  The value 0 means unlimited.
#MAX_CONCURRENT_DOWNLOADS = 10

##  Maximum number of simultaneous uploads of input files from the
##  submit machine to execute machines (limit applied per schedd).
##  The value 0 means unlimited.
#MAX_CONCURRENT_UPLOADS = 10

##  Condor needs to create a few lock files to synchronize access to
##  various log files.  Because of problems we had with network
##  filesystems and file locking over the years, we HIGHLY recommend
##  that you put these lock files on a local partition on each
##  machine.  If you don't have your LOCAL_DIR on a local partition,
##  be sure to change this entry.  Whatever user (or group) condor is
##  running as needs to have write access to this directory.  If
##  you're not running as root, this is whatever user you started up
##  the condor_master as.  If you are running as root, and there is a
##  condor account, it is probably condor.  Otherwise, it is whatever
##  you've set in the CONDOR_IDS environment variable.  See the Admin
##  manual for details on this.
LOCK		= $(LOG)

##  If you don't use a fully qualified name in your /etc/hosts file
##  (or NIS, etc.) for either your official hostname or as an alias,
##  Condor would not normally be able to use fully qualified names in
##  places that it'd like to.  You can set this parameter to the
##  domain you'd like appended to your hostname, if changing your host
##  information is not a good option.  This parameter must be set in
##  the global config file (not the LOCAL_CONFIG_FILE from above). 
#DEFAULT_DOMAIN_NAME = your.domain.name

##  If you don't have DNS set up, Condor will normally fail in many
##  places because it can't resolve hostnames to IP addresses and
##  vice-versa. If you enable this option, Condor will use
##  pseudo-hostnames constructed from a machine's IP address and the
##  DEFAULT_DOMAIN_NAME. Both NO_DNS and DEFAULT_DOMAIN must be set in
##  your top-level config file for this mode of operation to work
##  properly.
NO_DNS = True

##  Condor can be told whether or not you want the Condor daemons to
##  create a core file if something really bad happens.  This just
##  sets the resource limit for the size of a core file.  By default,
##  we don't do anything, and leave in place whatever limit was in
##  effect when you started the Condor daemons.  If this parameter is
##  set and "True", we increase the limit to as large as it gets.  If
##  it is set to "False", we set the limit at 0 (which means that no
##  core files are even created).  Core files greatly help the Condor
##  developers debug any problems you might be having.
#CREATE_CORE_FILES	= True

##  When Condor daemons detect a fatal internal exception, they
##  normally log an error message and exit.  If you have turned on
##  CREATE_CORE_FILES, in some cases you may also want to turn on
##  ABORT_ON_EXCEPTION so that core files are generated when an
##  exception occurs.  Set the following to True if that is what you
##  want.
#ABORT_ON_EXCEPTION = False

##  If your site needs to use UID_DOMAIN settings (defined above) that
##  are not real Internet domains that match the hostnames, you can
##  tell Condor to trust whatever UID_DOMAIN a submit machine gives to
##  the execute machine and just make sure the two strings match.  The
##  default for this setting is False, since it is more secure this
##  way.
#TRUST_UID_DOMAIN = False

## If you would like to be informed in near real-time via condor_q when
## a vanilla/standard/java job is in a suspension state, set this attribute to
## TRUE. However, this real-time update of the condor_schedd by the shadows 
## could cause performance issues if there are thousands of concurrently
## running vanilla/standard/java jobs under a single condor_schedd and they
## are allowed to suspend and resume.
#REAL_TIME_JOB_SUSPEND_UPDATES = False

## A standard universe job can perform arbitrary shell calls via the
## libc 'system()' function. This function call is routed back to the shadow
## which performs the actual system() invocation in the initial directory of the
## running program and as the user who submitted the job. However, since the
## user job can request ARBITRARY shell commands to be run by the shadow, this
## is a generally unsafe practice. This should only be made available if it is
## actually needed. If this attribute is not defined, then it is the same as
## it being defined to False. Set it to True to allow the shadow to execute
## arbitrary shell code from the user job.
#SHADOW_ALLOW_UNSAFE_REMOTE_EXEC = False

## KEEP_OUTPUT_SANDBOX is an optional feature to tell Condor-G to not
## remove the job spool when the job leaves the queue.  To use, just
## set to TRUE.  Since you will be operating Condor-G in this manner,
## you may want to put leave_in_queue = false in your job submit
## description files, to tell Condor-G to simply remove the job from
## the queue immediately when the job completes (since the output files
## will stick around no matter what).
#KEEP_OUTPUT_SANDBOX = False

## This setting tells the negotiator to ignore user priorities.  This
## avoids problems where jobs from different users won't run when using
## condor_advertise instead of a full-blown startd (some of the user
## priority system in Condor relies on information from the startd --
## we will remove this reliance when we support the user priority
## system for grid sites in the negotiator; for now, this setting will
## just disable it).
#NEGOTIATOR_IGNORE_USER_PRIORITIES = False

## This is a list of libraries containing ClassAd plug-in functions.
#CLASSAD_USER_LIBS =

## This setting tells Condor whether to delegate or copy GSI X509
## credentials when sending them over the wire between daemons.
## Delegation can take up to a second, which is very slow when
## submitting a large number of jobs. Copying exposes the credential
## to third parties if Condor is not set to encrypt communications.
## By default, Condor will delegate rather than copy.
#DELEGATE_JOB_GSI_CREDENTIALS = True

## This setting controls whether Condor delegates a full or limited
## X509 credential for jobs. Currently, this only affects grid-type
## gt2 grid universe jobs. The default is False.
#DELEGATE_FULL_JOB_GSI_CREDENTIALS = False

## This setting controls the default behavior for the spooling of files
## into, or out of, the Condor system by such tools as condor_submit
## and condor_transfer_data. Here is the list of valid settings for this
## parameter and what they mean:
##
##   stm_use_schedd_only
##      Ask the condor_schedd to solely store/retrieve the sandbox
##
##   stm_use_transferd
##      Ask the condor_schedd for a location of a condor_transferd, then
##      store/retrieve the sandbox from the transferd itself.
##
## The allowed values are case insensitive.
## The default of this parameter if not specified is: stm_use_schedd_only
#SANDBOX_TRANSFER_METHOD = stm_use_schedd_only

## This setting specifies an IP address that depends on the setting of
## BIND_ALL_INTERFACES. If BIND_ALL_INTERFACES  is True (the default), then
## this variable controls what IP address will be advertised as the public
## address of the daemon. If BIND_ALL_INTERFACES is False, then this variable
## specifies which IP address to bind network sockets to. If
## BIND_ALL_INTERFACES is False  and NETWORK_INTERFACE is not defined, Condor
## chooses a network interface automatically. It tries to choose a public
## interface if one is available. If it cannot decide which of two interfaces
## to choose from, it will pick the first one.
BIND_ALL_INTERFACES = False
NETWORK_INTERFACE = 127.0.0.1

##--------------------------------------------------------------------
##  Settings that control the daemon's debugging output:
##--------------------------------------------------------------------

##
## The flags given in ALL_DEBUG are shared between all daemons.
##

#ALL_DEBUG               =
#MAX_DEFAULT_LOG		= 10 Mb

#MAX_COLLECTOR_LOG	= $(MAX_DEFAULT_LOG)
#COLLECTOR_DEBUG		=

#MAX_KBDD_LOG		= $(MAX_DEFAULT_LOG)
#KBDD_DEBUG		=

#MAX_NEGOTIATOR_LOG	= $(MAX_DEFAULT_LOG)
#NEGOTIATOR_DEBUG	= D_MATCH
#MAX_NEGOTIATOR_MATCH_LOG = $(MAX_DEFAULT_LOG)

#MAX_SCHEDD_LOG		= $(MAX_DEFAULT_LOG)
#SCHEDD_DEBUG		= D_PID

#MAX_SHADOW_LOG		= $(MAX_DEFAULT_LOG)
#SHADOW_DEBUG		=

#MAX_STARTD_LOG		= $(MAX_DEFAULT_LOG)
#STARTD_DEBUG		= 

#MAX_STARTER_LOG		= $(MAX_DEFAULT_LOG)

#MAX_MASTER_LOG		= $(MAX_DEFAULT_LOG)
#MASTER_DEBUG		= 
##  Truncates master log start up?
#TRUNC_MASTER_LOG_ON_OPEN        = False

#MAX_JOB_ROUTER_LOG      = $(MAX_DEFAULT_LOG)
#JOB_ROUTER_DEBUG        =

#MAX_ROOSTER_LOG         = $(MAX_DEFAULT_LOG)
#ROOSTER_DEBUG           =

#MAX_SHARED_PORT_LOG     = $(MAX_DEFAULT_LOG)
#SHARED_PORT_DEBUG       =

#MAX_HDFS_LOG            = $(MAX_DEFAULT_LOG)
#HDFS_DEBUG              =

# High Availability Logs
#MAX_HAD_LOG		= $(MAX_DEFAULT_LOG)
#HAD_DEBUG		=
#MAX_REPLICATION_LOG	= $(MAX_DEFAULT_LOG)
#REPLICATION_DEBUG	=
#MAX_TRANSFERER_LOG	= $(MAX_DEFAULT_LOG)
#TRANSFERER_DEBUG	=


## The daemons touch their log file periodically, even when they have
## nothing to write. When a daemon starts up, it prints the last time
## the log file was modified. This lets you estimate when a previous
## instance of a daemon stopped running. This parameter controls how often
## the daemons touch the file (in seconds).
#TOUCH_LOG_INTERVAL = 60

######################################################################
######################################################################
##  
##  ######                                   #####
##  #     #    ##    #####    #####         #     #
##  #     #   #  #   #    #     #                 #
##  ######   #    #  #    #     #            #####
##  #        ######  #####      #                 #
##  #        #    #  #   #      #           #     #
##  #        #    #  #    #     #            #####
##  
##  Part 3:  Settings control the policy for running, stopping, and
##  periodically check-pointing condor jobs:
######################################################################
######################################################################

##  This section contains macros are here to help write legible
##  expressions:
MINUTE		= 60
HOUR		= (60 * $(MINUTE))
StateTimer	= (time() - EnteredCurrentState)
ActivityTimer	= (time() - EnteredCurrentActivity)
ActivationTimer = ifThenElse(JobStart =!= UNDEFINED, (time() - JobStart), 0)
LastCkpt	= (time() - LastPeriodicCheckpoint)

##  The JobUniverse attribute is just an int.  These macros can be
##  used to specify the universe in a human-readable way:
STANDARD	= 1
VANILLA		= 5
MPI		= 8
VM		= 13
IsMPI           = (TARGET.JobUniverse == $(MPI))
IsVanilla       = (TARGET.JobUniverse == $(VANILLA))
IsStandard      = (TARGET.JobUniverse == $(STANDARD))
IsVM            = (TARGET.JobUniverse == $(VM))

NonCondorLoadAvg	= (LoadAvg - CondorLoadAvg)
BackgroundLoad		= 0.3
HighLoad		= 0.5
StartIdleTime		= 15 * $(MINUTE)
ContinueIdleTime	=  5 * $(MINUTE)
MaxSuspendTime		= 10 * $(MINUTE)
MaxVacateTime		= 10 * $(MINUTE)

KeyboardBusy		= (KeyboardIdle < $(MINUTE))
ConsoleBusy		= (ConsoleIdle  < $(MINUTE))
CPUIdle			= ($(NonCondorLoadAvg) <= $(BackgroundLoad))
CPUBusy			= ($(NonCondorLoadAvg) >= $(HighLoad))
KeyboardNotBusy		= ($(KeyboardBusy) == False)

BigJob		= (TARGET.ImageSize >= (50 * 1024))
MediumJob	= (TARGET.ImageSize >= (15 * 1024) && TARGET.ImageSize < (50 * 1024))
SmallJob	= (TARGET.ImageSize <  (15 * 1024))

JustCPU			= ($(CPUBusy) && ($(KeyboardBusy) == False))
MachineBusy		= ($(CPUBusy) || $(KeyboardBusy))

##  The RANK expression controls which jobs this machine prefers to
##  run over others.  Some examples from the manual include:
##    RANK = TARGET.ImageSize
##    RANK = (Owner == "coltrane") + (Owner == "tyner") \
##                  + ((Owner == "garrison") * 10) + (Owner == "jones")
##  By default, RANK is always 0, meaning that all jobs have an equal
##  ranking.
#RANK			= 0


#####################################################################
##  This where you choose the configuration that you would like to
##  use. If you dont specify, the default policy is a no-preemption
##  policy. This is what older config files called TESTINGMODE_*
######################################################################

# When should we only consider SUSPEND instead of PREEMPT?
#WANT_SUSPEND = False

# When should we preempt gracefully instead of hard-killing?
#WANT_VACATE = False

##  When is this machine willing to start a job? 
#START = True

##  When to suspend a job?
#SUSPEND = False

##  When to resume a suspended job?
#CONTINUE = True

##  When to nicely stop a job?
##  (as opposed to killing it instantaneously)
#PREEMPT = False

##  When to instantaneously kill a preempting job
##  (e.g. if a job is in the pre-empting stage for too long)
#KILL = False

##  A non-zero value here is another way to have a no-preemption policy
##  a job is given this many seconds to exit even when it is preempted.
#MaxJobRetirementTime    = 0

#PERIODIC_CHECKPOINT = ((time() - LastPeriodicCheckpoint)/60.0) > (180.0 + $RANDOM_INTEGER(-30,30,1))
#PREEMPTION_REQUIREMENTS = False
#PREEMPTION_RANK = $(UWCS_PREEMPTION_RANK)
#NEGOTIATOR_PRE_JOB_RANK = RemoteOwner =?= UNDEFINED
#NEGOTIATOR_POST_JOB_RANK = (RemoteOwner =?= UNDEFINED) * (ifthenElse(isUndefined(KFlops), 1000, Kflops) - SlotID - 1.0e10*(Offline=?=True))
#CLAIM_WORKLIFE          = 1200

##  When should a local universe job be allowed to start?
#START_LOCAL_UNIVERSE = TotalLocalJobsRunning < 200

##  When should a scheduler universe job be allowed to start?
#START_SCHEDULER_UNIVERSE = TotalSchedulerJobsRunning < 200

#####################################################################
## This is the UWisc - CS Department Configuration.
#####################################################################

# When should we only consider SUSPEND instead of PREEMPT?
# Only when SUSPEND is True and one of the following is also true:
#   - the job is small
#   - the keyboard is idle
#   - it is a vanilla universe job
UWCS_WANT_SUSPEND  = ( $(SmallJob) || $(KeyboardNotBusy) || $(IsVanilla) ) && \
                     ( $(SUSPEND) )

# When should we preempt gracefully instead of hard-killing?
UWCS_WANT_VACATE   = ( $(ActivationTimer) > 10 * $(MINUTE) || $(IsVanilla) )

# Only start jobs if:
# 1) the keyboard has been idle long enough, AND
# 2) the load average is low enough OR the machine is currently
#    running a Condor job 
# (NOTE: Condor will only run 1 job at a time on a given resource.
# The reasons Condor might consider running a different job while
# already running one are machine Rank (defined above), and user
# priorities.)
UWCS_START	= ( (KeyboardIdle > $(StartIdleTime)) \
                    && ( $(CPUIdle) || \
                         (State != "Unclaimed" && State != "Owner")) )

# Suspend jobs if:
# 1) the keyboard has been touched, OR
# 2a) The CPU has been busy for more than 2 minutes, AND
# 2b) the job has been running for more than 90 seconds
UWCS_SUSPEND = ( $(KeyboardBusy) || \
                 ( (CpuBusyTime > 2 * $(MINUTE)) \
                   && $(ActivationTimer) > 90 ) )

# Continue jobs if:
# 1) the cpu is idle, AND 
# 2) we've been suspended more than 10 seconds, AND
# 3) the keyboard hasn't been touched in a while
UWCS_CONTINUE = ( $(CPUIdle) && ($(ActivityTimer) > 10) \
                  && (KeyboardIdle > $(ContinueIdleTime)) )

# Preempt jobs if:
# 1) The job is suspended and has been suspended longer than we want
# 2) OR, we don't want to suspend this job, but the conditions to
#    suspend jobs have been met (someone is using the machine)
UWCS_PREEMPT = ( ((Activity == "Suspended") && \
                  ($(ActivityTimer) > $(MaxSuspendTime))) \
		 || (SUSPEND && (WANT_SUSPEND == False)) )

# Maximum time (in seconds) to wait for a job to finish before kicking
# it off (due to PREEMPT, a higher priority claim, or the startd
# gracefully shutting down).  This is computed from the time the job
# was started, minus any suspension time.  Once the retirement time runs
# out, the usual preemption process will take place.  The job may
# self-limit the retirement time to _less_ than what is given here.
# By default, nice user jobs and standard universe jobs set their
# MaxJobRetirementTime to 0, so they will not wait in retirement.

UWCS_MaxJobRetirementTime = 0

##  If you completely disable preemption of claims to machines, you
##  should consider limiting the time span over which new jobs will be
##  accepted on the same claim.  See the manual section on disabling
##  preemption for a comprehensive discussion.  Since this example
##  configuration does not disable preemption of claims, we leave
##  CLAIM_WORKLIFE undefined (infinite).
#UWCS_CLAIM_WORKLIFE = 1200

# How long to allow a job to vacate gracefully.  After this time,
# the job is killed.
MachineMaxVacateTime = $(MaxVacateTime) 

# Abort graceful eviction of a job, even though it has not
# yet used all the time allotted by MachineMaxVacateTime.
UWCS_KILL = false

##  Only define vanilla versions of these if you want to make them
##  different from the above settings.
#SUSPEND_VANILLA  = ( $(KeyboardBusy) || \
#       ((CpuBusyTime > 2 * $(MINUTE)) && $(ActivationTimer) > 90) )
#CONTINUE_VANILLA = ( $(CPUIdle) && ($(ActivityTimer) > 10) \
#                     && (KeyboardIdle > $(ContinueIdleTime)) )
#PREEMPT_VANILLA  = ( ((Activity == "Suspended") && \
#                     ($(ActivityTimer) > $(MaxSuspendTime))) \
#                     || (SUSPEND_VANILLA && (WANT_SUSPEND == False)) )
#KILL_VANILLA    = false

##  Checkpoint every 3 hours on average, with a +-30 minute random
##  factor to avoid having many jobs hit the checkpoint server at
##  the same time.
UWCS_PERIODIC_CHECKPOINT	= $(LastCkpt) > (3 * $(HOUR) + \
                                  $RANDOM_INTEGER(-30,30,1) * $(MINUTE) )

##  You might want to checkpoint a little less often.  A good
##  example of this is below.  For jobs smaller than 60 megabytes, we
##  periodic checkpoint every 6 hours.  For larger jobs, we only
##  checkpoint every 12 hours.
#UWCS_PERIODIC_CHECKPOINT	= \
#          ( (TARGET.ImageSize < 60000) && \
#            ($(LastCkpt) > (6  * $(HOUR) + $RANDOM_INTEGER(-30,30,1))) ) || \ 
#          (  $(LastCkpt) > (12 * $(HOUR) + $RANDOM_INTEGER(-30,30,1)) )

##  The rank expressions used by the negotiator are configured below.
##  This is the order in which ranks are applied by the negotiator:
##    1. NEGOTIATOR_PRE_JOB_RANK
##    2. rank in job ClassAd
##    3. NEGOTIATOR_POST_JOB_RANK
##    4. cause of preemption (0=user priority,1=startd rank,2=no preemption)
##    5. PREEMPTION_RANK

##  The NEGOTIATOR_PRE_JOB_RANK expression overrides all other ranks
##  that are used to pick a match from the set of possibilities.
##  The following expression matches jobs to unclaimed resources
##  whenever possible, regardless of the job-supplied rank.
UWCS_NEGOTIATOR_PRE_JOB_RANK = RemoteOwner =?= UNDEFINED

##  The NEGOTIATOR_POST_JOB_RANK expression chooses between
##  resources that are equally preferred by the job.
##  The following example expression steers jobs toward
##  faster machines and tends to fill a cluster of multiprocessors
##  breadth-first instead of depth-first.  It also prefers online
##  machines over offline (hibernating) ones.  In this example,
##  the expression is chosen to have no effect when preemption
##  would take place, allowing control to pass on to
##  PREEMPTION_RANK.
UWCS_NEGOTIATOR_POST_JOB_RANK = \
 (RemoteOwner =?= UNDEFINED) * (ifthenElse(isUndefined(KFlops), 1000, Kflops) - SlotID - 1.0e10*(Offline=?=True))

##  The negotiator will not preempt a job running on a given machine
##  unless the PREEMPTION_REQUIREMENTS expression evaluates to true
##  and the owner of the idle job has a better priority than the owner
##  of the running job.  This expression defaults to true.
UWCS_PREEMPTION_REQUIREMENTS = ((SubmitterGroup =?= RemoteGroup) \
        && ($(StateTimer) > (1 * $(HOUR))) \
	&& (RemoteUserPrio > TARGET.SubmitterUserPrio * 1.2)) \
        || (MY.NiceUser == True)

##  The PREEMPTION_RANK expression is used in a case where preemption
##  is the only option and all other negotiation ranks are equal.  For
##  example, if the job has no preference, it is usually preferable to
##  preempt a job that has just started instead of a job with a longer
##  runtime, to cause less badput.  The default is to rank all 
##  preemptable matches the same.  However, the negotiator will always 
##  prefer to match the job with an idle machine over a preemptable 
##  machine, if all other negotiation ranks are equal.

UWCS_PREEMPTION_RANK = (RemoteUserPrio * 1000000) - ifThenElse(isUndefined(TotalJobRuntime), 0, TotalJobRuntime)


#####################################################################
##  This is a Configuration that will cause your Condor jobs to
##  always run.  This is intended for testing only.
######################################################################

##  This mode will cause your jobs to start on a machine an will let
##  them run to completion.  Condor will ignore all of what is going
##  on in the machine (load average, keyboard activity, etc.)

TESTINGMODE_WANT_SUSPEND	= False
TESTINGMODE_WANT_VACATE		= False
TESTINGMODE_START			= True
TESTINGMODE_SUSPEND			= False
TESTINGMODE_CONTINUE		= True
TESTINGMODE_PREEMPT			= False
TESTINGMODE_KILL			= False
TESTINGMODE_PERIODIC_CHECKPOINT	= False
TESTINGMODE_PREEMPTION_REQUIREMENTS = False
TESTINGMODE_PREEMPTION_RANK = 0

# Prevent machine claims from being reused indefinitely, since
# preemption of claims is disabled in the TESTINGMODE configuration.
TESTINGMODE_CLAIM_WORKLIFE = 1200


######################################################################
######################################################################
##  
##  ######                                  #
##  #     #    ##    #####    #####         #    #
##  #     #   #  #   #    #     #           #    #
##  ######   #    #  #    #     #           #    #
##  #        ######  #####      #           #######
##  #        #    #  #   #      #                #
##  #        #    #  #    #     #                #
##  
##  Part 4:  Settings you should probably leave alone:
##  (unless you know what you're doing)
######################################################################
######################################################################

######################################################################
##  Daemon-wide settings:
######################################################################

##  Pathnames
LOG		= $(LOCAL_DIR)/log/condor
SPOOL		= $(LOCAL_DIR)/lib/condor/spool
EXECUTE		= $(LOCAL_DIR)/lib/condor/execute
BIN		= $(RELEASE_DIR)/bin
LIB		= $(RELEASE_DIR)/lib
INCLUDE		= $(RELEASE_DIR)/include
SBIN		= $(RELEASE_DIR)/sbin
LIBEXEC		= $(RELEASE_DIR)/libexec

## If you leave HISTORY undefined (comment it out), no history file
## will be created. 
HISTORY		= $(SPOOL)/history

##  Log files
COLLECTOR_LOG	= $(LOG)/CollectorLog
KBDD_LOG	= $(LOG)/KbdLog
MASTER_LOG	= $(LOG)/MasterLog
NEGOTIATOR_LOG	= $(LOG)/NegotiatorLog
NEGOTIATOR_MATCH_LOG = $(LOG)/MatchLog
SCHEDD_LOG	= $(LOG)/SchedLog
SHADOW_LOG	= $(LOG)/ShadowLog
STARTD_LOG	= $(LOG)/StartLog
STARTER_LOG	= $(LOG)/StarterLog
JOB_ROUTER_LOG  = $(LOG)/JobRouterLog
ROOSTER_LOG     = $(LOG)/RoosterLog
SHARED_PORT_LOG = $(LOG)/SharedPortLog
# High Availability Logs
HAD_LOG		= $(LOG)/HADLog
REPLICATION_LOG	= $(LOG)/ReplicationLog
TRANSFERER_LOG	= $(LOG)/TransfererLog
HDFS_LOG	= $(LOG)/HDFSLog

##  Lock files
SHADOW_LOCK	= $(LOCK)/ShadowLock

## This setting controls how often any lock files currently in use have their
## time stamp updated. Updating the time stamp prevents administrative programs 
## like 'tmpwatch' from deleting long lived lock files. The parameter is
## an integer in seconds with a minimum of 60 seconds. The default if not
## specified is 28800 seconds, or 8 hours.
## This attribute only takes effect on restart of the daemons or at the next
## update time.
# LOCK_FILE_UPDATE_INTERVAL = 28800

##  This setting primarily allows you to change the port that the
##  collector is listening on.  By default, the collector uses port
##  9618, but you can set the port with a ":port", such as:
##  COLLECTOR_HOST = $(CONDOR_HOST):1234
COLLECTOR_HOST  = $(CONDOR_HOST)

## The NEGOTIATOR_HOST parameter has been deprecated.  The port where
## the negotiator is listening is now dynamically allocated and the IP
## and port are now obtained from the collector, just like all the
## other daemons.  However, if your pool contains any machines that
## are running version 6.7.3 or earlier, you can uncomment this
## setting to go back to the old fixed-port (9614) for the negotiator.
#NEGOTIATOR_HOST = $(CONDOR_HOST)

##  How long are you willing to let daemons try their graceful
##  shutdown methods before they do a hard shutdown? (30 minutes)
#SHUTDOWN_GRACEFUL_TIMEOUT	= 1800

##  How much disk space would you like reserved from Condor?  In
##  places where Condor is computing the free disk space on various
##  partitions, it subtracts the amount it really finds by this
##  many megabytes.  (If undefined, defaults to 0).
RESERVED_DISK		= 5

##  If your machine is running AFS and the AFS cache lives on the same
##  partition as the other Condor directories, and you want Condor to
##  reserve the space that your AFS cache is configured to use, set
##  this to true.
#RESERVE_AFS_CACHE	= False

##  By default, if a user does not specify "notify_user" in the submit
##  description file, any email Condor sends about that job will go to
##  "username@UID_DOMAIN".  If your machines all share a common UID
##  domain (so that you would set UID_DOMAIN to be the same across all
##  machines in your pool), *BUT* email to user@UID_DOMAIN is *NOT*
##  the right place for Condor to send email for your site, you can
##  define the default domain to use for email.  A common example
##  would be to set EMAIL_DOMAIN to the fully qualified hostname of
##  each machine in your pool, so users submitting jobs from a
##  specific machine would get email sent to user@machine.your.domain,
##  instead of user@your.domain.  In general, you should leave this
##  setting commented out unless two things are true: 1) UID_DOMAIN is
##  set to your domain, not $(FULL_HOSTNAME), and 2) email to
##  user@UID_DOMAIN won't work.
#EMAIL_DOMAIN = $(FULL_HOSTNAME)

##  Should Condor daemons create a UDP command socket (for incoming
##  UDP-based commands) in addition to the TCP command socket?  By
##  default, classified ad updates sent to the collector use UDP, in
##  addition to some keep alive messages and other non-essential
##  communication.  However, in certain situations, it might be
##  desirable to disable the UDP command port (for example, to reduce
##  the number of ports represented by a CCB broker, etc).  If not
##  defined, the UDP command socket is enabled by default, and to
##  modify this, you must restart your Condor daemons. Also, this
##  setting must be defined machine-wide.  For example, setting
##  "STARTD.WANT_UDP_COMMAND_SOCKET = False" while the global setting
##  is "True" will still result in the startd creating a UDP socket.
#WANT_UDP_COMMAND_SOCKET = True

##  If your site needs to use TCP updates to the collector, instead of
##  UDP, you can enable this feature.  HOWEVER, WE DO NOT RECOMMEND
##  THIS FOR MOST SITES!  In general, the only sites that might want
##  this feature are pools made up of machines connected via a
##  wide-area network where UDP packets are frequently or always
##  dropped.  If you enable this feature, you *MUST* turn on the
##  COLLECTOR_SOCKET_CACHE_SIZE setting at your collector, and each
##  entry in the socket cache uses another file descriptor.  If not
##  defined, this feature is disabled by default.
#UPDATE_COLLECTOR_WITH_TCP = True

## HIGHPORT and LOWPORT let you set the range of ports that Condor
## will use. This may be useful if you are behind a firewall. By
## default, Condor uses port 9618 for the collector, 9614 for the
## negotiator, and system-assigned (apparently random) ports for
## everything else. HIGHPORT and LOWPORT only affect these
## system-assigned ports, but will restrict them to the range you
## specify here. If you want to change the well-known ports for the
## collector or negotiator, see COLLECTOR_HOST or NEGOTIATOR_HOST.
## Note that both LOWPORT and HIGHPORT must be at least 1024 if you
## are not starting your daemons as root.  You may also specify
## different port ranges for incoming and outgoing connections by
## using IN_HIGHPORT/IN_LOWPORT and OUT_HIGHPORT/OUT_LOWPORT.
#HIGHPORT = 9700 
#LOWPORT = 9600

##  If a daemon does not respond for too long, do you want go generate
##  a core file?  This basically controls the type of the signal
##  sent to the child process, and mostly affects the Condor Master
#NOT_RESPONDING_WANT_CORE	= False


######################################################################
##  Daemon-specific settings:
######################################################################

##--------------------------------------------------------------------
##  condor_master
##--------------------------------------------------------------------
##  Daemons you want the master to keep running for you:
DAEMON_LIST			= MASTER, SCHEDD, STARTD, NEGOTIATOR, COLLECTOR

##  Which daemons use the Condor DaemonCore library (i.e., not the
##  checkpoint server or custom user daemons)?
#DC_DAEMON_LIST = \
#MASTER, STARTD, SCHEDD, KBDD, COLLECTOR, NEGOTIATOR, EVENTD, \
#VIEW_SERVER, CONDOR_VIEW, VIEW_COLLECTOR, HAWKEYE, CREDD, HAD, \
#JOB_ROUTER, ROOSTER, LEASEMANAGER, HDFS, SHARED_PORT, \
#DEFRAG, GANGLIAD, ANNEXD


##  Where are the binaries for these daemons?
MASTER				= $(SBIN)/condor_master
STARTD				= $(SBIN)/condor_startd
SCHEDD				= $(SBIN)/condor_schedd
KBDD				= $(SBIN)/condor_kbdd
NEGOTIATOR			= $(SBIN)/condor_negotiator
COLLECTOR			= $(SBIN)/condor_collector
CKPT_SERVER			= $(SBIN)/condor_ckpt_server
STARTER_LOCAL			= $(SBIN)/condor_starter
JOB_ROUTER                      = $(LIBEXEC)/condor_job_router
ROOSTER                         = $(LIBEXEC)/condor_rooster
HDFS				= $(SBIN)/condor_hdfs
SHARED_PORT			= $(LIBEXEC)/condor_shared_port
TRANSFERER			= $(LIBEXEC)/condor_transferer
DEFRAG                          = $(LIBEXEC)/condor_defrag
GANGLIAD                        = $(LIBEXEC)/condor_gangliad
ANNEXD				= $(SBIN)/condor_annexd

##  When the master starts up, it can place it's address (IP and port)
##  into a file.  This way, tools running on the local machine don't
##  need to query the central manager to find the master.  This
##  feature can be turned off by commenting out this setting.
MASTER_ADDRESS_FILE = $(LOG)/.master_address

##  Where should the master find the condor_preen binary? If you don't
##  want preen to run at all, set it to nothing.
PREEN				= $(SBIN)/condor_preen

##  How do you want preen to behave?  The "-m" means you want email
##  about files preen finds that it thinks it should remove.  The "-r"
##  means you want preen to actually remove these files.  If you don't
##  want either of those things to happen, just remove the appropriate
##  one from this setting.
PREEN_ARGS			= -m -r

##  How often should the master start up condor_preen? (once a day)
#PREEN_INTERVAL			= 86400

##  If a daemon dies an unnatural death, do you want email about it?
#PUBLISH_OBITUARIES		= True

##  If you're getting obituaries, how many lines of the end of that
##  daemon's log file do you want included in the obituary?
#OBITUARY_LOG_LENGTH		= 20

##  Should the master run?
#START_MASTER			= True

##  Should the master start up the daemons you want it to?
#START_DAEMONS			= True

##  How often do you want the master to send an update to the central
##  manager? 
#MASTER_UPDATE_INTERVAL		= 300

##  How often do you want the master to check the time stamps of the
##  running daemons?  If any daemons have been modified, the
##  master restarts them.
#MASTER_CHECK_NEW_EXEC_INTERVAL	= 300

##  Once you notice new binaries, how long should you wait before you
##  try to execute them?
#MASTER_NEW_BINARY_DELAY	= 120

##  What's the maximum amount of time you're willing to give the
##  daemons to quickly shutdown before you just kill them outright?
#SHUTDOWN_FAST_TIMEOUT		= 120

######
##  Exponential back off settings:
######
##  When a daemon keeps crashing, we use "exponential back off" so we
##  wait longer and longer before restarting it.  This is the base of
##  the exponent used to determine how long to wait before starting
##  the daemon again:
#MASTER_BACKOFF_FACTOR		= 2.0

##  What's the maximum amount of time you want the master to wait
##  between attempts to start a given daemon?  (With 2.0 as the
##  MASTER_BACKOFF_FACTOR, you'd hit 1 hour in 12 restarts...)
#MASTER_BACKOFF_CEILING		= 3600

##  How long should a daemon run without crashing before we consider
##  it "recovered".  Once a daemon has recovered, we reset the number
##  of restarts so the exponential back off stuff goes back to normal. 
#MASTER_RECOVER_FACTOR		= 300


##--------------------------------------------------------------------
##  condor_collector
##--------------------------------------------------------------------
## Address to which Condor will send a weekly e-mail with basic
## non-specific information about your pool. See
## http://htcondor.org/privacy.html for more information.
## To disable this behavior, uncomment the below line to
## explicitly set CONDOR_DEVELOPERS to NONE.
#CONDOR_DEVELOPERS = condor-admin@cs.wisc.edu
#CONDOR_DEVELOPERS = NONE

## Global Collector to periodically advertise basic
## non-specific information about your pool. See
## http://htcondor.org/privacy.html for more information.
## To disable this behavior, uncomment the below line to
## explicitly set CONDOR_DEVELOPERS_COLLECTOR to NONE.
#CONDOR_DEVELOPERS_COLLECTOR = condor.cs.wisc.edu
#CONDOR_DEVELOPERS_COLLECTOR = NONE

##  When the collector starts up, it can place it's address (IP and port)
##  into a file.  This way, tools running on the local machine don't
##  need to query the central manager to find the collector.  This
##  feature can be turned off by commenting out this setting.
##  This is essential when using a port of "0" (automatic) for the
##  COLLECTOR_HOST, a useful technique for personal Condor installs.
COLLECTOR_ADDRESS_FILE = $(LOG)/.collector_address

##
##  Conventional HTCondor installations start up as root, and can thus
##  set their own file descriptor limit.  Upping the collector's doesn't
##  hurt anything and ameliorates a common scalability problem.
##
# COLLECTOR_MAX_FILE_DESCRIPTORS = 10240


##--------------------------------------------------------------------
##  condor_negotiator
##--------------------------------------------------------------------
## Determine if the Negotiator will honor SlotWeight attributes, which
## may be used to give a slot greater weight when calculating usage.
#NEGOTIATOR_USE_SLOT_WEIGHTS = True


## How often the Negotaitor starts a negotiation cycle, defined in
## seconds.
#NEGOTIATOR_INTERVAL = 60

## Should the Negotiator publish an update to the Collector after
## every negotiation cycle. It is useful to have this set to True
## to get immediate updates on LastNegotiationCycle statistics.
#NEGOTIATOR_UPDATE_AFTER_CYCLE = False


##--------------------------------------------------------------------
##  condor_startd
##--------------------------------------------------------------------
##  Where are the various condor_starter binaries installed?
STARTER_LIST = STARTER, STARTER_STANDARD
STARTER			= $(SBIN)/condor_starter
STARTER_STANDARD	= $(SBIN)/condor_starter.std
STARTER_LOCAL		= $(SBIN)/condor_starter

##  When the startd starts up, it can place it's address (IP and port)
##  into a file.  This way, tools running on the local machine don't
##  need to query the central manager to find the startd.  This
##  feature can be turned off by commenting out this setting.
STARTD_ADDRESS_FILE	= $(LOG)/.startd_address

##  When a machine is claimed, how often should we poll the state of
##  the machine to see if we need to evict/suspend the job, etc?
#POLLING_INTERVAL        = 5

##  How often should the startd send updates to the central manager? 
#UPDATE_INTERVAL         = 300

##  How long is the startd willing to stay in the "matched" state?
#MATCH_TIMEOUT		= 300

##  How long is the startd willing to stay in the preempting/killing
##  state before it just kills the starter directly?
#KILLING_TIMEOUT	= 30

##  When a machine unclaimed, when should it run benchmarks?
##  LastBenchmark is initialized to 0, so this expression says as soon
##  as we're unclaimed, run the benchmarks.  Thereafter, if we are
##  unclaimed and it has been at least 4 hours since we ran the last
##  benchmarks, run them again.  The startd keeps a weighted average
##  of the benchmark results to provide more accurate values.
##  Note, if you don't want any benchmarks run at all, set RunBenchmarks to "False".
#RunBenchmarks = False
#RunBenchmarks = (LastBenchmark == 0 ) || ((time() - LastBenchmark) >= (4 * $(HOUR)))

##  When the startd does benchmarks, which set of benchmarks should we
##  run?  The default is the same as pre-7.5.6: MIPS and KFLOPS.
benchmarks_joblist = mips kflops

##  What's the max "load" of all running benchmarks?  With the default
##  (1.01), the startd will run the benchmarks serially.
benchmarks_max_job_load = 1.0

#  MIPS (Dhrystone 2.1) benchmark: load 1.0
benchmarks_mips_executable = $(LIBEXEC)/condor_mips
benchmarks_mips_job_load = 1.0

#  KFLOPS (clinpack) benchmark: load 1.0
benchmarks_kflops_executable = $(LIBEXEC)/condor_kflops
benchmarks_kflops_job_load = 1.0


##  Normally, when the startd is computing the idle time of all the
##  users of the machine (both local and remote), it checks the utmp
##  file to find all the currently active ttys, and only checks access
##  time of the devices associated with active logins.  Unfortunately,
##  on some systems, utmp is unreliable, and the startd might miss
##  keyboard activity by doing this.  So, if your utmp is unreliable,
##  set this setting to True and the startd will check the access time
##  on all tty and pty devices.
#STARTD_HAS_BAD_UTMP = False

##  This entry allows the startd to monitor console (keyboard and
##  mouse) activity by checking the access times on special files in
##  /dev.  Activity on these files shows up as "ConsoleIdle" time in
##  the startd's ClassAd.  Just give a comma-separated list of the
##  names of devices you want considered the console, without the
##  "/dev/" portion of the pathname.
#CONSOLE_DEVICES = mouse, console


##  The STARTD_ATTRS (formerly STARTD_EXPRS) entry allows you to
##  have the startd advertise arbitrary attributes from the config
##  file in its ClassAd.  Give the comma-separated list of entries
##  from the config file you want in the startd ClassAd.
##  NOTE: because of the different syntax of the config file and
##  ClassAds, you might have to do a little extra work to get a given
##  entry into the ClassAd.  In particular, ClassAds require double
##  quotes (") around your strings.  Numeric values can go in
##  directly, as can boolean expressions.  For example, if you wanted
##  the startd to advertise its list of console devices, when it is
##  configured to run benchmarks, and how often it sends updates to
##  the central manager, you'd have to define the following helper
##  macro:
#MY_CONSOLE_DEVICES = "$(CONSOLE_DEVICES)"
##  Note: this must come before you define STARTD_ATTRS because macros
##  must be defined before you use them in other macros or
##  expressions.
##  Then, you'd set the STARTD_ATTRS setting to this:
#STARTD_ATTRS = MY_CONSOLE_DEVICES, RunBenchmarks, UPDATE_INTERVAL
##
##  STARTD_ATTRS can also be defined on a per-slot basis.  The startd
##  builds the list of attributes to advertise by combining the lists
##  in this order: STARTD_ATTRS, SLOTx_STARTD_ATTRS.  In the below
##  example, the startd ad for slot1 will have the value for
##  favorite_color, favorite_season, and favorite_movie, and slot2
##  will have favorite_color, favorite_season, and favorite_song.
##
#STARTD_ATTRS = favorite_color, favorite_season
#SLOT1_STARTD_ATTRS = favorite_movie
#SLOT2_STARTD_ATTRS = favorite_song
##
##  Attributes in the STARTD_ATTRS list can also be on a per-slot basis.
##  For example, the following configuration:
##
#favorite_color = "blue"
#favorite_season = "spring"
#SLOT2_favorite_color = "green"
#SLOT3_favorite_season = "summer"
#STARTD_ATTRS = favorite_color, favorite_season
##
##  will result in the following attributes in the slot classified
##  ads:
##
## slot1 - favorite_color = "blue"; favorite_season = "spring"
## slot2 - favorite_color = "green"; favorite_season = "spring"
## slot3 - favorite_color = "blue"; favorite_season = "summer"
##
##  Finally, there is an automatic mechanism to
##  publish the COLLECTOR_HOST setting as a string.  This can be
##  useful using the "$$(COLLECTOR_HOST_STRING)" syntax in the submit file
##  for jobs to know (for example, via their environment) what pool
##  they're running in.  You can change the value published in the
##  COLLECTOR_HOST_STRING attribute by changing this value,
##  (this must be a value classad string value, so don't forget the quotes!)
#COLLECTOR_HOST_STRING = "$(COLLECTOR_HOST)"

##  When the startd is claimed by a remote user, it can also advertise
##  arbitrary attributes from the ClassAd of the job it is working on.
##  Just list the attribute names you want advertised.  
##  Note: since this is already a ClassAd, you don't have to do quoting.
##  Note2: the job attributes ImageSize, ExecutableSize, JobUniverse, NiceUser are automatically advertised.
#STARTD_JOB_ATTRS = 

##  If you want to "lie" to Condor about how many CPUs your machine
##  has, you can use this setting to override Condor's automatic
##  computation.  If you modify this, you must restart the startd for
##  the change to take effect (a simple condor_reconfig will not do).
##  Please read the section on "condor_startd Configuration File
##  Macros" in the Condor Administrators Manual for a further
##  discussion of this setting.  Its use is not recommended.  This
##  must be an integer ("N" is not a valid setting, that's just used to
##  represent the default).
#NUM_CPUS = N

##  If you never want Condor to detect more the "N" CPUs, uncomment this
##  line out. You must restart the startd for this setting to take 
##  effect. If set to 0 or a negative number, it is ignored. 
##  By default, it is ignored. Otherwise, it must be a positive  
##  integer ("N" is not a valid setting, that's just used to
##  represent the default).
#MAX_NUM_CPUS = N

##  Normally, Condor will automatically detect the amount of physical
##  memory available on your machine.  Define MEMORY to tell Condor
##  how much physical memory (in MB) your machine has, overriding the
##  value Condor computes automatically.  For example:
#MEMORY = 128

##  How much memory would you like reserved from Condor?  By default,
##  Condor considers all the physical memory of your machine as
##  available to be used by Condor jobs.  If RESERVED_MEMORY is
##  defined, Condor subtracts it from the amount of memory it
##  advertises as available.
#RESERVED_MEMORY = 0

######
##  SMP startd settings
##
##  By default, Condor will evenly divide the resources in an SMP
##  machine (such as RAM, swap space and disk space) among all the
##  CPUs, and advertise each CPU as its own slot with an even share of
##  the system resources.  If you want something other than this,
##  there are a few options available to you.  Please read the section
##  on "Configuring The Startd for SMP Machines" in the Condor
##  Administrator's Manual for full details.  The various settings are
##  only briefly listed and described here.
######

##  The maximum number of different slot types.
#MAX_SLOT_TYPES = 10

##  Use this setting to define your own slot types.  This
##  allows you to divide system resources unevenly among your CPUs.
##  You must use a different setting for each different type you
##  define.  The "<N>" in the name of the macro listed below must be
##  an integer from 1 to MAX_SLOT_TYPES (defined above),
##  and you use this number to refer to your type.  There are many
##  different formats these settings can take, so be sure to refer to
##  the section on "Configuring The Startd for SMP Machines" in the
##  Condor Administrator's Manual for full details.  In particular,
##  read the section titled "Defining Slot Types" to help
##  understand this setting.  If you modify any of these settings, you
##  must restart the condor_start for the change to take effect.
#SLOT_TYPE_<N> = 1/4
#SLOT_TYPE_<N> = cpus=1, ram=25%, swap=1/4, disk=1/4
#  For example:
#SLOT_TYPE_1 = 1/8
#SLOT_TYPE_2 = 1/4

##  If you define your own slot types, you must specify how
##  many slots of each type you wish to advertise.  You do
##  this with the setting below, replacing the "<N>" with the
##  corresponding integer you used to define the type above.  You can
##  change the number of a given type being advertised at run-time,
##  with a simple condor_reconfig.  
#NUM_SLOTS_TYPE_<N> = M
#  For example:
#NUM_SLOTS_TYPE_1 = 6
#NUM_SLOTS_TYPE_2 = 1

##  The number of evenly-divided slots you want Condor to
##  report to your pool (if less than the total number of CPUs).  This
##  setting is only considered if the "type" settings described above
##  are not in use.  By default, all CPUs are reported.  This setting
##  must be an integer ("N" is not a valid setting, that's just used to
##  represent the default).
#NUM_SLOTS = N

##  How many of the slots the startd is representing should
##  be "connected" to the console (in other words, notice when there's
##  console activity)?  This defaults to all slots
#SLOTS_CONNECTED_TO_CONSOLE = $(NUM_CPUS)

##  How many of the slots the startd is representing should
##  be "connected" to the keyboard (for remote tty activity, as well
##  as console activity).  Defaults to all slots
#SLOTS_CONNECTED_TO_KEYBOARD = $(NUM_CPUS)

##  If there are slots that are not connected to the
##  keyboard or the console (see the above two settings), the
##  corresponding idle time reported will be the time since the startd
##  was spawned, plus the value of this parameter.  It defaults to 20
##  minutes.  We do this because, if the slot is configured
##  not to care about keyboard activity, we want it to be available to
##  Condor jobs as soon as the startd starts up, instead of having to
##  wait for 15 minutes or more (which is the default time a machine
##  must be idle before Condor will start a job).  If you don't want
##  this boost, just set the value to 0.  If you change your START
##  expression to require more than 15 minutes before a job starts,
##  but you still want jobs to start right away on some of your SMP
##  nodes, just increase this parameter.
#DISCONNECTED_KEYBOARD_IDLE_BOOST = 1200

##	CKPT_PROBE is the location of a program which computes aspects of the
##	CheckpointPlatform classad attribute. By default the location of this
##	executable will be here: $(LIBEXEC)/condor_ckpt_probe
CKPT_PROBE = $(LIBEXEC)/condor_ckpt_probe

##--------------------------------------------------------------------
##  condor_schedd
##--------------------------------------------------------------------
##  Where are the various shadow binaries installed?
SHADOW_LIST = SHADOW, SHADOW_STANDARD
SHADOW			= $(SBIN)/condor_shadow
SHADOW_STANDARD		= $(SBIN)/condor_shadow.std

##  When the schedd starts up, it can place it's address (IP and port)
##  into a file.  This way, tools running on the local machine don't
##  need to query the central manager to find the schedd.  This
##  feature can be turned off by commenting out this setting.
SCHEDD_ADDRESS_FILE	= $(SPOOL)/.schedd_address

##  Additionally, a daemon may store its ClassAd on the local filesystem
##  as well as sending it to the collector. This way, tools that need
##  information about a daemon do not have to contact the central manager
##  to get information about a daemon on the same machine.
SCHEDD_DAEMON_AD_FILE = $(SPOOL)/.schedd_classad

##  How often should the schedd send an update to the central manager?
#SCHEDD_INTERVAL	= 300 

##  How long should the schedd wait between spawning each shadow?
#JOB_START_DELAY	= 2

##  How many concurrent sub-processes should the schedd spawn to handle
##  queries?  (UNIX only)
#SCHEDD_QUERY_WORKERS   = 3

##  How often should the schedd send a keep alive message to any
##  startds it has claimed?  (5 minutes)
#ALIVE_INTERVAL		= 300

##  This setting controls the maximum number of times that a
##  condor_shadow processes can have a fatal error (exception) before
##  the condor_schedd will simply relinquish the match associated with
##  the dying shadow.
#MAX_SHADOW_EXCEPTIONS	= 5

##  Estimated virtual memory size of each condor_shadow process. 
##  Specified in kilobytes.
# SHADOW_SIZE_ESTIMATE	= 800

##  The condor_schedd can renice the condor_shadow processes on your
##  submit machines.  How "nice" do you want the shadows? (1-19).
##  The higher the number, the lower priority the shadows have.
# SHADOW_RENICE_INCREMENT	= 0

## The condor_schedd can renice scheduler universe processes
## (e.g. DAGMan) on your submit machines.  How "nice" do you want the
## scheduler universe processes? (1-19).  The higher the number, the
## lower priority the processes have.
# SCHED_UNIV_RENICE_INCREMENT = 0

##  By default, when the schedd fails to start an idle job, it will
##  not try to start any other idle jobs in the same cluster during
##  that negotiation cycle.  This makes negotiation much more
##  efficient for large job clusters.  However, in some cases other
##  jobs in the cluster can be started even though an earlier job
##  can't.  For example, the jobs' requirements may differ, because of
##  different disk space, memory, or operating system requirements.
##  Or, machines may be willing to run only some jobs in the cluster,
##  because their requirements reference the jobs' virtual memory size
##  or other attribute.  Setting NEGOTIATE_ALL_JOBS_IN_CLUSTER to True
##  will force the schedd to try to start all idle jobs in each
##  negotiation cycle.  This will make negotiation cycles last longer,
##  but it will ensure that all jobs that can be started will be
##  started.
#NEGOTIATE_ALL_JOBS_IN_CLUSTER = False

## This setting controls how often, in seconds, the schedd considers
## periodic job actions given by the user in the submit file.
## (Currently, these are periodic_hold, periodic_release, and periodic_remove.)
#PERIODIC_EXPR_INTERVAL = 60

##
##  Conventional HTCondor installations start up as root, and can thus
##  set their own file descriptor limit.  Upping the schedd's limit has
##  some minor downsides (larger buffers passed to select() and the like), 
##  but upping it makes a class of difficult-to-debug problems much rarer.
##
# SCHEDD_MAX_FILE_DESCRIPTORS = 4096

######
## Queue management settings:
######
##  How often should the schedd truncate it's job queue transaction
##  log?  (Specified in seconds, once a day is the default.)
#QUEUE_CLEAN_INTERVAL	= 86400

##  How often should the schedd commit "wall clock" run time for jobs
##  to the queue, so run time statistics remain accurate when the
##  schedd crashes?  (Specified in seconds, once per hour is the
##  default.  Set to 0 to disable.)
#WALL_CLOCK_CKPT_INTERVAL = 3600

##  What users do you want to grant super user access to this job
##  queue?  (These users will be able to remove other user's jobs). 
##  By default, this only includes root.
QUEUE_SUPER_USERS	= root, condor


##--------------------------------------------------------------------
##  condor_shadow
##--------------------------------------------------------------------
##  If the shadow is unable to read a checkpoint file from the
##  checkpoint server, it keeps trying only if the job has accumulated
##  more than MAX_DISCARDED_RUN_TIME seconds of CPU usage.  Otherwise,
##  the job is started from scratch.  Defaults to 1 hour.  This
##  setting is only used if USE_CKPT_SERVER (from above) is True.
#MAX_DISCARDED_RUN_TIME = 3600 

##  Should periodic checkpoints be compressed?
#COMPRESS_PERIODIC_CKPT = False

##  Should vacate checkpoints be compressed?
#COMPRESS_VACATE_CKPT = False

##  Should we commit the application's dirty memory pages to swap
##  space during a periodic checkpoint?
#PERIODIC_MEMORY_SYNC = False

##  Should we write vacate checkpoints slowly?  If nonzero, this
##  parameter specifies the speed at which vacate checkpoints should
##  be written, in kilobytes per second.
#SLOW_CKPT_SPEED = 0

##  How often should the shadow update the job queue with job
##  attributes that periodically change?  Specified in seconds.
#SHADOW_QUEUE_UPDATE_INTERVAL = 15 * 60

##  Should the shadow wait to update certain job attributes for the
##  next periodic update, or should it immediately these update
##  attributes as they change?  Due to performance concerns of
##  aggressive updates to a busy condor_schedd, the default is True.
#SHADOW_LAZY_QUEUE_UPDATE = TRUE


##--------------------------------------------------------------------
##  condor_starter
##--------------------------------------------------------------------
##  The condor_starter can renice the processes of Condor
##  jobs on your execute machines.  If you want this, uncomment the
##  following entry and set it to how "nice" you want the user
##  jobs. (1-19)  The larger the number, the lower priority the
##  process gets on your machines.
##  Note on Win32 platforms, this number needs to be greater than
##  zero (i.e. the job must be reniced) or the mechanism that 
##  monitors CPU load on Win32 systems will give erratic results.
#JOB_RENICE_INCREMENT	= 10

##  Should the starter do local logging to its own log file, or send
##  debug information back to the condor_shadow where it will end up
##  in the ShadowLog? 
#STARTER_LOCAL_LOGGING	= TRUE

##  If the UID_DOMAIN settings match on both the execute and submit
##  machines, but the UID of the user who submitted the job is not in
##  the passwd file of the execute machine, the starter will normally
##  exit with an error.  Do you want the starter to just start up the
##  job with the specified UID, even if it is not in the passwd file?
#SOFT_UID_DOMAIN	= FALSE

##  honor the run_as_owner option from the condor submit file.
##
#STARTER_ALLOW_RUNAS_OWNER = TRUE

##  Tell the Starter/Startd what program to use to remove a directory
##  condor_rmdir.exe is a windows-only command that does a better job
##  than the built-in rmdir command when it is run with elevated privileges
##  Such as when when Condor is running as a service.
##   /s is delete sub-directories
##   /c is continue on error
WINDOWS_RMDIR = $(SBIN)\condor_rmdir.exe
#WINDOWS_RMDIR_OPTIONS = /s /c

##--------------------------------------------------------------------
##  condor_procd
##--------------------------------------------------------------------
##  
# the path to the procd binary
#
PROCD = $(SBIN)/condor_procd

# the path to the procd "address"
#   - on UNIX this will be a named pipe; we'll put it in the
#     $(LOCK) directory by default (note that multiple named pipes
#     will be created in this directory for when the procd responds
#     to its clients)
#   - on Windows, this will be a named pipe as well (but named pipes on
#     Windows are not even close to the same thing as named pipes on
#     UNIX); the name will be something like:
#         \\.\pipe\condor_procd
#
PROCD_ADDRESS = $(LOCK)/procd_pipe

# Note that in other Condor daemons, turning on D_PROCFAMILY will
# result in that daemon logging all of its interactions with the
# ProcD.
#
PROCD_LOG = $(LOG)/ProcLog

# This is the maximum period that the procd will use for taking
# snapshots (the actual period may be lower if a condor daemon registers
# a family for which it wants more frequent snapshots)
#
PROCD_MAX_SNAPSHOT_INTERVAL = 60

# On Windows, we send a process a "soft kill" via a WM_CLOSE message.
# This binary is used by the ProcD (and other Condor daemons if PRIVSEP
# is not enabled) to help when sending soft kills.
WINDOWS_SOFTKILL = $(SBIN)/condor_softkill

##--------------------------------------------------------------------
##  condor_submit
##--------------------------------------------------------------------
##  If you want condor_submit to automatically append an expression to
##  the Requirements expression or Rank expression of jobs at your
##  site, uncomment these entries.
#APPEND_REQUIREMENTS	= (expression to append job requirements)
#APPEND_RANK		= (expression to append job rank)

##  If you want expressions only appended for either standard or
##  vanilla universe jobs, you can uncomment these entries.  If any of
##  them are defined, they are used for the given universe, instead of
##  the generic entries above.
#APPEND_REQ_VANILLA	= (expression to append to vanilla job requirements)
#APPEND_REQ_STANDARD	= (expression to append to standard job requirements)
#APPEND_RANK_STANDARD	= (expression to append to vanilla job rank)
#APPEND_RANK_VANILLA	= (expression to append to standard job rank)

##  This can be used to define a default value for the rank expression
##  if one is not specified in the submit file.
#DEFAULT_RANK	        = (default rank expression for all jobs)

##  If you want universe-specific defaults, you can use the following
##  entries:
#DEFAULT_RANK_VANILLA	= (default rank expression for vanilla jobs)
#DEFAULT_RANK_STANDARD	= (default rank expression for standard jobs)

##  If you want condor_submit to automatically append expressions to
##  the job ClassAds it creates, you can uncomment and define the
##  SUBMIT_ATTRS (formerly SUBMIT_EXPRS) setting.  It works just like the STARTD_ATTRS
##  described above with respect to ClassAd vs. config file syntax,
##  strings, etc.  One common use would be to have the full hostname
##  of the machine where a job was submitted placed in the job
##  ClassAd.  You would do this by uncommenting the following lines: 
#Machine = "$(FULL_HOSTNAME)"
#SUBMIT_ATTRS = Machine

## Condor keeps a buffer of recently-used data for each file an
## application opens.  This macro specifies the default maximum number
## of bytes to be buffered for each open file at the executing
## machine.
#DEFAULT_IO_BUFFER_SIZE = 524288

## Condor will attempt to consolidate small read and write operations
## into large blocks.  This macro specifies the default block size
## Condor will use.
#DEFAULT_IO_BUFFER_BLOCK_SIZE = 32768

##--------------------------------------------------------------------
##  condor_preen 
##--------------------------------------------------------------------
##  Who should condor_preen send email to?
#PREEN_ADMIN		= $(CONDOR_ADMIN)


##--------------------------------------------------------------------
##  Java parameters:
##--------------------------------------------------------------------
##  If you would like this machine to be able to run Java jobs,
##  then set JAVA to the path of your JVM binary.  If you are not
##  interested in Java, there is no harm in leaving this entry
##  empty or incorrect.

JAVA = /usr/bin/java

## JAVA_CLASSPATH_DEFAULT gives the default set of paths in which
## Java classes are to be found.  Each path is separated by spaces.
## If your JVM needs to be informed of additional directories, add
## them here.  However, do not remove the existing entries, as Condor
## needs them.

JAVA_CLASSPATH_DEFAULT = $(LIB) $(LIB)/scimark2lib.jar .

##  JAVA_CLASSPATH_ARGUMENT describes the command-line parameter
##  used to introduce a new classpath:

JAVA_CLASSPATH_ARGUMENT = -classpath

##  JAVA_CLASSPATH_SEPARATOR describes the character used to mark
##  one path element from another:

JAVA_CLASSPATH_SEPARATOR = :

##  JAVA_BENCHMARK_TIME describes the number of seconds for which
##  to run Java benchmarks.  A longer time yields a more accurate
##  benchmark, but consumes more otherwise useful CPU time.
##  If this time is zero or undefined, no Java benchmarks will be run.

JAVA_BENCHMARK_TIME = 2

##  If your JVM requires any special arguments not mentioned in
##  the options above, then give them here.

JAVA_EXTRA_ARGUMENTS =

##
##--------------------------------------------------------------------
##  Condor-G settings
##--------------------------------------------------------------------
##  Where is the GridManager binary installed?

GRIDMANAGER			= $(SBIN)/condor_gridmanager
GT2_GAHP			= $(SBIN)/gahp_server
GRID_MONITOR			= $(SBIN)/grid_monitor

##--------------------------------------------------------------------
##  Settings that control the daemon's debugging output:
##--------------------------------------------------------------------
##
## Note that the Gridmanager runs as the User, not a Condor daemon, so 
## all users must have write permission to the directory that the 
## Gridmanager will use for it's logfile. Our suggestion is to create a
## directory called GridLogs in $(LOG) with UNIX permissions 1777 
## (just like /tmp )
##  Another option is to use /tmp as the location of the GridManager log.
## 

#MAX_GRIDMANAGER_LOG	= $(MAX_DEFAULT_LOG)
#GRIDMANAGER_DEBUG	= 

GRIDMANAGER_LOG = $(LOG)/GridmanagerLog.$(USERNAME)
GRIDMANAGER_LOCK = $(LOCK)/GridmanagerLock.$(USERNAME)

##--------------------------------------------------------------------
##  Various other settings that the Condor-G can use. 
##--------------------------------------------------------------------

## Adjust how frequently the gridmanager checks the status of grid jobs.
## GRIDMANAGER_JOB_PROBE_INTERVAL sets the minimum time between checks
## for each job's status in seconds. For grid-types where each job's
## status must be checked individually (gt2, gt5, nordugrid, batch),
## GRIDMANAGER_JOB_PROBE_RATE sets the maximum number of status check
## requests the gridmanager will send to each remote resource per
## second. If enough jobs are submitted to a remote resource, the
## interval between checks for each job will increase so as not to
## exceed the set rate.
#GRIDMANAGER_JOB_PROBE_INTERVAL = 60
#GRIDMANAGER_JOB_PROBE_RATE = 5

## For grid-type gt2 jobs (pre-WS GRAM), limit the number of jobmanager
## processes the gridmanager will let run on the headnode. Letting too
## many jobmanagers run causes severe load on the headnode.
GRIDMANAGER_MAX_JOBMANAGERS_PER_RESOURCE = 10

## If we're talking to a Globus 2.0 resource, Condor-G will use the new
## version of the GRAM protocol. The first option is how often to check the
## proxy on the submit site of things. If the GridManager discovers a new
## proxy, it will restart itself and use the new proxy for all future 
## jobs launched. In seconds,  and defaults to 10 minutes
#GRIDMANAGER_CHECKPROXY_INTERVAL = 600

## The GridManager will shut things down 3 minutes before loosing Contact
## because of an expired proxy. 
## In seconds, and defaults to 3 minutes
#GRDIMANAGER_MINIMUM_PROXY_TIME  = 180

## Condor requires that each submitted job be designated to run under a
## particular "universe". 
##
## If no universe is specified in the submit file, Condor must pick one
## for the job to use. By default, it chooses the "vanilla" universe. 
## The default can be overridden in the config file with the DEFAULT_UNIVERSE
## setting, which is a string to insert into a job submit description if the
## job does not try and define it's own universe
##
#DEFAULT_UNIVERSE = vanilla

#
# The Cred_min_time_left is the first-pass at making sure that Condor-G
# does not submit your job without it having enough time left for the 
# job to finish. For example, if you have a job that runs for 20 minutes, and
# you might spend 40 minutes in the queue, it's a bad idea to submit with less
# than an hour left before your proxy expires.
# 2 hours seemed like a reasonable default.
#
CRED_MIN_TIME_LEFT		= 120 


## 
## The GridMonitor allows you to submit many more jobs to a GT2 GRAM server
## than is normally possible.
#ENABLE_GRID_MONITOR = TRUE

##
## When an error occurs with the GridMonitor, how long should the
## gridmanager wait before trying to submit a new GridMonitor job?
## The default is 1 hour (3600 seconds).
#GRID_MONITOR_DISABLE_TIME = 3600

##
## The location of the wrapper for invoking
## Condor GAHP server
##
CONDOR_GAHP = $(SBIN)/condor_c-gahp
CONDOR_GAHP_WORKER = $(SBIN)/condor_c-gahp_worker_thread

##
## The Condor GAHP server has its own log.  Like the Gridmanager, the
## GAHP server is run as the User, not a Condor daemon, so all users must 
## have write permission to the directory used for the logfile. Our 
## suggestion is to create a directory called GridLogs in $(LOG) with 
## UNIX permissions 1777 (just like /tmp )
## Another option is to use /tmp as the location of the CGAHP log.
## 
#MAX_C_GAHP_LOG	= $(MAX_DEFAULT_LOG)

#C_GAHP_LOG = $(LOG)/GridLogs/CGAHPLog.$(USERNAME)
C_GAHP_LOG = /tmp/CGAHPLog.$(USERNAME)
C_GAHP_LOCK = /tmp/CGAHPLock.$(USERNAME)
C_GAHP_WORKER_THREAD_LOG = /tmp/CGAHPWorkerLog.$(USERNAME)
C_GAHP_WORKER_THREAD_LOCK = /tmp/CGAHPWorkerLock.$(USERNAME)

##
## Location of the PBS/LSF gahp and its associated binaries
##
GLITE_LOCATION = $(LIBEXEC)/glite
BATCH_GAHP = $(GLITE_LOCATION)/bin/batch_gahp

##
## The location of the wrapper for invoking the Unicore GAHP server
##
UNICORE_GAHP = $(SBIN)/unicore_gahp

##
## The location of the wrapper for invoking the NorduGrid GAHP server
##
NORDUGRID_GAHP = $(SBIN)/nordugrid_gahp

## The location of the CREAM GAHP server
CREAM_GAHP = $(SBIN)/cream_gahp

## Condor-G and CredD can use MyProxy to refresh GSI proxies which are
## about to expire.
#MYPROXY_GET_DELEGATION = /path/to/myproxy-get-delegation

##
## EC2 (REST): Universe = Grid, Grid_Resource = ec2
##

## The location of the ec2_gahp program, required
EC2_GAHP = $(SBIN)/ec2_gahp

## Location of log files, useful for debugging, must be in
## a directory writable by any user, such as /tmp
#EC2_GAHP_DEBUG = D_FULLDEBUG
EC2_GAHP_LOG = /tmp/EC2GahpLog.$(USERNAME)

## As of this writing EC2 has a hard limit of 20 concurrently
## running instances, so a limit of 20 is imposed so the GridManager
## does not waste its time sending requests that will be rejected.
GRIDMANAGER_MAX_SUBMITTED_JOBS_PER_RESOURCE_EC2 = 20

##
##--------------------------------------------------------------------
##  condor_credd credential management daemon
##--------------------------------------------------------------------
##  Where is the CredD binary installed?
CREDD				= $(SBIN)/condor_credd

##  When the credd starts up, it can place it's address (IP and port)
##  into a file.  This way, tools running on the local machine don't
##  need an additional "-n host:port" command line option.  This
##  feature can be turned off by commenting out this setting.
CREDD_ADDRESS_FILE	= $(LOG)/.credd_address

##  Specify a remote credd server here,
#CREDD_HOST  = $(CONDOR_HOST):$(CREDD_PORT)

## CredD startup arguments
## Start the CredD on a well-known port.  Uncomment to to simplify
## connecting to a remote CredD.  Note: that this interface may change
## in a future release.
CREDD_PORT			= 9620
CREDD_ARGS			= -p $(CREDD_PORT) -f

## CredD daemon debugging log
CREDD_LOG			= $(LOG)/CredLog
CREDD_DEBUG			= D_FULLDEBUG
#MAX_CREDD_LOG		= $(MAX_DEFAULT_LOG)

## The credential owner submits the credential.  This list specifies
## other user who are also permitted to see all credentials.  Defaults
## to root on UNIX systems, and Administrator on Windows systems.
#CRED_SUPER_USERS = 

## Credential storage location.  This directory must exist
## prior to starting condor_credd.  It is highly recommended to
## restrict access permissions to _only_ the directory owner.
CRED_STORE_DIR = $(LOCAL_DIR)/cred_dir

## Index file path of saved credentials.
## This file will be automatically created if it does not exist.
#CRED_INDEX_FILE = $(CRED_STORE_DIR/cred-index

## condor_credd  will attempt to refresh credentials when their
## remaining lifespan is less than this value.  Units = seconds.
#DEFAULT_CRED_EXPIRE_THRESHOLD = 3600

## condor-credd periodically checks remaining lifespan of stored
## credentials, at this interval.
#CRED_CHECK_INTERVAL = 60


##
##--------------------------------------------------------------------
##  VM Universe Parameters
##--------------------------------------------------------------------
## Where is the Condor VM-GAHP installed? (Required)
VM_GAHP_SERVER = $(SBIN)/condor_vm-gahp

## If the VM-GAHP is to have its own log, define 
## the location of log file.
##
## Optionally, if you do NOT define VM_GAHP_LOG, logs of VM-GAHP will 
## be stored in the starter's log file. 
## However, on Windows machine you must always define VM_GAHP_LOG. 
#
VM_GAHP_LOG	= $(LOG)/VMGahpLog
#MAX_VM_GAHP_LOG	= $(MAX_DEFAULT_LOG)
#VM_GAHP_DEBUG = D_FULLDEBUG

## What kind of virtual machine program will be used for 
## the VM universe?
## The three primary options are KVM, Xen and VMware.  (Required: no default)
#VM_TYPE = kvm

## How much memory can be used for the VM universe? (Required)
## This value is the maximum amount of memory that can be used by the 
## virtual machine program.
#VM_MEMORY = 128

## Want to support networking for VM universe?
## Default value is FALSE
#VM_NETWORKING = FALSE

## What kind of networking types are supported?
##
## If you set VM_NETWORKING to TRUE, you must define this parameter.
## VM_NETWORKING_TYPE = nat
## VM_NETWORKING_TYPE = bridge
## VM_NETWORKING_TYPE = nat, bridge
##
## If multiple networking types are defined, you may define 
## VM_NETWORKING_DEFAULT_TYPE for default networking type. 
## Otherwise, nat is used for default networking type.
## VM_NETWORKING_DEFAULT_TYPE = nat
#VM_NETWORKING_DEFAULT_TYPE = nat
#VM_NETWORKING_TYPE = nat

## In default, the number of possible virtual machines is same as
## NUM_CPUS.
## Since too many virtual machines can cause the system to be too slow
## and lead to unexpected problems, limit the number of running 
## virtual machines on this machine with
#VM_MAX_NUMBER = 2

## When a VM universe job is started, a status command is sent
## to the VM-GAHP to see if the job is finished.
## If the interval between checks is too short, it will consume 
## too much of the CPU. If the VM-GAHP fails to get status 5 times in a row, 
## an error will be reported to startd, and then startd will check 
## the availability of VM universe.
## Default value is 60 seconds and minimum value is 30 seconds
#VM_STATUS_INTERVAL = 60

## How long will we wait for a request sent to the VM-GAHP to be completed?
## If a request is not completed within the timeout, an error will be reported 
## to the startd, and then the startd will check 
## the availability of vm universe.  Default value is 5 minutes.
#VM_GAHP_REQ_TIMEOUT = 300

## When VMware or Xen causes an error, the startd will disable the
## VM universe.  However, because some errors are just transient,
## we will test one more
## whether vm universe is still unavailable after some time.
## In default, startd will recheck vm universe after 10 minutes.
## If the test also fails, vm universe will be disabled. 
#VM_RECHECK_INTERVAL = 600

## Usually, when we suspend a VM, the memory being used by the VM
## will be saved into a file and then freed.
## However, when we use soft suspend, neither saving nor memory freeing
## will occur.
## For VMware, we send SIGSTOP to a process for VM in order to 
## stop the VM temporarily and send SIGCONT to resume the VM.
## For Xen, we pause CPU. Pausing CPU does not save the memory of VM 
## into a file. It only stops the execution of a VM temporarily.
#VM_SOFT_SUSPEND = TRUE

## If Condor runs as root and a job comes from a different UID domain, 
## Condor generally uses "nobody", unless SLOTx_USER is defined. 
## If "VM_UNIV_NOBODY_USER" is defined, a VM universe job will run 
## as the user defined in "VM_UNIV_NOBODY_USER" instead of "nobody". 
##
## Notice: In VMware VM universe, "nobody" can not create a VMware VM. 
## So we need to define "VM_UNIV_NOBODY_USER" with a regular user. 
## For VMware, the user defined in "VM_UNIV_NOBODY_USER" must have a
## home directory.  So SOFT_UID_DOMAIN does not work for VMware VM universe job.
## If neither "VM_UNIV_NOBODY_USER" nor "SLOTx_VMUSER"/"SLOTx_USER" is defined, 
## VMware VM universe job will run as "condor" instead of "nobody".
## As a result, the preference of local users for a VMware VM universe job
## which comes from the different UID domain is 
## "VM_UNIV_NOBODY_USER" -> "SLOTx_VMUSER" -> "SLOTx_USER" -> "condor". 
#VM_UNIV_NOBODY_USER = login name of a user who has home directory

## If Condor runs as root and "ALWAYS_VM_UNIV_USE_NOBODY" is set to TRUE, 
## all VM universe jobs will run as a user defined in "VM_UNIV_NOBODY_USER".
#ALWAYS_VM_UNIV_USE_NOBODY = FALSE

##--------------------------------------------------------------------
##  VM Universe Parameters Specific to VMware
##--------------------------------------------------------------------

## Where is perl program? (Required)
VMWARE_PERL = perl

## Where is the Condor script program to control VMware? (Required)
VMWARE_SCRIPT = $(SBIN)/condor_vm_vmware

## Networking parameters for VMware
##
## What kind of VMware networking is used?
##
## If multiple networking types are defined, you may specify different
## parameters for each networking type.
##
## Examples
## (e.g.) VMWARE_NAT_NETWORKING_TYPE = nat
## (e.g.) VMWARE_BRIDGE_NETWORKING_TYPE = bridged
## 
##  If there is no parameter for specific networking type, VMWARE_NETWORKING_TYPE is used.
##
#VMWARE_NAT_NETWORKING_TYPE = nat
#VMWARE_BRIDGE_NETWORKING_TYPE = bridged
VMWARE_NETWORKING_TYPE = nat

## The contents of this file will be inserted into the .vmx file of
## the VMware virtual machine before Condor starts it.
#VMWARE_LOCAL_SETTINGS_FILE = /path/to/file

##--------------------------------------------------------------------
##  VM Universe Parameters common to libvirt controlled vm's (xen & kvm)
##--------------------------------------------------------------------

## Networking parameters for Xen & KVM
##
## This is the path to the XML helper command; the libvirt_simple_script.awk
## script just reproduces what Condor already does for the kvm/xen VM
## universe
LIBVIRT_XML_SCRIPT = $(LIBEXEC)/libvirt_simple_script.awk

## This is the optional debugging output file for the xml helper
## script.  Scripts that need to output debugging messages should
## write them to the file specified by this argument, which will be
## passed as the second command line argument when the script is
## executed

#LIBVRT_XML_SCRIPT_ARGS = /dev/stderr

##--------------------------------------------------------------------
##  VM Universe Parameters Specific to Xen
##--------------------------------------------------------------------

##  Where is bootloader for Xen domainU? (Required)
##
##  The bootloader will be used in the case that a kernel image includes
##  a disk image
#XEN_BOOTLOADER = /usr/bin/pygrub


##
##--------------------------------------------------------------------
##  KBDD - keyboard activity detection daemon
##--------------------------------------------------------------------
##  When the KBDD starts up, it can place it's address (IP and port)
##  into a file.  This way, tools running on the local machine don't
##  need an additional "-n host:port" command line option.  This
##  feature can be turned off by commenting out this setting.
KBDD_ADDRESS_FILE = $(LOG)/.kbdd_address

##
##--------------------------------------------------------------------
##  condor_ssh_to_job
##--------------------------------------------------------------------
# NOTE: condor_ssh_to_job is not supported under Windows.

# Tell the starter (execute side) whether to allow the job owner or
# queue super user on the schedd from which the job was submitted to
# use condor_ssh_to_job to access the job interactively (e.g. for
# debugging).  TARGET is the job; MY is the machine.
#ENABLE_SSH_TO_JOB = true

# Tell the schedd (submit side) whether to allow the job owner or
# queue super user to use condor_ssh_to_job to access the job
# interactively (e.g. for debugging).  MY is the job; TARGET is not
# defined.
#SCHEDD_ENABLE_SSH_TO_JOB = true

# Command condor_ssh_to_job should use to invoke the ssh client.
# %h --> remote host
# %i --> ssh key file
# %k --> known hosts file
# %u --> remote user
# %x --> proxy command
# %% --> %
#SSH_TO_JOB_SSH_CMD = "ssh -oUser=%u -oIdentityFile=%i -oStrictHostKeyChecking=yes -oUserKnownHostsFile=%k -oGlobalKnownHostsFile=%k -oProxyCommand=%x %h"

# Additional ssh clients may be configured.  They all have the same
# default as ssh, except for scp, which omits the %h:
#SSH_TO_JOB_SCP_CMD = "scp -oUser=%u -oIdentityFile=%i -oStrictHostKeyChecking=yes -oUserKnownHostsFile=%k -oGlobalKnownHostsFile=%k -oProxyCommand=%x"

# Path to sshd
#SSH_TO_JOB_SSHD = /usr/sbin/sshd

# Arguments the starter should use to invoke sshd in inetd mode.
# %f --> sshd config file
# %% --> %
#SSH_TO_JOB_SSHD_ARGS = "-i -e -f %f"

# sshd configuration template used by condor_ssh_to_job_sshd_setup.
#SSH_TO_JOB_SSHD_CONFIG_TEMPLATE = $(LIB)/condor_ssh_to_job_sshd_config_template

# Path to ssh-keygen
#SSH_TO_JOB_SSH_KEYGEN = /usr/bin/ssh-keygen

# Arguments to ssh-keygen
# %f --> key file to generate
# %% --> %
#SSH_TO_JOB_SSH_KEYGEN_ARGS = "-N '' -C '' -q -f %f -t rsa"

######################################################################
##
##  Condor HDFS
##
##  This is the default local configuration file for configuring Condor
##  daemon responsible for running services related to hadoop 
##  distributed storage system.  You should copy this file to the
##  appropriate location and customize it for your needs.  
##
##  Unless otherwise specified, settings that are commented out show
##  the defaults that are used if you don't define a value.  Settings
##  that are defined here MUST BE DEFINED since they have no default
##  value.
##
######################################################################

######################################################################
## FOLLOWING MUST BE CHANGED
######################################################################

## The location for hadoop installation directory. The default location
## is under 'libexec' directory. The directory pointed by HDFS_HOME 
## should contain a lib folder that contains all the required Jars necessary
## to run HDFS name and data nodes. 
#HDFS_HOME = $(RELEASE_DIR)/libexec/hdfs

## The host and port for hadoop's name node. If this machine is the
## name node (see HDFS_SERVICES) then the specified port will be used
## to run name node. 
#HDFS_NAMENODE = hdfs://example.com:9000
#HDFS_NAMENODE_WEB = example.com:8000

#HDFS_BACKUPNODE = hdfs://example.com:50100
#HDFS_BACKUPNODE_WEB = example.com:50105

## You need to pick one machine as name node by setting this parameter
## to HDFS_NAMENODE. The remaining machines in a storage cluster will
## act as data nodes (HDFS_DATANODE).
#HDFS_NODETYPE = HDFS_DATANODE

## If machine is selected to be NameNode then by a role should defined.
## If it selected to be DataNode then this parameter is ignored.
## Available options:
## ACTIVE: Active NameNode role (default value)
## BACKUP: Always synchronized with the active NameNode state, thus 
##         creating a backup of the namespace. Currently the NameNode
##         supports one Backup node at a time.
## CHECKPOINT: Periodically creates checkpoints of the namespace. 
#HDFS_NAMENODE_ROLE = ACTIVE

## The two set of directories that are required by HDFS are for name 
## node (HDFS_NAMENODE_DIR) and data node (HDFS_DATANODE_DIR). The 
## directory for name node is only required for a machine running 
## name node service and  is used to store critical meta data for 
## files. The data node needs its directory to store file blocks and 
## their replicas.
#HDFS_NAMENODE_DIR = /tmp/hadoop_name
#HDFS_DATANODE_DIR = /scratch/tmp/hadoop_data

## Unlike name node address settings (HDFS_NAMENODE), that needs to be 
## well known across the storage cluster, data node can run on any 
## arbitrary port of given host.
#HDFS_DATANODE_ADDRESS = 0.0.0.0:0

####################################################################
## OPTIONAL
#####################################################################

## Sets the log4j debug level. All the emitted debug output from HDFS
## will go in 'hdfs.log' under $(LOG) directory.
#HDFS_LOG4J=DEBUG

## The access to HDFS services both name node and data node can be 
## restricted by specifying IP/host based filters. By default settings
## from ALLOW_READ/ALLOW_WRITE and DENY_READ/DENY_WRITE
## are used to specify allow and deny list. The below two parameters can
## be used to override these settings. Read the Condor manual for 
## specification of these filters.
## WARN: HDFS doesn't make any distinction between read or write based connection.
#HDFS_ALLOW=*
#HDFS_DENY=*

#Fully qualified name for Name node and Datanode class.
#HDFS_NAMENODE_CLASS=org.apache.hadoop.hdfs.server.namenode.NameNode
#HDFS_DATANODE_CLASS=org.apache.hadoop.hdfs.server.datanode.DataNode
#HDFS_DFSADMIN_CLASS=org.apache.hadoop.hdfs.tools.DFSAdmin

## In case an old name for hdfs configuration files is required.
#HDFS_SITE_FILE = hdfs-site.xml


##
##--------------------------------------------------------------------
##  file transfer plugin defaults
##--------------------------------------------------------------------
FILETRANSFER_PLUGINS = $(LIBEXEC)/curl_plugin, $(LIBEXEC)/data_plugin