File a Better Ubuntu Bug Report with apport-bug

apport-bug walks you through filing an Ubuntu bug against the right symptom, package, process or crash file, then lets you send or save it. Allow 10 to 20 minutes for a normal report, plus time to actually read the collected details before you submit anything. This guide describes the installed apport package version 2.28.3-0ubuntu0.1, whose command reports version 2.28.3.

1. Check the installed command

Run these checks as your ordinary user. You do not normally need sudo to collect a report from your own desktop session.

$ command -v apport-bug
/usr/bin/apport-bug
$ apport-bug --version
2.28.3
$ dpkg-query -W -f='${Package} ${Version}\n' apport
apport 2.28.3-0ubuntu0.1

The command can open a graphical client if it finds a KDE or GNOME session, and falls back to the command-line client without one. That means the next screen depends entirely on where you run it, so keep a terminal handy even on a desktop.

2. Start with the symptom chooser

Run apport-bug with no argument first. The installed manual recommends this because the symptom list can steer you to a more useful reporting path than a guessed package name would.

$ apport-bug

Pick the symptom that matches the failure, then read every proposed report section before you send anything. The report can contain system details, package information, logs and other local data: treat it as potentially sensitive, and strip out private paths, account names or anything else that does not belong in a public bug report, wherever the client lets you review it first.

Checkpoint: you should know which symptom or component the report targets before you approve submission. If none of the listed symptoms fits, cancel and use a specific target in the next step instead.

3. Target a package or programme

Pass a package name when you already know which installed component is broken; a programme path works too. Both of these just start the reporting workflow, they will not silently file anything without your say-so:

$ apport-bug firefox
$ apport-bug /usr/bin/unzip

Prefer the package name over an arbitrary command name where you can. For a kernel problem, the special target linux means the currently running kernel, so you never have to type its full installed package name:

$ apport-bug linux

Do not guess if the failure spans several packages. Start with the symptom chooser instead, or check which package owns the executable with your normal package-management tools. A report aimed at the wrong package just adds noise and delays triage.

4. Add a process ID for a live failure

When a running programme is misbehaving, give Apport its process ID. Identify the process first, without changing anything:

$ pidof gnome-terminal
5139
$ apport-bug 5139

Swap in the PID you actually checked for 5139. A PID can be reused the moment a process exits, so run pidof or another read-only check immediately before starting the report, not five minutes earlier. If the application is stuck rather than crashed, the installed command also supports --hanging alongside the PID:

$ apport-bug --hanging 5139

This route can collect information about the process and its environment. Review that data carefully before sending it, especially if the process was handling customer records, tokens or other private documents.

5. Work with an existing crash file

Apport stores crash files in /var/crash by default, and also accepts a previously saved Apport file. Pass the exact readable path rather than copying the crash file somewhere new first:

$ ls -l /var/crash
$ apport-bug /var/crash/_bin_bash.1000.crash
$ apport-bug /tmp/apport.firefox.332G9t.apport

Those names are illustrative: use a file that actually exists on your machine, and never open or submit a crash file belonging to another user without authorisation. Crash files are not normally removed after submission; the manual says an automated cleanup only removes files after seven days, so decide whether to keep or delete them according to your own retention and privacy rules.

6. Save the collected report instead of sending it

Reach for --save when the affected machine cannot reach the bug tracker, when someone else needs to review the report first, or when you just want to move the collected data to a different machine. Choose a temporary path with restrictive permissions where it matters:

$ apport-bug --save /tmp/apport-firefox-report.apport firefox
$ ls -l /tmp/apport-firefox-report.apport

The file contains collected system information and may be sensitive: copy it only through a channel you trust, and remove it once the recipient confirms it is no longer needed. That removal is irreversible, so double-check the path before running a cleanup command:

$ test -f /tmp/apport-firefox-report.apport && echo "saved report exists"
$ rm -- /tmp/apport-firefox-report.apport

If you need the saved file later, pass its path to apport-bug on the reporting machine. The manual also points to apport-cli as an alternative command-line client, though this guide does not assume that one is installed.

7. Update an existing bug

Use the apport-collect alias with the bug report number when developers ask for more information on a report that already exists. This adds Apport data to that report instead of opening a new one:

$ apport-collect 1234567

Swap in the real report number for 1234567. The aliases ubuntu-bug and apport-collect point at the same installed reporting family, but use apport-collect for an update so the intent is obvious when you look back through shell history.

Checkpoint: use apport-bug for a new report and apport-collect for extra information on an existing one. Do not open a duplicate just because the first report needs more diagnostics.

8. Handle an obsolete-package refusal

Apport refuses to create a report when the target package or one of its dependencies is not current. The normal fix is to update the system through your usual, trusted package-management process, then try again. Do not bypass the check just to make the command proceed: a stale package can make a report much harder to reproduce.

The command recognises APPORT_IGNORE_OBSOLETE_PACKAGES as an override. The manual reserves it for experts who will check the package state themselves; if you genuinely need it, keep the override to a single invocation so it cannot silently affect future reports:

$ APPORT_IGNORE_OBSOLETE_PACKAGES=1 apport-bug PACKAGE_NAME

Replace PACKAGE_NAME with the affected package. This is a security and diagnostic boundary, not a general fix: record why you used the override in the report, and verify the installed versions separately.

Done means