On Thu, Apr 03, 2003, [EMAIL PROTECTED] wrote: > On Wed, 2 Apr 2003, Martin Andrews wrote: > > > struggled with the fsl.postfix configuration. Syntax or other errors in > > the fsl.postfix file caused postfix to dump core. Ug. [...] > > The fact that changes in the fsl or errors in configuring lead to core > dumps lets me doubt if fsl is a good approach to the problem. In general I > had several reports of people having problems with fsl which have been > hard to track down. E.g. a program crashes because the log file is not > writable etc. > Besides my statements below regarding "kolab disable fsl" i want you to know that i was not able to crash postfix with syntatically or logically wrong fsl configs. I used postfix-2.0.2-1.2.1 with fsl-1.0.8-1.2.2 for testing. If you use these or later versions and find a configuration which crashes please tell me about it. Make sure you rebuild applications like postfix after an fsl upgrade - it's statically linked and won't change until after rebuild and reinstall the application.
> Additionally because of the static nature of OpenPKG it is > not so easy to track down. > It is as easy to find out if a program uses fsl and which version, even in a static configuration - see http://www.ossp.org/pkg/lib/fsl/faq.html#static-fsl > In the kolab project we therefor decided to disable fsl everywhere. > We are aware of this and i have an item on by TODO list to - check that really all packages using syslog(3) become fsl enabled - every use of fsl becomes an option which defaults to "yes" So in the near future you could easily inhibit fsl without having to hack every spec file. This decision was primarily driven by kolab. However, we still believe in fsl, even the current incarnation, and continue to support it. We are currently designing a major improvment of the underlying OSSP l2 library. This library is much more sophisticated than syslog(3) and the tradeoff is that the more complex code could more easily fail. This won't change because it can't. But we're working on a asynchronous channel which dedicates most of the logging to a different process, so crashes won't touch the main program anymore. If this work has been completed, fsl will inherit those improvments. It is our hope that kolab will finally come back on the fsl track in the future. We need the feedback of the community to improve the code. > In general people are not used to crashes due to a non working logging > setup. Taditionally if logging was not possible for whatever reason > programs did continue to work. > Agree, and that's what (we) the OSSP l2 team are working on. Thanks to this thread i improved and created - http://www.ossp.org/pkg/lib/fsl/faq.html#syslog-fsl - http://www.ossp.org/pkg/lib/fsl/faq.html#static-fsl Thank you for your feedback. -- [EMAIL PROTECTED] Development Team, Operations Northern Europe, Cable & Wireless ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List [EMAIL PROTECTED]
