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 the detected option 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 -evaluate are used. ๐Ÿ’…
  • -default โ€” a view option: default values are displayed.
  • -expand โ€” a view option: expanded values are displayed. This is the default โ€” unless -dump is 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 to stderr, overriding a set value of TOOL_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

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