[syslog-ng] [PATCH 0/3] WIP: Convert syslog-ng to use upstream ivykis

[Lennert Buytenhek]

On Mon, May 07, 2012 at 11:42:30PM +0200, Gergely Nagy wrote:

> A long long time ago, upstream and BalaBit's version of ivykis started
> to diverge, which - at the time - was necessary, but the intent always
> was to eventually get things upstream and merged, to allow syslog-ng
> to use upstream ivykis, as-is.
> 
> With the help of Lennert Buytenhek (ivykis upstream) and Balazs
> Scheidler, I present you the first work in progress patch set against
> syslog-ng that enables it to work with an unmodified ivykis!

(Whoops, I didn't see this email until now.)

Yay!  Thanks for doing this work.


> Another thing is that the first patch stops libsyslog-ng-crypto from
> being directly linked to ivykis. This is not an issue when ivykis is
> statically compiled into libsyslog-ng, since all those symbols will be
> exported to other modules, including libsyslog-ng-crypto. However, it
> might become a problem when using a dynamically linked ivykis. I
> haven't tested that case yet.
> 
> The reason I remove the link is that if ivykis is statically compiled
> in to both shared objects, the constructors will run twice, as
> dlopen()ing anything linked against libsyslog-ng-crypto will trigger
> them again. This leads to an abort() inside ivykis.
> 
> This can be done on the ivykis side too: separate the constructors
> from the init functions, and make the constructors no-op if they ran
> already: this allows the init functions to continue aborting if called
> more than once, but allows the constructors to run twice. I have to
> discuss this with upstream, and see if we need this at all, or if my
> workaround of removing the linkage from libsyslog-ng-crypto is enough
> and without side effects.

If the constructors run twice but bss variables are still shared,
then yeah, we should do something like what you said.


> But alas, there is another issue!
> 
> With the first two patches applied, we'd have a syslog-ng that
> compiles fine against upstream ivykis, and even works. Except it
> doesn't: whenever we try to set an io handler for an fd, we'd end up
> in an abort, because for some reason, we already had a handler set.
> 
> I do not understand it quite yet why this happens - the old BalaBit
> fork of ivykis was similarly picky and abort-happy and they did not
> trigger.

(I screwed up here -- mea culpa -- but let's discuss this in the other
thread.)


> Nevertheless! The good news still is, that we're *very* close to being
> able to build with upstream ivykis! A few issues to fix, and then
> comes the next part: going over all the changes that were made to the
> BalaBit fork of ivykis, and send everything upstream that has not been
> sent yet.

Right, there's several changes still in your version of ivykis that
haven't made it into mine (e.g. to have an abstraction for syslog(),
which seems a generally good idea to have, and probably there's more
bits as well).  Do you think syslog-ng is ready for inclusion into
e.g. Fedora as-is, or do you want to get those changes merged into
upstream ivykis as well first?


cheers,
Lennert