On 07/07/2010 03:28 PM, Denys Vlasenko wrote:
> 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?
>
Just a quick dump from yestarday:
As Karel said, we need a better way to communicate with the "plugins" and let
users to override some settings ad-hoc, show the settings in UIs, etc...
So what if we remove abrt-handle-crashdump and let abrt-server to handle all of it's
work:
1. parse the config
2. send the actual configuration to UI if necessary
3. run the action(s)
(we can even keep acbrt-handle-crashdump, but in this case all it's work would be to
run action with parameters given by abrt-server)
- so the abrt-server can serve the calls like {Get,Set}PluginSettings
My second proposal is for the config file:
1. store it in /etc/abrt/actions.d/
2. I would vote for some more readable format like XML:
for example:
<action>
<stage>uploaded</stage>
<command>abrt-action-generate-backtrace</command>
<option mandatory="yes">option1</option>
<option default="foo">option2</option
or to avoid attrs
<option>
<name>option3</name>
<default>foobar</default>
<mandatory>yes</mandatory>
</option>
</action>
extending the xml config file should be less painful then adding new column in the
previous table like proposal.
Looking forward for you comments :)
Jirka
> ===============================================================
>
> 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
>