Mailing List Archive

Hi Michael,

as I have blogged, I am not yet sure about how to handle the situation.
I am also consulting with Autotools experts, any advise is appreciated.

Two packages seem useful, especially when more plugins become available
(I myself think about email and a couple of other databases). Many folks
also do not like the idea of having to have libmysql present on the
system just to install rsyslog - with a core package and the plugin,
those can only install the core (and that will probably the majority of
cases).

What I have not yet found - and I have very limited expertise in this
area - is how to do that in the best possible way.

Oh, and some more background: ones the plugin interace has matured (I
expect this in 3 to 6 month), I intend to actually use ommysql with its
own version number. Versioning will be handled by the interface (that
part is already present, but no code for it yet as there is only a
release 1 of it). So, in the medium to long term, ommysql *will* be a
separate project - maybe one with a different maintainer, as I am no
mysql guy.

Does this make sense? As I said, comments are much appreciated...

Rainer

> -----Original Message-----
> From: Michael Biebl [mailto:mbiebl at gmail.com]
> Sent: Friday, September 28, 2007 10:23 AM
> To: rsyslog-users; Rainer Gerhards
> Subject: Re: [rsyslog] rsyslog 1.19.8 released
>
> 2007/9/27, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > repeat message processing. The MySQL functionality is now taken out
> of
> > the core package, but its tarball is still contained in the main
> tarball
> > (so it is still a single download for everything). This is part of
> the
> > effort to fully support third-party plugins. Rsyslog 1.19.8 is a
>
>
> To be honest, I don't particularly like this change. It increases the
> work for package maintainers (like me). You now have to maintain two
> source packages. Having a non-standard tarball inside a tarball
> doesn't help there. It even worsens things, as stuff like "make dist"
> or "make distcheck" doesn't work anymore for a cvs checkout.
> There's also the problem of which version of the plugins will be
> compatible with the core version (upgrade scenarios, keeping them in
> sync, etc.)
> It also adds complexity for the developer (as he has to maintain an
> additonal set of build files).
> As you were talking about 3rd party plugins (with the emphasis on 3rd
> party) I don't understand the benefit of splitting out the mysql
> plugin as it is you who develops the mysql plugin, not a third party.
> Do you actually intend to create a separate tarball for each plugin in
> the future?
>
> What was wrong with the --enable-mysql configure switch? I don't see
> any benefits, only disadvantages. You know, if it ain't broken, why
> fix it ;-)
>
> Cheers,
> Michael
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?

Hi Rainer,

> Hi Michael,
>
> as I have blogged, I am not yet sure about how to handle the situation.
> I am also consulting with Autotools experts, any advise is appreciated.
>
> Two packages seem useful, especially when more plugins become available
>
> (I myself think about email and a couple of other databases). Many folks
> also do not like the idea of having to have libmysql present on the
> system just to install rsyslog - with a core package and the plugin,
> those can only install the core (and that will probably the majority
> of cases).

Yes, I totally agree with what you're doing, as making rsyslog modular is
better overall for the product as a whole, as it will allow contributors
easier access to have their own plugins in place without needing to release
rsyslog each time.

> What I have not yet found - and I have very limited expertise in this
> area - is how to do that in the best possible way.

I've asked both Dag and Dries (from rpmforge) on the best way forward as these
guys have years of knowledge behind them for packaging (in the RPM space though).

I'm not sure they'll reply though, as sometimes my questions to them are
ignored and sometimes they are responded to (some questions I ask go into
their "too hard" basket which I think is why they ignore them :P ). I have
been querying, requesting, suggesting, etc things off them for more than 7
years now, so they may be sick of me (joking) :).

