On 07/09/2010 01:30 PM, Denys Vlasenko wrote:
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.
How can we handle that only a non-report or a first occurred crashes will be notify
by bubble? I have an one RFE for this.