Am Wed, 25 Sep 2013 19:19:32 -0700 (PDT)
schrieb David Lang <[email protected]>:
> On Thu, 26 Sep 2013, Michael Schmitt wrote:
>
> > Hi list,
> >
> > it may sound odd to some, but I had the idea (and from that idea a
> > deep wish embarked) to redirect all logs that arrive
> > in /var/log/messages to a local fdo-compliant notification daemon.
>
> what sort of input does the fdo-compliant notification daemon that
> you are wanting to feed require?
I don't get you, plain text, it could accept html iirc, but I am just
interested in text. As in...
notify-send "Subject" "This\nis\na\test"
-- or --
notify-send "Subject "$(cat textfile.txt)"
(where textfile.txt is a plain text file with multiple lines)
which would pop up a notification that looks like this...
<popup>
-----------------
<b>Subject</b> | # bold and larger font
----------------
This | # ordinary text
is | # with multiple lines
a | # in one popup message
test |
----------------
</popup>
Really nothing special here.
> rsyslog can probably be configured to feed it, but we can't say how
> without knowing what you really want.
I thought I made it quite clear. :/ The shell-code provided in the last
mail would just spawn a notification popup for every single line in a
given textfile or in general any textinput. Basically because "read"
reads line after line and processes each line separately. I'd need some
thing or tool that does read several lines until either no lines arrive
anymore or after a given timeout and processes everything it got that
far. So regarding the format, no issue whatsoever.
> > As
> > rsyslog can be configured to filter the messages, one could even
> > limit the stuff that is sent to the users desktop, but I opted for
> > all for now.
> > Well, easier said than done apparently, as the basic idea is simple,
> > but how I want it seems hard (right next to impossible without
> > coding something in C or something). I save me the humiliation to
> > post what I tried until now in greater detail, but basically what I
> > want is something like this...
> >
> > (oh and I am on Debian GNU/Linux and rsyslogd is configured to log
> > to a named pipe in the example)
> >
> > <code>
> > #!/bin/bash
> > cat /tmp/rsyslog.pipe | while read foo
> > do
> > notify-send "Topic" "${foo}"
> > done
> > </code>
> >
> > BUT (and that is the important part) it should not print one line
> > per notification message but rather in bursts, like the messages
> > from the last few seconds in ONE notification. The overal design
> > idea is something like this:
> >
> > 1.) wait until something is logged, if nothing is logged, do
> > nothing
> >
> > 2.) if something is logged, collect the data for N seconds in a
> > buffer,
> >
> > -- or --
> >
> > if something is logged, collect in a buffer, when logging stops
> > for $TIME
> >
> > -- then --
> >
> > send that buffer via notify-send...
>
> the problem is that when rsyslog sends the data into the pipe,
> sending a lot of messages at once, or pausing between messgaes would
> make no difference to your application.
Ignore the example, it is obviously flawed and does NOT do what I
want. What I want was described in that "1.) 2.) 3.) recipe"
expressed in plain "human logic". Even if I don't see an error in that
"recipe", there might be some, but did you understand the overall idea?
> In addition, as your log volume increases, you will find that you
> never have a time period where no logs are generated, so that logic
> doesn't make sense.
Sure it *could* increase to a point where sending *all* messages would
cause a never-ending-flow of popups. But that is in no way a given
outcome and highly depending on the system where something like that
would be deployed. And of course, the idea to get the messages from
rsyslog *includes* the possibility to filter for only the messages you
want if all and everything is too much at any given point in time or
situation.
And at least for all my desktop computers, it will most likely never
ever happen anyway. The only time where such a never-ending flooding
occured was when something went really really wrong, so wrong that at
that point X or my desktop session was of the least of my concerns, X
has most likely crashed there anyway and with it the
notification-daemon.
More generally, I don't know every system, but every (desktop) system I
use has a rather un-impressive log-volume.
> All this being said, Simple Event Correlator does have the ability to
> save log messages and then output them as part of the alert. It's
> also very straightforward to feed SEC from rsyslog, so I think you
> would want to look there for some of this.
Uhm... I did read into it, but from what I see using it would not
change much. But I guess I'd have to play around with it to make sure
it does not what I want. So thanks for the hint for now.
If anyone else has some idea, feel free to add your thoughts.
regards
Michael
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