I have been asked to become a packager for them before (and for Axel Thimms
who does ATrpms.net - they're all merging into one large repo eventually) but
declined as I have little time as is to contribute to the projects I'm
currently working with.

> Oh, and some more background: ones the plugin interace has matured (I
> expect this in 3 to 6 month), I intend to actually use ommysql with its
> own version number. Versioning will be handled by the interface (that
> part is already present, but no code for it yet as there is only a
> release 1 of it). So, in the medium to long term, ommysql *will* be a
> separate project - maybe one with a different maintainer, as I am no
> mysql guy.
>
> Does this make sense? As I said, comments are much appreciated...

Yes and I do agree with it all. I'm just not personally sure of the best way
forward myself, but I would suspect something along the lines of having one
spec file for rsyslog, and another for rsyslog-mysql would likely be the right
way to go.

If neither Dag nor Dries answer me, I might even try Axel and if he also
doesn't respond (he usually does) then I'll just start on the packaging
myself, doing rsyslog and rsyslog-mysql.

In the long term, it would be better though if rpmforge or atrpms.net would
take on this packaging system. I realise Red Hat will have a "base" one
available in Fedora and then eventually an EL release, but they dont' do
updates, just bugfixing, once they release it for an enterprise product. Which
is where 3rd party repo's make sense.

Regards,

Michael.

> Rainer
>
> > -----Original Message-----
> > From: Michael Biebl [mailto:mbiebl at gmail.com]
> > Sent: Friday, September 28, 2007 10:23 AM
> > To: rsyslog-users; Rainer Gerhards
> > Subject: Re: [rsyslog] rsyslog 1.19.8 released
> >
> > 2007/9/27, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > > repeat message processing. The MySQL functionality is now taken out
> > of
> > > the core package, but its tarball is still contained in the main
> > tarball
> > > (so it is still a single download for everything). This is part of
> > the
> > > effort to fully support third-party plugins. Rsyslog 1.19.8 is a
> >
> >
> > To be honest, I don't particularly like this change. It increases the
> > work for package maintainers (like me). You now have to maintain two
> > source packages. Having a non-standard tarball inside a tarball
> > doesn't help there. It even worsens things, as stuff like "make dist"
> > or "make distcheck" doesn't work anymore for a cvs checkout.
> > There's also the problem of which version of the plugins will be
> > compatible with the core version (upgrade scenarios, keeping them in
> > sync, etc.)
> > It also adds complexity for the developer (as he has to maintain an
> > additonal set of build files).
> > As you were talking about 3rd party plugins (with the emphasis on 3rd
> > party) I don't understand the benefit of splitting out the mysql
> > plugin as it is you who develops the mysql plugin, not a third party.
> > Do you actually intend to create a separate tarball for each plugin in
> > the future?
> >
> > What was wrong with the --enable-mysql configure switch? I don't see
> > any benefits, only disadvantages. You know, if it ain't broken, why
> > fix it ;-)
> >
> > Cheers,
> > Michael
> >
> >
> > --
> > Why is it that all of the instruments seeking intelligent life in the
> > universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
------- End of Original Message -------

2007/9/28, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> Hi Michael,
>
> as I have blogged, I am not yet sure about how to handle the situation.
> I am also consulting with Autotools experts, any advise is appreciated.
>
> Two packages seem useful, especially when more plugins become available
> (I myself think about email and a couple of other databases). Many folks
> also do not like the idea of having to have libmysql present on the
> system just to install rsyslog - with a core package and the plugin,

Well, this is not quite true. If you don't want to have mysql support,
you could just use --disable-mysql. This way you don't have to have
mysql installed.
Such a --enable/disable-feature option could be added for any plugin
that will be added in the future.

> those can only install the core (and that will probably the majority of
> cases).
>
> What I have not yet found - and I have very limited expertise in this
> area - is how to do that in the best possible way.

I do have quite some experience with autotools. So if any help is
needed, I'll gladly offer it.

> release 1 of it). So, in the medium to long term, ommysql *will* be a
> separate project - maybe one with a different maintainer, as I am no
> mysql guy.

This actually is a valid argument for splitting it off.

But to reiterate what I posted earlier: For the plugins shipped
directly by the rsyslog project, I'd prefer to have them in a single
tarball with configure options to turn them on/off and as long as you
are the maintainer of the mysql output plugin its more convenient to
keep them in one project. Why not make the split when the plugin
interface is stable, other output plugins are available (and we have
more experience how to handle them) and a external maintainer for
ommysql is found?
I hope this doesn't sound too negative. I generally like the idea of
having a plugin interface, but I only fear that splitting things up
prematurely without knowing how it develops, will complicate things
(and probably destabilize).

Cheers,
Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael,

I need to prepare for german astronomy day tomorrow, so brief ;)

