[rsyslog] desktop notifications from syslog

[Tom Metro]

Rainer Gerhards wrote:
> I really like the idea...and think that it is also the solution
> to some other things I have on my mind (like a way to get rsyslogd internals
> via the GUI, that would at least for debugging and probably for a couple of
> other things be useful).
...
> What I have on my mind is a kind of interactive interface, where, in
> real-time, you can see things like queue saturation, modules loaded, maybe
> generate test events and so on. That's my debug case. Of course, some
> interactive features may be interesting for regular end user

Are those kinds of internals accessible from an output plugin? If not, 
then either the "subscribe to events via DBus" functionality would need 
to be implemented in the core code, or these might be two independent 
projects.

I see you have an SNMP interface. I wonder if that has some common 
ground with the functionality you're describing. Layering the SNMP 
interface on the DBus interface, or just having both use a common 
middleware with two different front-ends.


> In any case, however, this sounds like a lot of work (that being the reason I
> did not yet start the effort).

It can aways be approached incrementally. A first cut would provide only 
a single DBus operation - subscribe to events. What events would be 
entirely controlled by where the output module was specified in the 
config file, and you'd probably be limited to only one occurrence of 
that module in the config.

An incremental enhancement might be to permit the DBus client to specify 
a named channel it wishes to subscribe to. (I recall seeing something 
about named channels in the rsyslog documentation. Not sure if they'd be 
applicable here.)


> So while I would consider this approach technically inferior, I'd
> still take the route to create a libnotify output, where the users
> has the burden of correct configuring the params, if that can be done
> in a couple of hours.

The quick hack might actually be to go back to my original approach of 
using a named pipe for the first leg of IPC, with the hope that rsyslog 
handles pipes more reliably (or I can figure out why they appeared not 
to work reliably with sysklogd; I assume xconsole users would have 
noticed if this mechanism was unreliable). Then use Michael Biebl's 
technique of running the client from the user's X session so you don't 
have to go through hoops to get connected to the right desktop. (I 
already have a Perl script that implements this, I just need to launch 
it from within the X session.)

This is basically the same setup as xconsole, just a different UI.


> That, of course, would need to run on a large async queue, because it
> has the potential of blocking rsyslog and in consequence the system
> as whole (I assume that's not an issue with DBus).

I'm curious to know if rsyslog will block if it fills the buffer going 
to the named pipe, in much the same way it can block if the shell 
execute process hangs?

I'm assuming not, as I've seen syslog.conf's that write to 
/dev/xconsole, and ran fine despite there being no xconsole on the 
system servicing the pipe.

  -Tom