CONDOR_INSTALL(1)

🌸 CONDOR_INSTALL(1) β€” the HTCondor Manual, but make it make sense 🌸

okay bestie, welcome to the glow-up of CONDOR_INSTALL(1) from the HTCondor Manual. this is the page for condor_install, and it is long, so buckle up πŸ’…


✨ NAME ✨

condor_install β€” Configure or install HTCondor πŸ› οΈ


✨ SYNOPSIS ✨

condor_configure or condor_install [--help] [--usage]

condor_configure or condor_install [--install[=<path/to/release>]]
[--install-dir=<path>] [--prefix=<path>] [--local-dir=<path>]
[--make-personal-condor] [--bosco] [--type = < submit, execute, manager
>] [--central-manager = < hostname>] [--owner = < ownername >]
[--maybe-daemon-owner] [--install-log = < file >] [--overwrite]
[--ignore-missing-libs] [--force] [--no-env-scripts] [--env-scripts-dir
= < directory >] [--backup] [--credd] [--verbose]

✨ DESCRIPTION ✨

soooo, plot twist: condor_configure and condor_install are literally the same script. one script, two names, doing the most πŸ’– It installs and/or configures HTCondor on Unix machines. As the names imply, condor_install is the one meant to perform an HTCondor installation, and condor_configure is the one meant to configure (or reconfigure) an existing installation. Both of them need Perl 5.6.0 or more recent versions to run, no cap.

condor_configure (and condor_install) are designed to be run more than one time where required. It can install HTCondor when you invoke it with a correct configuration via

$ condor_install

or

$ condor_configure --install

or, it can change the configuration files when you invoke it via

$ condor_configure
⚠️ important tea: changes in the configuration files do not result in changes while HTCondor is running. To effect changes while HTCondor is running, you have to further use the condor_reconfig or condor_restart command. condor_reconfig is required where the currently executing daemons need to be informed of configuration changes. condor_restart is required where the options --make-personal-condor or --type are used, since these affect which daemons are running. πŸ‘‘

Running condor_configure or condor_install with no options results in a usage screen being printed. The --help option can be used to display a full help screen. 🫢

Within the options given below, the phrase release directories is the list of directories that are released with HTCondor. This list includes: bin, etc, examples, include, lib, libexec, man, sbin, sql and src. πŸ—‚οΈ


✨ OPTIONS ✨

  • -help β€” Print help screen and exit πŸ‘‹
  • -usage β€” Print short usage and exit πŸ“
  • -install β€” Perform installation, assuming that the current working directory contains the release directories. Without further options, the configuration is that of a Personal HTCondor, a complete one-machine pool ✨ If used as an upgrade within an existing installation directory, existing configuration files and local directory are preserved. This is the default behavior of condor_install. πŸ’…
  • -install-dir=<path> β€” Specifies the path where HTCondor should be installed or the path where it already is installed. The default is the current working directory. πŸ“
  • -prefix=<path> β€” This is an alias for -install-dir. same energy, different name bestie πŸͺž
  • -local-dir=<path> β€” Specifies the location of the local directory, which is the directory that generally contains the local (machine-specific) configuration file as well as the directories where HTCondor daemons write their run-time information (spool, log, execute). This location is indicated by the LOCAL_DIR variable in the configuration file. When installing (that is, if -install is specified), condor_configure will properly create the local directory in the location specified. If none is specified, the default value is given by the evaluation of $(RELEASE_DIR)/local.$(HOSTNAME).

During subsequent invocations of condor_configure (that is, without the -install option), if the -local-dir option is specified, the new directory will be created and the log, spool and execute directories will be moved there from their current location. 🚚

  • -make-personal-condor β€” Installs and configures for Personal HTCondor, a fully-functional, one-machine pool. it's giving main character energy, one machine doing it all πŸ’œ
  • -bosco β€” Installs and configures Bosco, a personal HTCondor that submits jobs to remote batch systems. πŸ¦‹
  • -type= < submit, execute, manager > β€” One or more of the types may be listed. This determines the roles that a machine may play in a pool. In general, any machine can be a submit and/or execute machine, and there is one central manager per pool. In the case of a Personal HTCondor, the machine fulfills all three of these roles. πŸ‘‘
  • -central-manager=<hostname> β€” Instructs the current HTCondor installation to use the specified machine as the central manager. This modifies the configuration variable COLLECTOR_HOST to point to the given host name. The central manager machine's HTCondor configuration needs to be independently configured to act as a manager using the option -type=manager. no shortcuts here, bestie 😭
  • -owner=<ownername> β€” Set configuration such that HTCondor daemons will be executed as the given owner. This modifies the ownership on the log, spool and execute directories and sets the CONDOR_IDS value in the configuration file, to ensure that HTCondor daemons start up as the specified effective user. This is only applicable when condor_configure is run by root. If not run as root, the owner is the user running the condor_configure command. πŸ”
  • -maybe-daemon-owner β€” If -owner is not specified and no appropriate user can be found to run Condor, then this option will allow the daemon user to be selected. This option is rarely needed by users but can be useful for scripts that invoke condor_configure to install Condor. πŸ€–
  • -install-log=<file> β€” Save information about the installation in the specified file. This is normally only needed when condor_configure is called by a higher-level script, not when invoked by a person. πŸ“„
  • -overwrite β€” Always overwrite the contents of the sbin directory in the installation directory. By default, condor_install will not install if it finds an existing sbin directory with HTCondor programs in it. In this case, condor_install will exit with an error message. Specify -overwrite or -backup to tell condor_install what to do. 🚨

