[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