[syslog-ng] merging stuff from merge-queue/3.4

Gergely Nagy algernon at balabit.hu
Sat Nov 17 16:36:51 CET 2012


Balazs Scheidler <bazsi77 at gmail.com> writes:

>> commit 169bc655620bf641eb0429258533037ff9ae52bd
>> Author: Gergely Nagy <algernon at balabit.hu>
>> Date:     Fri Oct 5 12:16:57 2012 +0200
>> 
>>         logreader: When following a file, treat non-regular files specially
>> 
>> > I'm afraid that the inability to use kqueue on /dev/klog would
>> > prevent using kqueue completely, as the syslog-ng file source code
>> > requires either regular files or pollable devices.
>> 
>> With the above patch, there is a workaround that will do until we have
>> a proper device() source. 
>
> you mean, that with that workaround, logreader will unconditionally
> read from the fd every follow-freq() seconds, assuming there's
> something to be read?

Pretty much, yes, provided the fd shows certain properties which I
forgot (I believe it was st.st_size being 0).

> I don't see how the device() driver would solve this though.

It would 'solve' it by not having to have this hack in logreader, but in
a device-specific driver, a few layers elsewhere.

> agaimn, I don't see how you'd solve this case properly. w/o kqueue
> support on /dev/log, we'll have to resort to timer based polling.

Yes, timer based polling is the good solution, and one reason device()
would solve it, is that it wouldn't have follow-freq(0). The reason
/dev/klog did not work is because we fell back to timer-based polling,
but that is disabled with follow-freq(0). With device(), we can get rid
of that without resorting to crude hackery.

> You don't have to look up anything, the context is passed to template
> functions through the invoke args stuff. There are already template
> functions that use the context, see for instance $(grep)

Hrm... I didn't look hard enough then. I'll take a look at $(grep) and
rework the patch, thanks!


-- 
|8]



More information about the syslog-ng mailing list