On Thu, 2010-07-08 at 18:27 +0200, Karel Klic wrote:
On 07/07/2010 03:28 PM, Denys Vlasenko wrote:
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-applet Provides GUI notification icon and launcher for abrt-gui
Currently abrt-applet shows the "application crashed" bubble after receiving a DBus message. Since only abrt-server knows about every new crash, how would it inform abrt-applet about it?
Should abrt-server start abrt-dbus? That way the DBus independence would be lost.
It's more like "abrt-server or abrt-handle-crashdump should execute actiona as configured. If we want dbus signal, then we can configure it to be emitted:
# event type cmd [params] post-create * abrt-action-dbus-signal # and if we want to know about uploaded (i.e., remote) crashes: post-upload * abrt-action-dbus-signal
IIRC dbus package has a command line tool, dbus-send, which can emit dbus signals, maybe we can use it directly instead of abrt-action-dbus-signal, or abrt-action-dbus-signal can be a shell script which uses that tool. Of course it can also be a small C program.