File an Apport Bug Report from a Linux Terminal

apport-cli builds an Ubuntu bug report entirely from the terminal: pick a package or process, save it, and review before anything uploads. The examples use apport-cli from Apport package version 2.28.3-0ubuntu0.1 on the machine used for this guide.

Allow about fifteen minutes. You need a shell and a package or process you can identify. A report can contain system details, package versions, logs and data about a process, so read it before sending, and never paste real private paths or customer data into a public bug.

1. Check the installed command

Start with read-only checks. None of these need elevated privileges, and they confirm which executable and package you are actually using:

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

Read the local manual as well as the command's own help. On this installation, the help calls the update operation --update-bug, while the manual documents --update-report. The short option -u sidesteps that ambiguity entirely when you need that operation:

$ apport-cli --help
usage: apport-cli [options] [symptom|pid|package|program path|.apport/.crash file]
$ man apport-cli

2. Decide whether you are reporting a crash or a bug

Apport handles pending crash reports, non-crash package problems, running processes, and saved .crash or .apport files. With no options at all, it works through pending reports from /var/crash/ one by one:

$ apport-cli

That is an interactive workflow, and it may offer to send existing reports, so do not run it blindly on a production host. If you already know the report file, name it for a narrower target:

$ apport-cli /path/to/problem.crash

Stick to a path ending in .crash or .apport. Treat the file as sensitive evidence: copying it to another machine can leak usernames, paths, environment details or excerpts from application data.

3. Save a package report instead of sending it

For a problem that is not a crash, use file-bug mode and name the affected package. The save option collects the report into a local file instead of firing it off immediately:

$ apport-cli --file-bug --package PACKAGE_NAME --save /tmp/PACKAGE_NAME.apport

Swap in the Debian package that actually owns the faulty component for PACKAGE_NAME. Apport will ask interactive questions and pull together operating-system and package-version context. This example writes the file under /tmp, so lock it down from other users per your host's policy, and remove it once reviewed.

$ test -s /tmp/PACKAGE_NAME.apport && echo 'report saved'
report saved
$ ls -lh /tmp/PACKAGE_NAME.apport

If the package name is uncertain, do not guess: the manual also supports symptom scripts, which ask questions and select a package for you. List them by starting file-bug mode without a package, or name one explicitly with --symptom:

$ apport-cli --file-bug
$ apport-cli --file-bug --symptom SYMPTOM_NAME --save /tmp/symptom-report.apport

Available symptoms come from /usr/share/apport/symptoms/*.py and vary by installation. If none exist, the first command just stops with an error.

4. Include a running process only when it helps

A process report can add real context while a program is actively misbehaving. Find its PID without changing anything first:

$ ps -ux
$ apport-cli --file-bug --package PACKAGE_NAME --pid PID --save /tmp/process-report.apport

Swap in the numeric process ID for PID. The process may get inspected while the report is collected, and the result can carry more information than a package-only report would. Get the owner's approval before collecting from someone else's process, and steer clear of this route for secrets or sensitive workloads unless your incident process explicitly allows it.

Do not reach for a PID just because the program happens to be running. For a crashed process, use the matching pending crash report instead. For a hung one, the installed command also accepts --hanging in file-bug mode, but only when the program is genuinely stuck, not as a generic extra flag.

5. Review the saved report before uploading

Inspect the file as text where practical, but expect some fields to run long:

$ less /tmp/PACKAGE_NAME.apport
$ file /tmp/PACKAGE_NAME.apport

Look for private usernames, home-directory paths, command-line arguments, hostnames, log excerpts, tokens and customer identifiers. Do not touch it with a blind search-and-replace: changing the structure can make it unusable. If it holds data that cannot be shared, stop and use your organisation's redaction or bug-report process instead.

Once the contents are fit for the project's bug tracker and the machine has the network access it needs, report the saved file explicitly:

$ apport-cli --crash-file /tmp/PACKAGE_NAME.apport

This is the point where an upload or interactive submission can actually happen. Read every prompt. A successful command does not mean the report was safe to disclose, only that Apport finished its workflow.

6. Update an existing report carefully

Apport can collect fresh information for an existing report number. This changes the report's workflow and may contact the bug tracker, so double-check the number before you start:

$ apport-cli -u REPORT_NUMBER

The affected package is pulled from the existing report by default. If the report was filed against the wrong package, the manual allows an explicit one:

$ apport-cli -u REPORT_NUMBER --package PACKAGE_NAME

Use a real report number in place of REPORT_NUMBER. Do not treat -u as an undo: it adds information, it does not retract an uploaded report. If you started the wrong interactive action, use its own cancellation choice and check the tracker separately.

7. Handle obsolete-package checks and permissions

Apport normally refuses to create a report when the package or one of its dependencies is obsolete. The APPORT_IGNORE_OBSOLETE_PACKAGES environment variable bypasses that check:

$ APPORT_IGNORE_OBSOLETE_PACKAGES=1 apport-cli --file-bug --package PACKAGE_NAME --save /tmp/obsolete-package.apport

Use this only after checking the package state yourself. It is not a repair command, and it can produce a report against a problem already fixed by an update. Do not drop the setting permanently into your shell startup file unless you understand the reporting policy it changes.

Most read-only checks and report collection run fine as the invoking user. Reach for elevated privileges only when the command explicitly says it cannot read a required file or pending report, and never use sudo to work around an unknown package, an unsafe disclosure decision, or a missing symptom script.

8. Clean up a temporary saved report

Once the report has been reviewed and either submitted or retained per your incident process, remove the temporary copy if it is no longer needed:

$ rm -- /tmp/PACKAGE_NAME.apport