[rsyslog] desktop notifications from syslog

[david at lang.hm]

On Mon, 4 May 2009, Tom Metro wrote:

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

I think the best way to do this is for the rsyslog output plugin to not 
worry about who's listening. it just takes anything that the rsyslog rules 
tell it to forward and sends it to DBUS.

at that point it's up to the admin to deal with the security issue about 
what's going to be visable

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

I'll look into this a bit later tonight

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

you don't want to try and have dbus users push rules through dbus to 
rsyslog. they can choose to ignore some of the stuff that they get, but 
you don't want to go further than that.

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

this is correct. applications reading from pipes like this can't assume 
that a EOF means that they should exit (unless you wrap them with 
something to restart them)

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

hmm, I haven't had that problem. I wonder if the process was down long 
enough for the pipe to fill up and sysklog to decide there was a problem 
and stop writing to that pipe (some versions would do that instead of 
blocking)

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

what I'm doing for the syslog broadcast is defining a multicast MAC 
address for a specific IP, and then setting that IP address up on all the 
systems that need to see the message. (see 
http://www.linux-ha.org/ClusterIP for info on this and examples of how to 
set it up for testing) this lets me spread the load between multiple 
machines in one set while still having multiple sets of boxes recieve the 
same message.

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

I don't know.

David Lang