Stop your package manager from leaving orphaned config files behind

Technical Briefing | 8/4/2026

You run apt remove or dnf remove, the package is gone, and you think that is the end of it. But if you check /etc or your home directories, you will often find stale configuration files lingering like ghosts. This bit me in prod when an old config file caused a daemon to start with deprecated options, leading to a silent failure that took me half a morning to debug.

Why removing the package rarely cleans up the mess

The reality is that most package managers treat config files as user-owned property. They are terrified of deleting files that you might have manually tweaked. If you modify a config file, dpkg marks it as conffile, and even if you purge the package, it often leaves the modified version behind. It is a safety feature that usually works against you during routine maintenance.

dpkg-query -W -f='${Conffiles}\n' package_name | awk '{print $1}' | xargs -I{} sh -c 'if [ -f {} ]; then echo "Stale: {}"; fi'

• Apt purge does more than remove, but it only tracks known conffiles.
• Dnf leaves /etc files alone unless you specifically tell it to clean up the transaction.
• Configuration files created by the binary at runtime never show up in package manifests.

The right approach is to handle these before they pile up. If you are building automated provisioning, rely on configuration management like Ansible to force state instead of hoping the package manager cleans its own house. I have seen directory structures in /etc bloated with hundreds of .dpkg-dist or .rpmsave files, which just makes auditing security rules a nightmare.

Next time you decide to prune your server, stop assuming the package manager knows what it is doing. Verify the filesystem state manually if you are decommissioning a service. You will save yourself from the phantom bugs that wait for you six months down the line.