[syslog-ng] preparing for 1.9.9

[Roberto Nibali]

> I've fixed a segfault in this release, and as of now I don't know about
> any others.

Ok, all segfaults I've seen can be attributed to the SIGHUP case.

>>>I would like to ask you to give a try to these snapshot releases I've
>>>just uploaded to our website. Assuming no grave problems are found in
>>>the next day or two I'll release 1.9.9 and hopefully we can have a
>>>stable 2.0.0 in the nearfuture.
>>
>>So this is a feature freeze?
> 
> Yes, I'd like to release a stable syslog-ng 2.0 out of the door. The
> more exciting features will be added to a new branch.

Thanks, this is good to know. So with this in mind, I believe we can 
give syslog-ng 2.0 a serious thought. This would give us and you a broad 
test base. The idea would be to go through all our internal bugzilla 
entries related to logging or syslog-ng and re-test them with the new 
code base.

>>You could do it the squid way (or httpd for that matter) and have an 
>>external syslog-ng client (similar to squidclient) to poll or dump 
>>internal stats. Is that more to your liking?
>  
> Yes, that is something I was thinking about, I originally wanted to
> avoid the complexity of a control channel. That might be missing from
> 2.0.0 though.

No problem.

>>>        * Added kernel flag to sources to indicate that messages coming from
>>>          the source should default to 'kern.crit' instead of 'user.notice'
>>
>>Rather than fix up the kernel source?
> 
> Sometimes messages from the kernel are not prefixed by a proper priority
> prefix. I had this request in our bugzilla and as it was trivial I
> implemented it.

So long as it remains optional. However I do not agree with kern.crit as 
a default because kern.crit has very specific semantic meaning in the 
linux kernel. Why not resort to kern.info or make it configurable? Also 
how does the klogd alternative handle this?

>>>        * Fixed a possible segmentation fault on SIGHUP.
>>
>>Thank you! Could you point me to the respective patch, please, since I 
>>tried to fix that one in the past and spent 4 hours in vain. I would 
>>like to improve my debugging abilities regarding syslog-ng and 
>>understand your architecture better.
> 
> The problem was a stale reference between AFSocketSourceConnection and
> the AFSocketSourceDriver objects through SIGHUP.
> 
> AFSocketSourceConnections are kept through SIGHUP (so that they are not
> closed), but AFSocketSourceDrivers are not. Similarly the LogReader
> associated with AFSocketSourceConnection has a reference to its
> LogReaderOptions which was again stored in AFSocketSourceDriver.

... and booom! I see the problem, nasty. At least, now you know that you 
have no fd leakage :).

> The solution was get rid of this stale reference to point to the newly
> created driver object, this was archieved by adding a
> afsocket_sc_set_owner() function which makes sure all references are
> properly updated.

Nice solution.

> See the changelog entry for 2006-02-11 for more details.

I'll do that, thanks.

Best regards,
Roberto Nibali, ratz
-- 
echo 
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc