On Thu, 2010-07-08 at 14:40 +0200, Karel Klic wrote:
On 07/07/2010 03:28 PM, Denys Vlasenko wrote:
> 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.]
Writing a simple abrt-networksocket daemon doing the same thing as
abrt-dbus would allow us to report crashes from client servers to the
collecting server DIRECTLY, without storing them on the machine where a
program crashed, right?
The tools would just connect not to the local abrt-server, but to the
remote server via TCP and abrt-networksocket on the master server side.
This seems like the proper design for master-slave ABRT to me.
abrt-server does not know where its input/output comes from. It can well
be a TCP socket. Thus, no new program is needed. abrt-server can do it.
Just slap the authentication on it, and it should fill this role.
--
vda