salt-call

Perform a highstate on this minion

$ salt-call state.highstate

$ salt-call state.highstate test=true

$ salt-call [[-l|--log-level]] debug state.highstate

$ salt-call grains.items

salt-call [options] <function> [arguments]

Examples:
salt-call cmd.run 'ls -l /tmp'
salt-call state.apply my_state_file
salt-call --local pkg.install apache

-h, --help
    Display the help message and exit.

-v, --version
    Show program's version number and exit.

-l <level>, --log-level=<level>
    Set the console log level. Possible levels are: debug, info, warning, error, critical.

--local
    Run salt-call locally without connecting to a Salt master. This option causes salt-call to load modules from the local file system.

-c <dir>, --config-dir=<dir>
    Specify the directory where the Salt configuration files are located. Default is /etc/salt.

-m <dir>, --module-dirs=<dir>
    Specify additional directories where custom Salt execution modules, state modules, or other plugin types can be found.

--output=<outputter>, --out=<outputter>
    Specify the outputter to use for displaying results. Common options include json, yaml, raw, highstate, nested (default).

--out-file=<path>
    Write the output of the command to the specified file instead of standard output.

--retcode-passthrough
    Pass through the Salt internal retcode as the shell exit code. Useful for scripting.

--file-root=<path>
    Override the configured file_roots for the Salt minion.

--pillar-root=<path>
    Override the configured pillar_roots for the Salt minion.

--state-tree=<path>
    Override the configured state_tree for the Salt minion (equivalent to file-root for states).

--master=<hostname>
    Specify the Salt master to connect to, if not using --local.

--minion-id=<id>
    Specify the minion ID to use for the local execution.

salt-call is a utility included with the SaltStack automation framework, designed to execute Salt functions directly on a Salt minion without requiring a Salt master. It effectively simulates a command originating from a master, allowing for local testing, debugging, and administration.

This command is invaluable for developers testing new Salt execution modules or states, as well as system administrators who need to apply a Salt state or run a specific Salt function directly on a single machine for verification or troubleshooting. While salt-call typically connects to a local Salt minion daemon to execute commands, the --local option allows it to operate entirely stand-alone, using only local configuration and files, making it perfect for environments where a Salt master isn't present or desired for a particular operation.

When using salt-call without the --local option, it still communicates with the local Salt minion daemon, which might be connected to a Salt master. However, many features typically provided by the master (like master-defined Pillars, Grains, or files from the master's file_roots) will not be available or will behave differently if not configured locally.

The --local option specifically bypasses any master connection, meaning all necessary configuration, modules, states, and pillar data must be present on the local file system. This distinction is crucial for understanding salt-call's operational context.

The <function> argument usually follows the format module.function (e.g., pkg.install, state.apply, cmd.run). Arguments to the function are passed directly after the function name.

salt-call is frequently used for local state management, such as applying a specific state file (salt-call state.apply my_state_file) or even a full highstate (salt-call state.highstate) directly on the minion. This is extremely useful for testing state changes or applying configurations in isolated environments.

For Salt module developers, salt-call is an indispensable tool. It allows for rapid iteration and testing of new execution modules, state modules, or custom returners by running them directly on a test minion and observing their output without master involvement.

salt-call has been an integral part of the SaltStack project since its early public releases around 2011. It was introduced to provide a direct, on-minion method for executing Salt modules and states, initially to aid in debugging and testing new features without needing a full master-minion setup. Over time, its usage expanded significantly, becoming a staple for local system administration, bootstrapping new systems, and developing complex Salt states due to its ability to mimic master commands and its powerful --local mode.

salt(1), salt-minion(1), salt-master(1), salt-run(1), salt-ssh(1)