[rsyslog] desktop notifications from syslog

[david at lang.hm]

On Mon, 4 May 2009, Tom Metro wrote:

> 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 think there would be two independant projects

1. provide output to dbus

2. create a dbus management interface to query internal stats

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

I have not looked at the rsyslog snmp interface, but I assumed that it 
sendt and/or recieved snmp trap messages, not queried rsyslog internal 
stats.

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

the term 'subscribe to events' sounds to me like it recieves messages 
others send. in this case it needs to be generating events that others 
would subscribe to. am I just confused by the terminaology here?

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

rsyslog does not have named channels internally.

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

I have been using named pipes extensivly with both rsyslog and sysklogd, 
what problems were you having?

> 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?

yes rysyslog would block, although you could create a action queue for 
that activity to keep that blockage from blocking all of rsyslog (and you 
may be able to use reinerscript to put logic in place to throw away 
messages if the queue is full, I don't know if the info needed to do this 
is available at this time)

David Lang

> 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
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
>