The point was that a single package (RPM or whatever) can be pre-build
for the core and the mysql functionality. I think the configure options
do not help with that. Or do they?

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Michael Biebl
> Sent: Friday, September 28, 2007 6:07 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog 1.19.8 released
>
> 2007/9/28, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > Hi Michael,
> >
> > as I have blogged, I am not yet sure about how to handle the
> situation.
> > I am also consulting with Autotools experts, any advise is
> appreciated.
> >
> > Two packages seem useful, especially when more plugins become
> available
> > (I myself think about email and a couple of other databases). Many
> folks
> > also do not like the idea of having to have libmysql present on the
> > system just to install rsyslog - with a core package and the plugin,
>
> Well, this is not quite true. If you don't want to have mysql support,
> you could just use --disable-mysql. This way you don't have to have
> mysql installed.
> Such a --enable/disable-feature option could be added for any plugin
> that will be added in the future.
>
> > those can only install the core (and that will probably the majority
> of
> > cases).
> >
> > What I have not yet found - and I have very limited expertise in
this
> > area - is how to do that in the best possible way.
>
> I do have quite some experience with autotools. So if any help is
> needed, I'll gladly offer it.
>
> > release 1 of it). So, in the medium to long term, ommysql *will* be
a
> > separate project - maybe one with a different maintainer, as I am no
> > mysql guy.
>
> This actually is a valid argument for splitting it off.
>
> But to reiterate what I posted earlier: For the plugins shipped
> directly by the rsyslog project, I'd prefer to have them in a single
> tarball with configure options to turn them on/off and as long as you
> are the maintainer of the mysql output plugin its more convenient to
> keep them in one project. Why not make the split when the plugin
> interface is stable, other output plugins are available (and we have
> more experience how to handle them) and a external maintainer for
> ommysql is found?
> I hope this doesn't sound too negative. I generally like the idea of
> having a plugin interface, but I only fear that splitting things up
> prematurely without knowing how it develops, will complicate things
> (and probably destabilize).
>
> Cheers,
> Michael
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

2007/9/28, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> Michael,
>
> I need to prepare for german astronomy day tomorrow, so brief ;)
>
> The point was that a single package (RPM or whatever) can be pre-build
> for the core and the mysql functionality. I think the configure options
> do not help with that. Or do they?
>

You can split up the build to create multiple *binary* packages from a
single *source* package, the RPM format as well as DEB allows that.

Actually the Debian and Fedora packages already do that. The rsyslog
[1] binary package contains the core rsyslogd/rklogd binaries, the
rsyslog-mysql [2] package the mysql output plugin.
It's not necessary to already split up the *source* package for that.

Cheers,
Michael


[1] http://packages.debian.org/sid/rsyslog
[2] http://packages.debian.org/sid/rsyslog-mysql

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

2007/9/28, Michael Biebl <mbiebl at gmail.com>:
> 2007/9/28, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> >
> > The point was that a single package (RPM or whatever) can be pre-build
> > for the core and the mysql functionality. I think the configure options
> > do not help with that. Or do they?
> >
>
> You can split up the build to create multiple *binary* packages from a
> single *source* package, the RPM format as well as DEB allows that.
>
> Actually the Debian and Fedora packages already do that. The rsyslog
> [1] binary package contains the core rsyslogd/rklogd binaries, the
> rsyslog-mysql [2] package the mysql output plugin.
> It's not necessary to already split up the *source* package for that.
>
> [1] http://packages.debian.org/sid/rsyslog
> [2] http://packages.debian.org/sid/rsyslog-mysql

And as you can see from [1] and [2], the core rsyslog package has no
libmysql dependencies.

Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

On 2007-09-27, Rainer Gerhards <rgerhards at hq.adiscon.com> wrote:
>
> rsyslog 1.19.8 has been released today. Most importantly, it fixes a bug

Still crashes.. twice today, but I didn't find the trace the
first time. Here's the trace from the second crash:

