7.4.1 Invoking gpgconf
One of the following commands must be given:
- List all components. This is the default command used if none is
- List all available backend programs and test whether they are runnable.
- List all options of the component component.
- Change the options of the component component.
- Check the options for the component component.
- Update all configuration files with values taken from the global
configuration file (usually /etc/gnupg/gpgconf.conf).
- Lists the directories used by gpgconf. One directory is
listed per line, and each line consists of a colon-separated list where
the first field names the directory type (for example
and the second field contains the percent-escaped directory. Although
they are not directories, the socket file names used by
gpg-agent and dirmngr are printed as well. Note
that the socket file names and the
homedir lines are the default
names and they may be overridden by command line switches.
- List the global configuration file in a colon separated format. If
filename is given, check that file instead.
- Run a syntax check on the global configuration file. If filename
is given, check that file instead.
- Reload all or the given component. This is basically the same as sending
a SIGHUP to the component. Components which don't support reloading are
- Kill the given component. Components which support killing are
gpg-agent and scdaemon. Components which don't support reloading are
ignored. Note that as of now reload and kill have the same effect for
The following options may be used:
- Outputs additional information while running. Specifically, this
extends numerical field values by human-readable descriptions.
- Do not actually change anything. This is currently only implemented
--change-options and can be used for testing purposes.
- Only used together with
--change-options. If one of the
modified options can be changed in a running daemon process, signal
the running daemon to ask it to reparse its configuration file after
This means that the changes will take effect at run-time, as far as
this is possible. Otherwise, they will take effect at the next start
of the respective backend programs.