CONDOR_CONFIG_VAL(1)
๐ condor_config_val โ the HTCondor Manual page, but make it cute ๐
Hey bestie ๐ซถ you've landed on CONDOR_CONFIG_VAL(1), straight out of the HTCondor Manual. Buckle up, this one's a queen.
โจ NAME โจ
condor_config_val โ HTCondor Manual
Query or set a given HTCondor configuration variable ๐
๐ธ SYNOPSIS ๐ธ
condor_config_val <help option>
condor_config_val [<location options> ] <edit option>
condor_config_val [<location options> ] [<view options> ] vars
condor_config_val use category [:template_name ] [-expand ]
๐ฆ DESCRIPTION ๐ฆ
Okay so picture this: you want to know right now what HTCondor's configuration actually is on some machine, and you do not want to go spelunking through files. That's the whole job of condor_config_val. ๐
You hand it a space-separated set of configuration variables as the vars argument, and it reports what each of those variables is currently set to. And if one of the variables you asked about isn't defined? It stops right there on that variable and tells you it's not defined โ no cap, it just halts. ๐
By default, condor_config_val peeks inside the local machine's configuration files to evaluate the variables. But you don't have to do it that way โ variables and values can instead be queried from a daemon that you point at with a location option. Iconic, honestly.
So here's the tea on output formats โ. The raw output of condor_config_val shows you the string used to define the configuration variable. What does that mean? It's literally whatever sits on the right-hand side of the equals sign (=) in a configuration file for that variable. But heads up: the default output is an expanded one, not raw. Expanded output recursively replaces any macros inside the raw definition of a variable with that macro's own raw definition. It's giving layers. ๐ง
โจ
Every daemon remembers the settings made by a successful invocation of condor_config_val. And no, the configuration file itself does not get modified. Not even a little. ๐
You can also persistently set or unset configuration variables for a specific daemon on a given machine, using a -set or -unset edit option. Persistent means persistent โ those settings are still there when the daemon gets restarted. ๐
Want something more temporary? Configuration variables for a specific daemon on a given machine can be set or unset for the time period that the daemon keeps running, using a -rset or -runset edit option. These runtime settings will override persistent settings until the daemon is restarted. And fr fr, any changes you make will not take effect until condor_reconfig is invoked. Don't forget that step, I'm begging. ๐ญ
Now for the serious part, and I mean it. ๐ In general, modifying a host's configuration with condor_config_val requires the CONFIG access level, which is disabled on all hosts by default. Administrators get more fine-grained control over which access levels can modify which settings. Check out the /admin-manual/security section for all the details on security settings. Also, security considerations require that you have proper settings of the configuration variables SETTABLE_ATTRS_<PERMISSION-LEVEL>, ENABLE_PERSISTENT_CONFIG, and ALLOW_CONFIG in order to use condor_config_val to change any configuration variable. No shortcuts, bestie. ๐
โ ๏ธ And finally, the advice that will save your whole entire life: it is generally wise to test a new configuration on a single machine first, to make sure there's no syntax error or other error in the configuration before you go reconfiguring a ton of machines. Bad syntax or invalid configuration settings is a fatal error for HTCondor daemons, and they will exit. Discovering that problem on one machine is far, far better than causing every HTCondor daemon in the pool to exit. condor_config_val is literally here to help you with exactly this kind of testing. Use it. ๐ซถ
๐ OPTIONS ๐
Okay bestie, here come the options. Every single one. Let's go. ๐
๐ Help options
-helpโ a help option: print usage information and exit. Simple, iconic, done.-versionโ a help option: print the HTCondor version information and exit. Show me the numbers. ๐ข
๐ Edit options
-set "var = value"โ an edit option: sets one or more persistent configuration file variables. The new value remains even if the daemon is restarted. You can set one or more variables; the syntax requires double quote marks to identify the pairing of variable name to value, and to permit spaces. So yes, the quotes are mandatory, not a vibe suggestion. ๐-unset varโ an edit option: each of the persistent configuration variables you list reverts to its previous value. Rewind. โช-rset "var = value"โ an edit option: sets one or more configuration file variables, and the new value remains as long as the daemon continues running. One or more variables can be set; the syntax requires double quote marks to identify the pairing of variable name to value, and to permit spaces. Same quote rules, same energy. โจ-runset varโ an edit option: each of the configuration variables listed reverts to its previous value as long as the daemon continues running. Temporary rewind, only while it's up. โณ
๐ฆ View options
-summary[:detected]โ a view option: for all configuration variables that differ from the default value, print out the name and value. The values are grouped by the file that last set the variable, and in the order that they were set in that file. If thedetectedoption is added, then variables such as$(OPSYSANDVER)that are detected at runtime get included in the output. Ooh, runtime tea. ๐-dumpโ a view option: for all configuration variables that match vars, display the variables and their values. If no vars are listed, then display all configuration variables and their values. Heads up: the values will be raw unless-expand,-default, or-evaluateare used. ๐-defaultโ a view option: default values are displayed.-expandโ a view option: expanded values are displayed. This is the default โ unless-dumpis used. Sneaky little exception, love that for it. ๐ง-rawโ a view option: raw values are displayed.-verboseโ a view option: display the configuration file name and line number where the variable is set, along with the raw, expanded, and default values of the variable. All the receipts at once. ๐-traceโ a view option: display the old configuration file name and line number and value each time the variable is replaced as the configuration is loaded. It's giving history channel. ๐ฐ๏ธ-debug[:<opts>]โ a view option: send output tostderr, overriding a set value ofTOOL_DEBUG. Take the wheel, debug.-evaluateโ a view option: applied only when a location option specifies a daemon. The value of the requested parameter will be evaluated with respect to the ClassAd of that daemon. Math but make it daemon. ๐งฎ-usedโ a view option: applied only when a location option specifies a daemon. Modifies which variables are displayed, narrowing it to only those used by the specified daemon. ๐ฏ-unusedโ a view option: applied only when a location option specifies a daemon. Modifies which variables are displayed to only those not used by the specified daemon. The exact opposite vibe of-used. ๐ซ
โจ EXAMPLES โจ
okay bestie, this is the part where we actually do stuff ๐
here's a whole little journey through condor_config_val so you can see the vibe in motion. follow along, it's giving tutorial but make it cute.
Step one โ just peeking at a value. so we wanna ask the condor_schedd daemon on host perdita what MAX_JOBS_RUNNING is currently set to:
$ condor_config_val -name perdita -schedd MAX_JOBS_RUNNING
500
boom. it's 500. no notes. ๐
Step two โ changing it. now we're gonna tell that same condor_schedd on perdita to set MAX_JOBS_RUNNING to 10:
$ condor_config_val -name perdita -schedd -set "MAX_JOBS_RUNNING = 10"
Successfully set configuration "MAX_JOBS_RUNNING = 10" on
schedd perdita.cs.wisc.edu <192.0.2.32:52067>.
look at that confirmation message. iconic. it literally tells you which daemon and which address it landed on ๐ซถ
Step three โ making it real. here's the thing bestie, setting it doesn't mean anyone noticed yet ๐ this is the command that actually implements the change you just set up there:
$ condor_reconfig -schedd perdita
Sent "Reconfig" command to schedd perdita.cs.wisc.edu
Step four โ checking yourself before you wreck yourself. re-check the config variable and you'll see the change has landed:
$ condor_config_val -name perdita -schedd MAX_JOBS_RUNNING
10
told you. โจ
Step five โ putting it back. MAX_JOBS_RUNNING was 500 before all this, so let's restore it to what it was before it got set to 10:
$ condor_config_val -name perdita -schedd -unset MAX_JOBS_RUNNING
Successfully unset configuration "MAX_JOBS_RUNNING" on
schedd perdita.cs.wisc.edu <192.0.2.32:52067>.
Step six โ implement that too. same deal as before, another command to actually make the unset happen:
$ condor_reconfig -schedd perdita
Sent "Reconfig" command to schedd perdita.cs.wisc.edu
Step seven โ confirm the glow up reversed. now you can see the variable has gone right back to the value it had before you ever set it:
$ condor_config_val -name perdita -schedd MAX_JOBS_RUNNING
500
we love a full circle moment ๐ซ
Template time ๐ฆ โ getting the list of template_names for the role configuration template category:
$ condor_config_val use role
use ROLE accepts
CentralManager
Execute
Personal
Submit
four of them, all sitting there, waiting for you.
And last but not least โ the actual definition of the role:personal configuration template:
$ condor_config_val use role:personal
use ROLE:Personal is
CONDOR_HOST=127.0.0.1
COLLECTOR_HOST=$(CONDOR_HOST):0
DAEMON_LIST=MASTER COLLECTOR NEGOTIATOR STARTD SCHEDD
RunBenchmarks=0
there it is. that's literally the whole template, laid bare. no cap. ๐
๐ AUTHOR ๐
HTCondor Team
๐ COPYRIGHT ๐
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 the whole page, babe ๐ this was CONDOR_CONFIG_VAL(1), dated Oct 16, 2026 โ go forth and config confidently, you're literally so good at this ๐๐
๐ฆ where this page comes from
- fedora 43: condor 25.14.1-1.fc43 ยท Apache-2.0
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms