apport-cli (1)
NAME
apport-cli, apport-gtk, apport-kde - Apport user interfaces for reporting problems
SYNOPSIS
apport-cli
apport-cli [ --save file ] symptom | pid | package | program path | .apport/.crash file
apport-cli -f
apport-cli -f -p package -P pid
apport-cli -u report-number
Same options/arguments for apport-gtk and apport-kde.
DESCRIPTION
apport automatically collects data from crashed processes and compiles a problem report in /var/crash/. This is a command line frontend for reporting those crashes to the developers. It can also be used to report bugs about packages or running processes.
If symptom scripts are available, it can also be given the name of a symptom, or be called with just -f to display a list of known symptoms.
When being called without any options, it processes the pending crash reports and offers to report them one by one. You can also display the entire report to see what is sent to the software developers.
When being called with exactly one argument and no option, apport-cli uses some heuristics to find out "what you mean" and reports a bug against the given symptom name, package name, program path, or PID. If the argument is a .crash or .apport file, it uploads the stored problem report to the bug tracking system.
For desktop systems with a graphical user interface, you should consider installing the GTK or KDE user interface (apport-gtk or apport-kde). They accept the very same options and arguments. apport-cli is mainly intended to be used on servers.
OPTIONS
- -f, --file-bug
-
Report a (non-crash) problem. If neither
--package,
--symptom,
or
--pid
are specified, then it displays a list of available symptoms. If none are
available, it aborts with an error.
This will automatically attach information about your operating system and the package version etc. to the bug report, so that the developers have some important context.
- -s symptom, --symptom=symptom
-
When being used in
--file-bug
mode, specify the symptom to report the problem about.
- -p package, --package=package
-
When being used in
--file-bug
mode, specify the package to report the problem against.
- -P pid, --pid=pid
-
When being used in
--file-bug
mode, specify the PID (process ID) of a running program to report the
problem against. This can be determined with e. g.
ps -ux.
- -c report, --crash-file=report
-
Upload a previously processed stored report in an arbitrary file location.
This is useful for copying a crash report to a machine with internet
connection and reporting it from there. Files must end in
.crash
or
.apport.
- -u report-number, --update-report report-number
-
Run apport information collection on an already existing problem report. The
affected package is taken from the report by default, but you can explicitly
specify one with --package to collect information for a different package
(this is useful if the report is assigned to the wrong package).
- --save filename
-
In --file-bug mode, save the collected information into a file instead of
reporting it. This file can then be reported with --crash-file later on.
- -w, --window
-
Point and click at the application window against which you wish to report
the bug. Apport will automatically find the package name and generate a report
for you. This option can be specially useful in situations when you do not know
the name of the package, or if the application window has stopped responding
and you cannot report the problem from the "Help" menu of the application.
ENVIRONMENT
- APPORT_IGNORE_OBSOLETE_PACKAGES
-
Apport refuses to create bug reports if the package or any dependency is not
current. If this environment variable is set, this check is waived. Experts who
will thoroughly check the situation before filing a bug report can define this
in their
~/.bashrc
or temporarily when calling the apport frontend (-cli, -gtk, or -kde).
FILES
- /usr/share/apport/symptoms/*.py
-
Symptom scripts. These ask a set of interactive questions to determine the
package which is responsible for a particular problem. (For some problems like
sound or storage device related bugs there are many places where things can go
wrong, and it's not immediately obvious for a bug reporter where the problem is.)