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