Query debconf Answers with debconf-communicate

An install is misbehaving and you need to know what debconf actually has stored, so you pipe a request into debconf-communicate and read the reply. Allow about ten minutes. The examples use debconf 1.5.86ubuntu1 on Ubuntu, but the command speaks the Debian debconf protocol and your question database will differ.

Everything here is read-only. It sets no answer, shows no interactive question and alters no package configuration. You need a shell and the debconf package. Normal queries do not need sudo.

1. Confirm the installed command

Check the executable and package version before trusting an example. Both commands are ordinary and unprivileged:

$ command -v debconf-communicate
/usr/bin/debconf-communicate
$ dpkg-query -W -f='${Package} ${Version}\n' debconf
debconf 1.5.86ubuntu1

The manual's synopsis is echo commands | debconf-communicate [options] [package]. Commands arrive on standard input, one per line. The optional package name is the package you are pretending to be while talking to debconf. Supplying it makes the intent visible, so the examples use debconf.

Checkpoint: confirm the command path and package version match the system you are diagnosing. Do not assume a question exists just because another machine has it.

2. Query one question

Use the protocol's GET command followed by the question name. debconf/frontend makes a handy diagnostic question, because a configured debconf installation normally has it:

$ printf '%s\n' 'GET debconf/frontend' | debconf-communicate --frontend noninteractive debconf
0 Dialog
$ printf '%s\n' "$?"
0

The first number is debconf's protocol return code, not shell decoration. Code 0 means success, and the text after it is the value, here Dialog. Yours may differ. The --frontend noninteractive option stops the query trying to open an interactive frontend. It does not change the stored answer.

Do not add shell quotes inside the protocol line for a question name with spaces. Debconf question names conventionally look like package/setting. If you copy a name from another tool, pass the exact protocol text and check the reply.

3. Read several values in one session

Put one command on each input line. You get one textual reply per command, in order:

$ printf '%s\n' \
    'VERSION 2.0' \
    'GET debconf/frontend' \
    'GET debconf/priority' \
  | debconf-communicate --frontend noninteractive debconf
0 2.0
0 Dialog
0 high

VERSION checks protocol negotiation, and the two GET requests read stored values. The output is protocol data, so do not assume every value is a single word. A value can contain spaces and escaped text. If a script needs a particular answer, check the numeric reply code first, then parse the rest according to the debconf protocol.

Checkpoint: capture the shell status immediately after the pipeline, because any later command replaces $?:

printf '%s\n' 'GET debconf/frontend' | debconf-communicate --frontend noninteractive debconf
status=$?
if [ "$status" -ne 0 ]; then
    printf 'debconf query failed with status %s\n' "$status" >&2
    exit "$status"
fi

4. Inspect a flag or template field

Sometimes the question is about metadata, not the answer. FGET reads a flag, and METAGET reads a template field:

$ printf '%s\n' 'FGET debconf/frontend seen' | debconf-communicate --frontend noninteractive debconf
0 false
$ printf '%s\n' 'METAGET debconf/frontend type' | debconf-communicate --frontend noninteractive debconf
0 select

The exact result depends on the local templates and database. A successful FGET gives a flag value such as true or false. A successful METAGET returns metadata such as the question type. A missing question or field gives a non-zero protocol code and an explanatory message. Treat that as a finding, not an empty answer.

5. Handle failures and the last-command rule

Every input line runs in sequence, and the manual says the program's return value is the numeric return code of the last executed command. So an earlier reply can show an error while a later successful request makes the process exit 0.

This example deliberately sends an unsupported command after a successful query:

$ printf '%s\n' 'GET debconf/frontend' 'BOGUS' \
  | debconf-communicate --frontend noninteractive debconf
0 Dialog
20 Unsupported command "bogus" (full line was "BOGUS") received from confmodule.
$ printf '%s\n' "$?"
20

Tip: put the command you care about last, or inspect every reply in a script. A printed value is not proof of success until you have checked its leading code. If the question is absent, try a known question for diagnosis only, and do not invent a replacement setting.

6. Keep state-changing commands out of a first test

Protocol commands such as SET, RESET, SUBST, REGISTER and UNREGISTER can change debconf state or its question catalogue.

Warning: do not paste them into a production shell, support script or automation run unless you have identified the target question, recorded the current state and agreed how to recover it. A stored answer can change later package-installation behaviour.

Warning: do not call debconf-communicate from a package maintainer script for a package that uses debconf. The installed manual explicitly warns against it. Maintainer scripts should use the package's supported debconf integration. This command is for controlled debugging and inspection.

The examples above need no undo, because GET, FGET, METAGET and VERSION only read or negotiate. If you have already run a state-changing command, stop and look up the package's documented recovery procedure rather than guessing with RESET.

Done means