[rsyslog] desktop notifications from syslog

[Tom Metro]

david at lang.hm wrote:
> Tom Metro wrote:
>> A first cut would provide only
>> a single DBus operation - subscribe to events.
> 
> 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?

The client-server relationship may be inverted from what you expect.

The proposed architecture is something like this:

rsyslog output plugin w/DBus interface
   ^
   | DBus
   |
syslog-notify
   |
   | DBus session bus
   V
notification daemon

Here the 'syslog-notify' "glue" daemon runs under the user's X session, 
establishes a connection to rsyslog via DBus, and subscribes to events.

That way the output plugin could support multiple subscribers, each 
eventually with their own topic/channel, and could be a no-op if there 
are no subscribers.


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

This is what I was referring to:

http://www.rsyslog.com/doc-rsyslog_conf_actions.html
   Output Channel

   Binds an output channel definition (see there for details) to this
   action. Output channel actions must start with a $-sign, e.g. if you
   would like to bind your output channel definition "mychannel" to the
   action, use "$mychannel". Output channels support template definitions
   like all all other actions.

And explained further here:
http://www.rsyslog.com/doc-rsyslog_conf_output.html

which clarifies that this isn't quite what I thought it was. I was 
thinking it was a way of assigning a name to a set of selector rules, 
which could then later be directed to one or more outputs.

If such a thing existed, then conceivably it would be useful to permit a 
DBus subscriber to specify the particular filtered channel of data it 
wished to subscribe to.

Of course it might also be useful to allow DBus subscribers to specify 
an arbitrary selector pattern. (Though this raises security 
complications, as you don't want all syslog data to be readable by any 
local user.)


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

In many cases I observed sysklogd closing the pipe resulting in a loop 
in the reader process checking for EOF to exit. Perhaps that's normal 
and expected. That's easy enough to deal with. In at least one case I 
observed that after such an exit, when the reader was restarted, it 
failed to receive any new messages until sysklogd was restarted, 
suggesting it had closed the pipe and failed to reopen it when the next 
applicable message was processed.

But my testing with named pipes has been too limited to draw any firm 
conclusions. I need to get the syslog broadcast problem resolved (which 
I discussed in another thread), as that's part of the overall system I'm 
setting up that would make active and regular use of these desktop 
notifications, and permit longer term testing.


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

Does it differ from sysklogd in that respect, or does it not block if 
the pipe is closed (no reader running)?

  -Tom