ABRT 2.0 architecture
- programs / libraries which are invoked at the moment when problem occurs
- the mechanism of invocation is problem-dependent
- when invoked, they create a new problem directory in $COREDUMPDIR and store problem data in it
- hook examples:
- runs all the time (this may be changed in a future version)
- listens on /var/run/abrt.socket for problem notifications
- runs "post-create" events on new problem directories. Useful for
- automatically collecting additional information very soon after the crash
- if the machine is running unattended, or admin doesn't want users to deal with crash reporting (kiosk mode), "post-create" event can be used to report problem automatically, without any user
interaction
- sends broadcast messages over system dbus when a new problem is detected
- accepts requests on Unix domain socket to create new problem directories. This is used by python hook, and likely to be used by perl/java hooks in the future
- accepts requests on Unix domain socket to delete a problem directory (used by GUI/cli when it runs under unprivileged user)
- can be invoked via applet or manually (from menu/cmdline)
- e.g. I have the applet disabled and want to run GUI once a week manually to check for new crashes
- shows the list of problem directories
- allows user to open a problem directory (run a GUI wizard on it), or delete a problem directory
- provides UI to configure parameters passed to event processing
- UI for X-less (or entirely headless) computers, or for technical users
- has --get-list, --report, --delete options etc (use --help to see all)
- does not do any configuration - we expect techies to just tweak *.conf files in /etc/abrt/