Hi,
I was brainstorming a bit about future direction for abrt.
Here are my haphazard design notes.
What I want to change in abrt compared to current design?
* I want to simplify long-running processes (ideally I'd like
to eliminate them, but this might be impractical),
and do most of the complex work in short lived, separate
processes. Resource leaks are hard to weed out,
this way, they will be more manageable
* I want different reporting steps to be easier to debug
individually
* I want to make it more configurable without adding ad-hoc
options for every imaginable thing to abrt.conf
* I want to make it possible for third-party packages to add
their own processing for crashes in their packages
* I don't want to require dbus
Here is a tentative list of programs I came up with,
with descriptions what they do:
abrtd [-dsvvv]
Installs abrt-hook-ccpp as userspace core dumper.
Waits for socket connections (used by e.g python crashes,
can be extended to accept remote dumps?),
then spawns abrt-server for accepted connection.
Also waits using inotify for new archives to appear
in upload directory, then spawns abrt-handle-upload.
Also waits on specified log files (used for kerneloops,
X server crash detection, etc) and when a suspicious change
is detected [regex match?], spawns abrt-plugin-FOO
to process it.
Options:
-d Do not daemonize
-s Log to syslog even with -d
-v Verbose
abrt-hook-ccpp
Exec'ed by kernel. Creates new crashdump directory,
then exec's abrt-handle-crashdump.
abrt-plugin-kerneloops ABRT_DIR [-i INFILE] [-o OUTFILE]
Processes given syslog file, creates crashdump(s) and spawns
abrt-handle-crashdump for each found oops.
abrt-handle-upload ABRT_DIR UPLOAD_DIR ARCHIVE
Processes given crashdump archive: checks and unpacks it,
then exec's abrt-handle-crashdump.
abrt-applet
Provides GUI notification icon and launcher for abrt-gui
abrt-cli/gui [-v]
User interface. +Web interface, anyone?
abrt-dbus [-dsvvv] [-t SEC]
Autostarted by client (abrt-cli/gui/etc).
Waits for dbus commands, for every new dbus client spawns
a copy of abrt-server.
After this, pipes dbus client commands to abrt-server's
stdin and pipes abrt-server's output to dbus client.
If no child abrt-server's are running and no new dbus commands
are coming, exits after a timeout.
dbus cmds:
GetCrashInfos (no params)
StartJob crash_id force
Report map_crash_data reporters user_conf_data
DeleteDebugDump crash_id
CreateReport crash_id
GetPluginsInfo (no params)
GetPluginSettings PluginName
SetPluginSettings PluginName plugin_settings
GetSettings (no params)
SetSettings map_abrt_settings
Options:
-d Do not daemonize
-s Log to syslog even with -d
-v Verbose
-t SEC Exit after SEC seconds of inactivity
abrt-server [-dsvvv] [-t SEC] ABRT_DIR
If run from abrtd:
Reads data from stdin and creates new crashdump directory,
then spawns abrt-handle-crashdump.
If run from abrt-dbus:
Reads data from stdin and performs requested ops.
[Rationale for separate process: easy to debug,
easy to prevent resource leaks in abrtd/abrt-dbus,
easy to implement connection timeout, does not need to link
against dbus libs, can be used with e.g. network connection.]
Creating new crashdump:
EXECUTABLE=asciz
BACKTRACE=asciz
BASENAME=asciz
ANALYZER=asciz
REASON=asciz
PID=asciz
DONE
Dbus ops:
CreateReport crashdump_dir - preparing crashdump (generate backtrace etc):
DeleteDebugDump crashdump_dir
Report crashdump_dir reporter user_conf_data
Note: not a lot of configurability is needed for the above programs -
they do basically the same processing for all use cases.
abrt-handle-crashdump DIR [PARAMS]
Processes given crashdump directory.
[Best to implement as shell script, to make it easier to set up
custom processing? this way, sosreport, filetransfer/ticketuploader
plugins are no longer needed - they can be easily implemented
in shell script]
STAGE: created / uploaded / collectinfo / report / ...
abrt-plugin-ANALYZER
Do we need separate programs for this?
abrt-plugin-REPORTER (bugzilla,rhtsupport)
Used by abrt-handle-crashdump to interface to bug databases.
abrt-backtrace
abrt-debuginfo-install
===============================================================
How to configure abrt-handle-crashdump?
conf file?
# stage [env vars] cmd [params]
uploaded abrt-action-get-build_ids
uploaded abrt-action-generate-backtrace
created abrt-action-upload ftp://user:pass@host/dir
created abrt-action-sosreport
collectinfo abrt-action-sosreport
collectinfo abrt-action-get-build_ids
collectinfo abrt-action-debuginfo-install
collectinfo FORCE=1 abrt-action-generate-backtrace
report abrt-action-bugzilla
https://bz-web1-test.devel.redhat.com/
report abrt-action-logger
report user_custom_shell_script
other ideas?
===============================================================
For reference, abrt1 plugins are:
Bugzilla.cpp
CCpp.cpp
FileTransfer.cpp
Kerneloops.cpp
KerneloopsScanner.cpp
Logger.cpp
Mailx.cpp
Python.cpp
RHTSupport.cpp
RunApp.cpp
SOSreport.cpp
ReportUploader.cpp