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

[Gergely Nagy]

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!

The patch set is not 100% complete yet however, I'm only submitting it
for review and possible testing. I will probably port it to 3.3 too
(it applies almost cleanly, there's only one trivial conflict in
lib/Makefile.am) and build the Debian packages using upstream ivykis
to get wider testing.

What is missing, is the old lib/ivykis/configure.gnu script, which we
had there to force a static build of ivykis. This will be replaced by
a modification to autogen.sh, that will automatically create the
configure.gnu scripts in the various submodules, so we can point the
submodule links to upstream repos instead of our own forks. This is
not included in this set yet, and one will need to copy that file over
from the BalaBit fork, or things won't work too well.

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.

These were the easy issues, which I could solve right now if I had
some coffee left.

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.

As a workaround, I created the third patch, because I wanted to have
something that shows signs of working. The third patch is *WRONG*, but
it's an acceptable workaround until I have time to debug the problem
further.

What it does, is that it *always* clears the io handlers before
registering new ones. This results in marginally more work being done
each time we need to set a handler, but not by much, and as far as I
saw, it has no side effects.

But since the part of ivykis that aborts before the third patch, did
not change between BalaBit's fork and upstream, I'm certain that the
second patch introduces a bug that wasn't there before.

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.

That will be another funny adventure, but at least, by that time, I
will understand what the hell I am doing =)

--
|8]