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.
--
vda