*** glibc detected *** rsyslogd: corrupted double-linked list: 0x094ca0e8 ***
======= Backtrace: =========
/lib/libc.so.6[0x4152cda9]
/lib/libc.so.6(cfree+0x90)[0x415305d0]
rsyslogd(MsgDestruct+0x73)[0x8058323]
rsyslogd[0x804dfba]
rsyslogd(llExecFunc+0x3f)[0x805f43f]
rsyslogd[0x804d9ba]
rsyslogd[0x804db0f]
/lib/libpthread.so.0[0x416112db]
/lib/libc.so.6(clone+0x5e)[0x4159414e]
======= Memory map: ========
0067d000-0067e000 r-xp 0067d000 00:00 0 [vdso]
08048000-08068000 r-xp 00000000 fd:00 884939 /sbin/rsyslogd
08068000-08069000 rwxp 00020000 fd:00 884939 /sbin/rsyslogd
094c5000-09549000 rwxp 094c5000 00:00 0
414aa000-414c3000 r-xp 00000000 fd:00 1146882 /lib/ld-2.5.so
414c3000-414c4000 r-xp 00018000 fd:00 1146882 /lib/ld-2.5.so
414c4000-414c5000 rwxp 00019000 fd:00 1146882 /lib/ld-2.5.so
414c7000-415fe000 r-xp 00000000 fd:00 1146990 /lib/libc-2.5.so
415fe000-41600000 r-xp 00137000 fd:00 1146990 /lib/libc-2.5.so
41600000-41601000 rwxp 00139000 fd:00 1146990 /lib/libc-2.5.so
41601000-41604000 rwxp 41601000 00:00 0
41606000-41608000 r-xp 00000000 fd:00 1147002 /lib/libdl-2.5.so
41608000-41609000 r-xp 00001000 fd:00 1147002 /lib/libdl-2.5.so
41609000-4160a000 rwxp 00002000 fd:00 1147002 /lib/libdl-2.5.so
4160c000-4161f000 r-xp 00000000 fd:00 1147003 /lib/libpthread-2.5.so
4161f000-41620000 r-xp 00012000 fd:00 1147003 /lib/libpthread-2.5.so
41620000-41621000 rwxp 00013000 fd:00 1147003 /lib/libpthread-2.5.so
41621000-41623000 rwxp 41621000 00:00 0
41667000-41679000 r-xp 00000000 fd:00 1087043 /usr/lib/libz.so.1.2.3
41679000-4167a000 rwxp 00011000 fd:00 1087043 /usr/lib/libz.so.1.2.3
416c4000-416cb000 r-xp 00000000 fd:00 1147009 /lib/librt-2.5.so
416cb000-416cc000 r-xp 00006000 fd:00 1147009 /lib/librt-2.5.so
416cc000-416cd000 rwxp 00007000 fd:00 1147009 /lib/librt-2.5.so
4acb4000-4acbf000 r-xp 00000000 fd:00 1146939 /lib/libgcc_s-4.1.1-20070105.so.1
4acbf000-4acc0000 rwxp 0000a000 fd:00 1146939 /lib/libgcc_s-4.1.1-20070105.so.1
b7200000-b722a000 rw-p b7200000 00:00 0
b722a000-b7300000 ---p b722a000 00:00 0
b7400000-b7430000 rw-p b7400000 00:00 0
b7430000-b7500000 ---p b7430000 00:00 0
b759b000-b759c000 ---p b759b000 00:00 0
b759c000-b7f9e000 rw-p b759c000 00:00 0
b7fa3000-b7fa5000 rw-p b7fa3000 00:00 0
bfc72000-bfc88000 rw-p bfc72000 00:00 0 [stack]



-jf

Hi Michael,

sorry for the late reply, have been quite busy with astronomy day in
Germany. Back to rsyslog...

> You can split up the build to create multiple *binary* packages from a
> single *source* package, the RPM format as well as DEB allows that.
>
> Actually the Debian and Fedora packages already do that. The rsyslog
> [1] binary package contains the core rsyslogd/rklogd binaries, the
> rsyslog-mysql [2] package the mysql output plugin.
> It's not necessary to already split up the *source* package for that.

That sounds exactly like what I would love to have. However, I am no
autotools expert. If you (or someone else) can lend me a helping hand in
creating the necessary config files for autotools, I will gladly do it
in that way.

The current setup has two things that I do not really like:

a) the need for two tarballs

I do not know how to integrate the full structure in a single "make
dist". And I do not like to simply include the *full* ommysql subdir
within the extra_dist make target - that gets me a lot of files I really
don't need.

b) need to specify version twice

Currently, ommsysql has its own version definition in its configure.ac.
It's error prone and I know I'll mess up with it sooner or later. That
makes sense once it is a totally independent package, but not at the
time being.

