Reconfigure a Package Safely with dpkg-reconfigure

dpkg-reconfigure reopens the debconf questions an installed package already answered. It is exactly how people accidentally change a server's time zone at 2am while meaning to check one setting. Allow about ten minutes for a familiar package, longer if its prompts touch networking, locale, time zone or a running service.

You need a shell, an installed package that uses debconf, and an account that can use sudo when its configuration files require root. The examples use the locally installed debconf package version 1.5.86ubuntu1 and the installed tzdata package as a concrete stand-in. Your own prompts and defaults can differ.

1. Check the command and package first

Start with read-only checks. This confirms the command on your PATH and that the package name is actually installed, before you hand it to anything privileged:

$ command -v dpkg-reconfigure
/usr/sbin/dpkg-reconfigure
$ dpkg-query -W -f='\${Status} \${Version}\n' tzdata
install ok installed 2026c-0ubuntu0.24.04.1
$ dpkg-reconfigure --help
Usage: dpkg-reconfigure [options] packages
...

The help text shows the shape: options, then one or more package names. Do not point dpkg-reconfigure at a package that is absent, half-installed, or never designed to ask debconf questions in the first place. Check its state before trying to fix anything.

2. Know what the ordinary command actually does

The basic form is:

$ sudo dpkg-reconfigure PACKAGE_NAME

Replace PACKAGE_NAME with an installed package, for example:

$ sudo dpkg-reconfigure tzdata

This asks the package to revisit its configuration questions, much as it did during installation. By default, dpkg-reconfigure shows every question, including ones already answered, and normally includes low-priority ones too. That is why a package you know well can suddenly ask more than you remember.

There is a real state change here. A completed prompt sequence can rewrite configuration files and run the package's own configuration scripts. For tzdata, a new time zone touches timestamps and any application reading the system time zone. Do not run a reconfiguration mid-change-window unless you already know which services and users depend on the result.

3. Choose the frontend deliberately

The frontend controls how debconf asks its questions. The installed manual documents -f TYPE and --frontend=TYPE. On a local terminal the default is usually an interactive dialog; a text-only session can request readline explicitly:

$ sudo dpkg-reconfigure --frontend=readline tzdata

Force a frontend that needs a display and it will fail, or leave you stuck in an unusable session. Pick one the terminal you are actually using can support. The frontend decides how questions are presented, never what the package's answers are.

One genuinely confusing case: the manual states that dpkg-reconfigure switches to the dialog frontend when debconf is normally set up for noninteractive operation, precisely so reconfiguration stays interactive. Do not assume a noninteractive system-wide default means this command will silently accept every answer for you.

4. Limit the questions, with a clear reason

Use --priority=VALUE, or its short form -pVALUE, to set the minimum priority displayed:

$ sudo dpkg-reconfigure --frontend=readline --priority=medium tzdata

Higher minimums mean fewer questions, which can make a long session manageable but can just as easily hide the one setting you meant to change. The command deliberately shows low-priority questions by default, so do not add --priority=medium purely to make the screen shorter.

--default-priority uses the configured default priority instead of forcing the normal low-priority behaviour:

$ sudo dpkg-reconfigure --default-priority tzdata

These are two different decisions. Use a threshold once you have decided lower-priority questions are out of scope; use --default-priority when you want the host's own debconf policy to decide instead. Want to see everything? Leave both out.

5. Revisit only unseen questions, when that is the actual intent

--unseen-only, or -u, asks only questions not yet seen, useful for finishing an interrupted first configuration, but the wrong tool for revisiting an old answer:

$ sudo dpkg-reconfigure --frontend=readline --unseen-only PACKAGE_NAME

Do not pair --unseen-only with an expectation that every setting will be offered again. If a question is already marked seen, the command can finish without showing it at all. For a deliberate review, drop --unseen-only and read every prompt.

Only want to inspect the current debconf values, without starting a reconfiguration? The manual suggests debconf-show PACKAGE_NAME:

$ debconf-show tzdata

That is a read-only inspection step. Its output is not a substitute for checking the package's effective configuration files, or the running service that actually consumes them.

6. Verify the result, then recover carefully

Record the exit status the moment the command returns:

$ printf 'dpkg-reconfigure status: %s\n' "$?"
dpkg-reconfigure status: 0

Status 0 means the command completed, nothing more. It does not prove you picked the intended answer, or that every dependent service reloaded it. Re-check the package's documented configuration, then the specific consumer. For the time zone example:

$ timedatectl status
$ date

The exact output depends on the host; look for the expected time zone and a sensible local time. A successful exit status is not proof an application has already re-read its configuration.

Use --force only once you have confirmed the package is genuinely inconsistent or broken, and you understand the risk; the manual is explicit that it forces reconfiguration in that state. --no-reload similarly prevents template reloading and can stop the command repairing a broken templates database. It exists for constrained environments where rewriting templates is expensive, not as a general speed option.

7. Keep the operation narrow

You can name more than one package, but only when they form one planned change:

$ sudo dpkg-reconfigure --frontend=readline PACKAGE_ONE PACKAGE_TWO

More packages means more chances to change system state and lose track of which prompt caused which effect later. Reconfigure one, verify it, then move on. Keep the terminal output in your change record whenever the setting touches a production host.

If the command reports a broken package, stop and inspect the package manager state before adding --force. A forced configuration can make a difficult recovery genuinely harder. Resolve the underlying dependency or package error through your normal Debian package-management procedure, then retry the ordinary command.