Run Programs Under debconf with the Right Frontend

When a program speaks the debconf protocol, plain sh tricks will not show you what it is asking, and debconf is the wrapper that does. The examples match debconf 1.5.86ubuntu1, installed here as package debconf, and take about fifteen minutes.

You will launch a debconf-aware program repeatably, choose how its questions appear, and collect diagnostics when the wrapper misbehaves.

1. Check the installed command

Start with read-only checks. They confirm which executable your shell will find and which package supplied it:

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

The installed manual describes the command as a runner for a debconf-using program. It connects that program to debconf on standard input and output, so the child must emit debconf protocol commands, not ordinary human-facing prompts. A shell script that merely prints text is not a suitable test.

Checkpoint: you should have a command name or path for a real debconf-aware program. The wrapper also needs the command to be findable through PATH, so a bare name only works when its directory is on it.

2. Start a harmless command first

Use /bin/true for a launch check. It needs no input, prints nothing and exits successfully. The non-interactive frontend avoids a terminal prompt in automation:

$ debconf --frontend=noninteractive /bin/true
$ printf 'exit status: %s\n' "$?"
exit status: 0

Zero proves this invocation completed. It does not prove a real package's questions, ownership or database operations are correct.

Tip: if the debconf database is not writable by your user, you may also see a database permission warning. Do not make the database writable just to silence a wrapper smoke test.

No undo needed. The command is a child process, and the wrapper leaves no persistent configuration behind when it exits.

3. Choose the frontend on purpose

The --frontend=type option selects the interface debconf uses for questions. The type is not a command name. For an interactive terminal test, the manual gives this pattern:

$ debconf --frontend=readline sh -x my-shell-prog

Replace my-shell-prog with your debconf-aware program. The sh -x form helps when that program is a shell script: the shell prints each command as it runs while debconf handles the protocol conversation. Run it in a terminal, because the readline frontend expects one.

For unattended work, use --frontend=noninteractive and test the program's documented defaults first. A non-interactive run can finish happily while accepting defaults that are wrong for your service. That is a configuration decision, not proof the job is safe.

4. Limit which questions appear

Use --priority=value to set the minimum question priority debconf displays:

$ debconf --frontend=readline --priority=high my-shell-prog

In the long form the value attaches straight to the option, as shown. The setting filters out questions below the threshold. It does not answer every question with a value you have reviewed, and it does not change the package's stored answers. If an expected question vanishes, lower the threshold only after checking the program's configuration plan.

The short spelling is -pvalue. Likewise -freadline selects a frontend and -opackage names the package that owns the questions. Long options are easier to audit in scripts, so prefer them unless you are matching an existing command line.

5. Set the question owner for package commands

Use --owner=package when the wrapped command belongs to a Debian package:

$ debconf --owner=example-package --frontend=noninteractive example-command

The owner matters for registered questions, including later unregister and purge operations. Replace both placeholders with the package and command you have actually inspected. Do not guess an owner from a similarly named executable. For a local diagnostic script that is not a package component, leave the option out unless its documentation names a real package owner.

Warning: this option can affect persistent debconf question ownership, depending on what the child asks debconf to register. Before using it on a package you manage, record the existing package state, and undo a mistake through the package's normal reconfiguration or removal procedure. Never run an ownership experiment against a production package during a service change.

6. Turn on developer diagnostics

When a debconf-aware shell script holds an unexpected conversation, set DEBCONF_DEBUG=developer for that one invocation:

$ DEBCONF_DEBUG=developer debconf my-shell-prog

The setting lasts only for that process. It shows the protocol exchange while you trace the script, but the output may include question text or values. Keep it out of shared logs if those values could expose secrets or personal data.

If the script itself is the confusing part, combine the manual's two diagnostic techniques:

$ DEBCONF_DEBUG=developer debconf --frontend=readline sh -x my-shell-prog

Check the exit status afterwards, then read the trace and debug output. A non-zero status belongs either to the wrapped command or to debconf, and the trace helps you tell which.

7. Keep common failures in their lane

If debconf says it cannot find the command, check PATH and the executable name before reaching for sudo:

$ command -v my-shell-prog
$ printf 'PATH=%s\n' "$PATH"
$ printf 'exit status: %s\n' "$?"

An empty result from command -v means the shell cannot resolve that name. Use the program's documented absolute path only after confirming it exists and is executable. Root privileges do not fix a misspelled command.

If an interactive frontend fails in a service, cron job or redirected session, switch to a deliberately tested non-interactive configuration.

Warning: if a non-interactive run picks an unsafe default, stop the deployment and fix the package configuration. Do not lean on --terse. Terse mode changes output for some frontends, but it does not turn an interactive program into a safe unattended one.

Done means