Ideally, I would like autotools to know the dependencies and create
things correctly.

As said, any help is deeply appreciated.

Rainer

> Cheers,
> Michael
>
>
> [1] http://packages.debian.org/sid/rsyslog
> [2] http://packages.debian.org/sid/rsyslog-mysql
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

2007/10/2, Rainer Gerhards <rgerhards at hq.adiscon.com>:
>
> > You can split up the build to create multiple *binary* packages from a
> > single *source* package, the RPM format as well as DEB allows that.
> >
> > Actually the Debian and Fedora packages already do that. The rsyslog
> > [1] binary package contains the core rsyslogd/rklogd binaries, the
> > rsyslog-mysql [2] package the mysql output plugin.
> > It's not necessary to already split up the *source* package for that.
>
> That sounds exactly like what I would love to have. However, I am no

But that is already possible with a single source tarball as we had
with <= 1.19.7.
That's why I questioned the need for the source package split.
Am I missing something?

> autotools expert. If you (or someone else) can lend me a helping hand in
> creating the necessary config files for autotools, I will gladly do it
> in that way.

I'd say, just ship a single tarball as in <= 1.19.7 and let the
distributions decide how they split up the package into (multiple)
binary packages.

Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Is this the overall consensus on this list? If so, I'll revert the change in the next release. So if you don't like this, please comment now.

Thanks,
Rainer

----- Urspr?ngliche Nachricht -----
Von: "Michael Biebl" <mbiebl at gmail.com>
An: "rsyslog-users" <rsyslog at lists.adiscon.com>
Gesendet: 02.10.07 18:34
Betreff: Re: [rsyslog] rsyslog 1.19.8 released

2007/10/2, Rainer Gerhards <rgerhards at hq.adiscon.com>:
>
> > You can split up the build to create multiple *binary* packages from a
> > single *source* package, the RPM format as well as DEB allows that.
> >
> > Actually the Debian and Fedora packages already do that. The rsyslog
> > [1] binary package contains the core rsyslogd/rklogd binaries, the
> > rsyslog-mysql [2] package the mysql output plugin.
> > It's not necessary to already split up the *source* package for that.
>
> That sounds exactly like what I would love to have. However, I am no

But that is already possible with a single source tarball as we had
with <= 1.19.7.
That's why I questioned the need for the source package split.
Am I missing something?

> autotools expert. If you (or someone else) can lend me a helping hand in
> creating the necessary config files for autotools, I will gladly do it
> in that way.

I'd say, just ship a single tarball as in <= 1.19.7 and let the
distributions decide how they split up the package into (multiple)
binary packages.

Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog

On Tue, Oct 02, 2007 at 07:41:22PM +0200, Rainer Gerhards wrote:
> Is this the overall consensus on this list? If so, I'll revert
> the change in the next release. So if you don't like this,
> please comment now.

In source-based systems (like BSD ports, Gentoo Portage and many
others), it is a lot more logical two have separate tarballs, but
they have to be self-sufficient. The current ommysql tarball
should only need whatever rsyslog core installs to be built and
used. It should not require the core tarball.

If that's too difficult, it's OK to ship a single tarball with an
opportunity to build just the plugin (just ommysql as opposed to
rsyslog+ommysql).

If that's also difficult, the old behavior is OK, where a single
tarball can build either rsyslog or rsyslog+ommysql. From a
packager's point of view, the current (transitional?) behavior
does not add anything but a minor headache. I had to disable
mysql support in the FreeBSD port temporarily because I didn't
have time to arrange for it to be built properly in 1.19.8.

Thanks!

Hi all,

thanks for the (on- and off-list) feedback. I count silence as
agreement. So I will try to follow the advise down here. I'll change
back to a single tarball, most probably with the next release.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Andrew Pantyukhin
> Sent: Thursday, October 04, 2007 10:38 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog 1.19.8 released
>
> On Tue, Oct 02, 2007 at 07:41:22PM +0200, Rainer Gerhards wrote:
> > Is this the overall consensus on this list? If so, I'll revert
> > the change in the next release. So if you don't like this,
> > please comment now.
>
> In source-based systems (like BSD ports, Gentoo Portage and many
> others), it is a lot more logical two have separate tarballs, but
> they have to be self-sufficient. The current ommysql tarball
> should only need whatever rsyslog core installs to be built and
> used. It should not require the core tarball.
>
> If that's too difficult, it's OK to ship a single tarball with an
> opportunity to build just the plugin (just ommysql as opposed to
> rsyslog+ommysql).
>
> If that's also difficult, the old behavior is OK, where a single
> tarball can build either rsyslog or rsyslog+ommysql. From a
> packager's point of view, the current (transitional?) behavior
> does not add anything but a minor headache. I had to disable
> mysql support in the FreeBSD port temporarily because I didn't
> have time to arrange for it to be built properly in 1.19.8.
>
> Thanks!
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