This prevents condor_install from moving an sbin directory out of the way that it should not move. This is particularly useful when trying to install HTCondor in a location used by other things (/usr, /usr/local, etc.) For example: condor_install -prefix=/usr will not move /usr/sbin out of the way unless you specify the -backup option. 😬

The -backup behavior is used to prevent condor_install from overwriting running daemons β€” Unix semantics will keep the existing binaries running, even if they have been moved to a new directory. πŸ’€

  • -backup β€” Always backup the sbin directory in the installation directory. By default, condor_install will not install if it finds an existing sbin directory with HTCondor programs in it. In this case, condor_install will exit with an error message. You must specify -overwrite or -backup to tell condor_install what to do. 🚨

This prevents condor_install from moving an sbin directory out of the way that it should not move. This is particularly useful if you're trying to install HTCondor in a location used by other things (/usr, /usr/local, etc.) For example: condor_install -prefix=/usr will not move /usr/sbin out of the way unless you specify the -backup option. 😬

The -backup behavior is used to prevent condor_install from overwriting running daemons β€” Unix semantics will keep the existing binaries running, even if they have been moved to a new directory. πŸ’€

  • -ignore-missing-libs β€” Ignore missing shared libraries that are detected by condor_install. By default, condor_install will detect missing shared libraries such as libstdc++.so.5 on Linux; it will print messages and exit if missing libraries are detected. The -ignore-missing-libs will cause condor_install to not exit, and to proceed with the installation if missing libraries are detected. πŸ™ˆ
  • -force β€” This is equivalent to enabling both the -overwrite and -ignore-missing-libs command line options. πŸ”₯
  • -no-env-scripts β€” By default, condor_configure writes simple sh and csh shell scripts which can be sourced by their respective shells to set the user's PATH and CONDOR_CONFIG environment variables. This option prevents condor_configure from generating these scripts. 🚫
  • -env-scripts-dir=<directory> β€” By default, the simple sh and csh shell scripts (see -no-env-scripts for details) are created in the root directory of the HTCondor installation. This option causes condor_configure to generate these scripts in the specified directory. πŸŽ€
  • -credd β€” Configure the condor_credd daemon (credential manager daemon). πŸ”‘
  • -verbose β€” Print information about changes to configuration variables as they occur. the way it just tells you everything, iconic πŸ‘€

✨ EXIT STATUS ✨

condor_configure will exit with a status value of 0 (zero) upon success πŸŽ‰, and it will exit with a nonzero value upon failure 😭.


🌸 EXAMPLES 🌸

Okay bestie, here's where it gets real. Let's actually do the thing. ✨


πŸŽ€ Making a central manager (the main character of your pool)

Say your machine is <machine1@cs.wisc.edu> and you want it to be the pool's central manager. On machine1, inside the directory that contains the unzipped HTCondor distribution directories, you run:

$ condor_install --type=submit,execute,manager

And that's it, that's the slay πŸ’…. This lets the machine submit and execute HTCondor jobs, plus it becomes the central manager of the pool. Triple threat energy fr fr.


πŸ¦‹ Turning a machine into a dedicated compute node

Now let's say <machine2@cs.wisc.edu> should be an execute-only machine β€” aka a dedicated computing node β€” inside a pool whose central manager lives on <machine1@cs.wisc.edu>. You hop onto <machine2@cs.wisc.edu> and run this from inside the directory where HTCondor is installed:

$ condor_configure --central-manager=machine1@cs.wisc.edu --type=execute

No cap, that's the whole move. 🫢


πŸ’œ Moving your LOCAL_DIR (a glow-up)

Want to change where the LOCAL_DIR directory lives? It's a configuration knob documented over in the admin manual at configuration/global.html#LOCAL_DIR. Do this from the directory where HTCondor is installed:

$ condor_configure --local-dir=/path/to/new/local/directory

This will move the log, spool, and execute directories to /path/to/new/local/directory, relocating them out of the current local directory. New home, same vibes. 🏑✨


πŸ‘‘ Author

HTCondor Team. Genuinely iconic of them.


1990-2026, Center for High Throughput Computing, Computer Sciences Department, University of Wisconsin-Madison, Madison, WI, US. Licensed under the Apache License, Version 2.0.


And that's a wrap on CONDOR_INSTALL(1), bestie! πŸŽ€ This one's from Jul 26, 2026, and the page tag is CONDOR_INSTALL(1) β€” go forth and install, you've got this πŸ’–πŸŒˆβ­

πŸ“¦ where this page comes from