Hi Rainer,

> Hi all,
>
> thanks for the (on- and off-list) feedback. I count silence as
> agreement. So I will try to follow the advise down here. I'll change
> back to a single tarball, most probably with the next release.

Yeah, from my end I don't see much of a difference with how it's packaged your
end, since the packager responsible for making an RPM will need both tarballs
and two specs to make two RPM's anyway.

Regards,

Michael.

> Rainer
>
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Andrew Pantyukhin
> > Sent: Thursday, October 04, 2007 10:38 AM
> > To: rsyslog-users
> > Subject: Re: [rsyslog] rsyslog 1.19.8 released
> >
> > On Tue, Oct 02, 2007 at 07:41:22PM +0200, Rainer Gerhards wrote:
> > > Is this the overall consensus on this list? If so, I'll revert
> > > the change in the next release. So if you don't like this,
> > > please comment now.
> >
> > In source-based systems (like BSD ports, Gentoo Portage and many
> > others), it is a lot more logical two have separate tarballs, but
> > they have to be self-sufficient. The current ommysql tarball
> > should only need whatever rsyslog core installs to be built and
> > used. It should not require the core tarball.
> >
> > If that's too difficult, it's OK to ship a single tarball with an
> > opportunity to build just the plugin (just ommysql as opposed to
> > rsyslog+ommysql).
> >
> > If that's also difficult, the old behavior is OK, where a single
> > tarball can build either rsyslog or rsyslog+ommysql. From a
> > packager's point of view, the current (transitional?) behavior
> > does not add anything but a minor headache. I had to disable
> > mysql support in the FreeBSD port temporarily because I didn't
> > have time to arrange for it to be built properly in 1.19.8.
> >
> > Thanks!
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
------- End of Original Message -------

On 2007-09-28, Jan-Frode Myklebust <janfrode at tanso.net> wrote:
> On 2007-09-27, Rainer Gerhards <rgerhards at hq.adiscon.com> wrote:
>>
>> rsyslog 1.19.8 has been released today. Most importantly, it fixes a bug
>
> Still crashes.. twice today, but I didn't find the trace the
> first time. Here's the trace from the second crash:
>

FYI: I set the environment variable MALLOC_CHECK_=2 after this
last crash on friday, hoping to get a better trace when it crashed,
but it still haven't crashed.. Not sure if that's good or bad :-)


-jf

As we know it crashed at least once, I'd be more happy with consistent
crashing... ;) That inconsistency is part of the problem. It's extremely
hard to repro it - I did not even succeed once. I know what this pattern
typically means, but so far I've found no more places in code that would
"qualify" for this kind of bug... Obviously, either my understanding is
wrong or I am still looking at the wrong places. So any further data
from the field (crashing or not) is highly appreciated. You are my sole
source of troubleshooting information.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Jan-Frode Myklebust
> Sent: Thursday, October 04, 2007 12:10 PM
> To: rsyslog at lists.adiscon.com
> Subject: Re: [rsyslog] rsyslog 1.19.8 released
>
> On 2007-09-28, Jan-Frode Myklebust <janfrode at tanso.net> wrote:
> > On 2007-09-27, Rainer Gerhards <rgerhards at hq.adiscon.com> wrote:
> >>
> >> rsyslog 1.19.8 has been released today. Most importantly, it fixes
a
> bug
> >
> > Still crashes.. twice today, but I didn't find the trace the
> > first time. Here's the trace from the second crash:
> >
>
> FYI: I set the environment variable MALLOC_CHECK_=2 after this
> last crash on friday, hoping to get a better trace when it crashed,
> but it still haven't crashed.. Not sure if that's good or bad :-)
>
>
> -jf
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog