From rgerhards at hq.adiscon.com  Mon Sep  1 15:32:27 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 1 Sep 2008 15:32:27 +0200
Subject: [rsyslog] Problems migrating from syslog-ng
In-Reply-To: <c24352ca0808220621s5419322fi3f0820e1dea79da9@mail.gmail.com>
References: <c24352ca0808211033u3e1a810dsb5ad7f11c594bfe6@mail.gmail.com><ac9ded160808211046h4eb276e2t9653c5e7169008f5@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA0108D9@grfint2.intern.adiscon.com><c24352ca0808211344n221aff68ib6e143c287680b48@mail.gmail.com><ac9ded160808211400w2da90ce3k17a307a214aa939f@mail.gmail.com>
	<c24352ca0808220621s5419322fi3f0820e1dea79da9@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F05E@grfint2.intern.adiscon.com>

Being back...

(inline)

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Jeff Schroeder
> Sent: Friday, August 22, 2008 3:21 PM
> To: (private) HKS
> Cc: rsyslog-users
> Subject: Re: [rsyslog] Problems migrating from syslog-ng
> 
> On Thu, Aug 21, 2008 at 2:00 PM, (private) HKS <hks.private at gmail.com>
> wrote:
> > On Thu, Aug 21, 2008 at 4:44 PM, Jeff Schroeder
> <jeffschroed at gmail.com> wrote:
> >> On Thu, Aug 21, 2008 at 10:53 AM, Rainer Gerhards
> >> <rgerhards at hq.adiscon.com> wrote:
> >>> I have only been able to have a brief look, but it looks like the
> message is incorrectly formatted. rsyslog is smart enough to detect
> that the hostname is missing if the tag is followed by a character not
> valid in hostnames. But if the tag even looks like a hostname, it has
> no chance of detecting that it isn't one. As suggested, see RFC 3164
> for what the format should look like. I think the -x option (or some
> other) enables to strip hostname detection, but I am not sure. You can
> "solve" this by misusing some fields. E.g. FROMHOST probably has what
> actually is the tag. HKS suggestion will help you find a suitable
> format.
> 
> You were right Rainer. It looks like the java code which injects the
> message is sending malformed
> syslog requests.

Please provide samples of the raw messages, what syslog-ng does to them
and what rsyslog does (and what you would ideally like to see, if that's
different in any aspect ;)). [I know you have sent most of it - except
the source message, but I'd like to have a consistent set to look at.]

> syslog-ng still sends it through and does the correct
> things. Is there a way to make
> rsyslog a bit less strict about it? 

It depends on the above things. The problem is that when we cannot
detect whether it is a tag or a hostname, there is no way to do it
automatically. I can, of course, add a switch that tells the parser that
there never is a hostname inside the message. I suspect this is what
syslog-ng is doing. This prevents relay chains from properly conveying
the hostname, but I guess it would work in your case. It needs to be a
user option, because obviously most users will never want to use this
handling.

> Running rsyslog with -c0 defeats
> the purpose of using rsyslog.

Well... not really. The -cX switches change some aspects of behavior,
but do not change the core itself. However, I do not think that -c0
would change anything. Does it? If so, my analysis would obviously be
wrong...

> Until our application has been fixed and rolled out accross our
> clusters worldwide, we rolled back to syslog-ng.

Of course, I'd like to support the format as-is (under above
constraints;)).

Rainer
> 
> 
> >>
> >> Is there an equivalent of "-x" with "-c 3" enabled? It doesn't seem
> to
> >> work with -c3 and I'd
> >> rather not run in compatibility mode.
> >
> >
> > I don't think so.
> >
> > -HKS
> >
> 
> 
> 
> --
> Jeff Schroeder
> 
> Don't drink and derive, alcohol and analysis don't mix.
> http://www.digitalprognosis.com
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Mon Sep  1 16:41:45 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 01 Sep 2008 16:41:45 +0200
Subject: [rsyslog] broken size_nbr handling
In-Reply-To: <4255c2570808232301n5bab0c30w549df07c8e5b6c1f@mail.gmail.com>
References: <4255c2570808232301n5bab0c30w549df07c8e5b6c1f@mail.gmail.com>
Message-ID: <1220280105.7184.411.camel@rgf9dev.intern.adiscon.com>

Thanks for spotting this problem and the patch. I have just applied it
to the v3-stable branch, will be moved to all others soon.

Rainer

On Sun, 2008-08-24 at 00:01 -0600, RB wrote:
> In implementing my own 'human-readable' size parser (would be nice to
> have one as a part of one of the usable objects), I noticed there
> seemed to be order-of-magnitude issues on the base-10 size definitions
> in cfsysline.c.  Although the base-2 operations properly increase 2^10
> (1024) for each SI prefix, the base-10 ones only increase by one order
> of magnitude (10) instead of the proper 10^3 per prefix, ending up
> with EB only being 10^8 instead of 10^18.
> 
> Following is a simple patch that should put things right:
> ======================================
> diff --git a/runtime/cfsysline.c b/runtime/cfsysline.c
> index 18643ba..1989247 100644
> --- a/runtime/cfsysline.c
> +++ b/runtime/cfsysline.c
> @@ -215,11 +215,11 @@ static rsRetVal doGetSize(uchar **pp, rsRetVal
> (*pSetHdlr)(void*, uid_t), void *
>                 case 'e': i *= (int64) 1024 * 1024 * 1024 * 1024 *
> 1024 * 1024; ++(*pp); break; /* exa */
>                 /* and now the "new" 1000-based definitions */
>                 case 'K': i *= 1000; ++(*pp); break;
> -               case 'M': i *= 10000; ++(*pp); break;
> -               case 'G': i *= 100000; ++(*pp); break;
> -               case 'T': i *= 1000000; ++(*pp); break; /* tera */
> -               case 'P': i *= 10000000; ++(*pp); break; /* peta */
> -               case 'E': i *= 100000000; ++(*pp); break; /* exa */
> +               case 'M': i *= 1000000; ++(*pp); break;
> +               case 'G': i *= 1000000000; ++(*pp); break;
> +               case 'T': i *= 1000000000000; ++(*pp); break; /* tera */
> +               case 'P': i *= 1000000000000000; ++(*pp); break; /* peta */
> +               case 'E': i *= 1000000000000000000; ++(*pp); break; /* exa */
>         }
> 
>         /* done */
> ======================================
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep  1 16:56:42 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 01 Sep 2008 16:56:42 +0200
Subject: [rsyslog] Running hashes
In-Reply-To: <4255c2570808230045kb625e11u795435a8a6c8d457@mail.gmail.com>
References: <4255c2570808230045kb625e11u795435a8a6c8d457@mail.gmail.com>
Message-ID: <1220281002.7184.426.camel@rgf9dev.intern.adiscon.com>

On Sat, 2008-08-23 at 01:45 -0600, RB wrote:
> Acting on an old comment from a friend, I decided to look into what
> it'd take to get rsyslog to perform running hashes of logs.
> Conceptually, it's pretty simple - every Nth message inject one
> message containing the hash of the previous N messages (including the
> previous hash message).  

Yes - this is the way IETF's upcoming syslog-sign is using hashes. It
may be tempting to use that mode for the logs, too...

> It also gave me an excuse to start digging
> into the rsyslog code.
> 
> At first I thought I could do it with a property replacer, but that
> seems a wash since those are wholly message-based and don't [seem to]
> give the opportunity to store information (even a running hash) of
> prior messages.  

That's right and that's by design. The property replacer is a one-way
road.

> A plugin was my next hope, but there doesn't seem to
> be a good mechanism to pipeline those together - AFAICT they're
> expected to be single ingress/egress points, with no interstitial
> stages. 

That's definitely true for input and output plugins. They, by very
definition, are at either end of the processing flow.

>  I see the code for loading other objects as Rainer mentioned
> in April, but that seems more for central functionality than for
> chaining modules together.

You are absolutely correct. These objects are (mostly) for internal
things, so to save us static binding - and the ability to use different
drivers for different needs, e.g. for different network transport
protocols (and maybe later for different, even-smaller and more
abstracted, database drivers).

> This all brings me back to one of my original questions for rsyslog -
> is module chaining something that is even on your radar?  I'm thinking
> normalization, hashing, encryption, etc.  Almost feels like there
> should be another layer here, maybe a "mangle" plugin interface that
> could stack in after im* and before om*?

You are definitely on the right route. If you look at the plugin
definitions, there is another class, not yet implemented, of plugins:
they are called "filter plugins". They will have the ability to take a
message, modify it (or inject a new one based on previous messages) and
so on - at least this is how it was designed roughly a year ago.

With the arrival of the scripting language (in February, if I correctly
remember), new players have entered the field: library plugins that
expose function calls to the script engine. So far, they do NOT yet
exist, but they are pretty well thought out. They are probably the first
thing I will implement when I start bringing the script engine to its
full power. These functions may also be a good place to provide a
"mangling" interface. I am still a bit undecided, maybe I will not 100%
design this, but let the code evolve (sometimes, I think, it is good to
look at code written and see if that "extra bit" just naturally fits
in...).

A bit problematic is the order of events (and message modification) when
the message object is run asynchronously through multiple action queues.
For each queue, the message is forked, so it requires careful design
when to modify which of the forked messages. This can be very powerful,
but also quite complex to configure (where the scripting language
hopefully comes in handy).

Another, internal, thing is message synchronization. So far, property
creation and modification never requires sync objects (like mutexes),
because the always happen in a single thread (for ONE specific message,
of course). With mangling capabilities, things change considerably,
property set methods than need sync capability. This must be implemented
in a way that does not hurt the (for more frequent) case of message
object creation.

Of course, all of this is doable and the base design is there :) I just
wanted to provide an idea why it may take a little while to implement.
Comments and suggestions are most welcome, especially as this is among
the next things on my todo list (if priorities don't change).

Rainer
> 
> 
> RB
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep  1 17:00:15 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 1 Sep 2008 17:00:15 +0200
Subject: [rsyslog] Running hashes
In-Reply-To: <1220281002.7184.426.camel@rgf9dev.intern.adiscon.com>
References: <4255c2570808230045kb625e11u795435a8a6c8d457@mail.gmail.com>
	<1220281002.7184.426.camel@rgf9dev.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F064@grfint2.intern.adiscon.com>

I forgot one thing. If you did not already find it, have a look at this:

http://www.rsyslog.com/doc-generic_design.html

The filter/function plugins are conceptually on the "PLG Ext" et al
layer in this chart. This is not specifically rsyslog design, but it
comes from the same source and conveys the same basic idea ;) [I
initially did that description for some generic IETF work].

Maybe it is useful.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Monday, September 01, 2008 4:57 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] Running hashes
> 
> On Sat, 2008-08-23 at 01:45 -0600, RB wrote:
> > Acting on an old comment from a friend, I decided to look into what
> > it'd take to get rsyslog to perform running hashes of logs.
> > Conceptually, it's pretty simple - every Nth message inject one
> > message containing the hash of the previous N messages (including
the
> > previous hash message).
> 
> Yes - this is the way IETF's upcoming syslog-sign is using hashes. It
> may be tempting to use that mode for the logs, too...
> 
> > It also gave me an excuse to start digging
> > into the rsyslog code.
> >
> > At first I thought I could do it with a property replacer, but that
> > seems a wash since those are wholly message-based and don't [seem
to]
> > give the opportunity to store information (even a running hash) of
> > prior messages.
> 
> That's right and that's by design. The property replacer is a one-way
> road.
> 
> > A plugin was my next hope, but there doesn't seem to
> > be a good mechanism to pipeline those together - AFAICT they're
> > expected to be single ingress/egress points, with no interstitial
> > stages.
> 
> That's definitely true for input and output plugins. They, by very
> definition, are at either end of the processing flow.
> 
> >  I see the code for loading other objects as Rainer mentioned
> > in April, but that seems more for central functionality than for
> > chaining modules together.
> 
> You are absolutely correct. These objects are (mostly) for internal
> things, so to save us static binding - and the ability to use
different
> drivers for different needs, e.g. for different network transport
> protocols (and maybe later for different, even-smaller and more
> abstracted, database drivers).
> 
> > This all brings me back to one of my original questions for rsyslog
-
> > is module chaining something that is even on your radar?  I'm
> thinking
> > normalization, hashing, encryption, etc.  Almost feels like there
> > should be another layer here, maybe a "mangle" plugin interface that
> > could stack in after im* and before om*?
> 
> You are definitely on the right route. If you look at the plugin
> definitions, there is another class, not yet implemented, of plugins:
> they are called "filter plugins". They will have the ability to take a
> message, modify it (or inject a new one based on previous messages)
and
> so on - at least this is how it was designed roughly a year ago.
> 
> With the arrival of the scripting language (in February, if I
correctly
> remember), new players have entered the field: library plugins that
> expose function calls to the script engine. So far, they do NOT yet
> exist, but they are pretty well thought out. They are probably the
> first
> thing I will implement when I start bringing the script engine to its
> full power. These functions may also be a good place to provide a
> "mangling" interface. I am still a bit undecided, maybe I will not
100%
> design this, but let the code evolve (sometimes, I think, it is good
to
> look at code written and see if that "extra bit" just naturally fits
> in...).
> 
> A bit problematic is the order of events (and message modification)
> when
> the message object is run asynchronously through multiple action
> queues.
> For each queue, the message is forked, so it requires careful design
> when to modify which of the forked messages. This can be very
powerful,
> but also quite complex to configure (where the scripting language
> hopefully comes in handy).
> 
> Another, internal, thing is message synchronization. So far, property
> creation and modification never requires sync objects (like mutexes),
> because the always happen in a single thread (for ONE specific
message,
> of course). With mangling capabilities, things change considerably,
> property set methods than need sync capability. This must be
> implemented
> in a way that does not hurt the (for more frequent) case of message
> object creation.
> 
> Of course, all of this is doable and the base design is there :) I
just
> wanted to provide an idea why it may take a little while to implement.
> Comments and suggestions are most welcome, especially as this is among
> the next things on my todo list (if priorities don't change).
> 
> Rainer
> >
> >
> > RB
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Tue Sep  2 12:47:08 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 2 Sep 2008 12:47:08 +0200
Subject: [rsyslog] preview of 3.21.4 devel
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F073@grfint2.intern.adiscon.com>

Hi all,

I am about to release 3.21.4, BUT it contains one big change and I would
appreciate if some of you could give it a try before I officially
release it. In 3.21.4, I have removed the compile-time hardcoded maximum
message size. So far, a message, by default, could be 2K maximum. This
could be changed by modifying the MAXLINE compile time default (and
recompiling/install). This size limit stems back to plain old BSD
syslogd, RFC 3164 (where it is 1k) and the upcoming syslog RFC series
(where it is variable, but 2k is suggested as a minimum). There have
been a lot of questions about larger sizes. So I have now streamlined
the process and created a simple config directive:

$MaxMessageSize 4k

Where 4k is of your choice. You may also specify any non-k value, like
7341. I do not check for a sensible maximum, so you may also specify 4p
(4 petabyte), but I hardly believe that will get you a working instance
;)

I did not blindly change the message size - I tried to keep performance
as good as with the previous approach (dyn memory alloc takes more
time!). So there is chance for failure all over the code. In my test (up
to now), everything works, but I would really appreciate some feedback
from practice.

Please let me know if you experience any issues with that release.

It is available at

http://download.rsyslog.com/rsyslog/rsyslog-3.21.4-Test1.tar.gz

This version also contains a number of smaller fixes, but not yet the
new doc building system (this is next on my agenda).

Your feedback is appreciated.

Rainer


From r.bhatia at ipax.at  Thu Sep  4 10:21:54 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 04 Sep 2008 10:21:54 +0200
Subject: [rsyslog] Problems with spooling to disk
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44EFC8@grfint2.intern.adiscon.com>
References: <20080807120552.GA16724@darville.vm.bytemark.co.uk><577465F99B41C842AAFBE9ED71E70ABA44EF6B@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44EF80@grfint2.intern.adiscon.com><48A2BFA7.8000408@ipax.at>	<1218630780.7184.368.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44EFC8@grfint2.intern.adiscon.com>
Message-ID: <48BF9AA2.1070904@ipax.at>

hi,

i yesterday deployed 3.18.3 and verified that the fix you told specified
below is in the source.

unfortunatly, this does not help and rsyslog hangs. please follow the
steps below to reproduce the error:

1) setup two servers. A is the rsyslog "client" and B is the rsyslog
   server logging to mysql.

A is configured with the debian default config and:
> $WorkDirectory /var/spool/rsyslog/ # where to place spool files
> $ActionQueueFileName remote # unique name prefix for spool files
> $ActionQueueMaxDiskSpace 100M   # 100mb space limit (use as much as possible)
> $ActionQueueSaveOnShutdown on # save messages to disk on shutdown
> $ActionQueueType LinkedList   # run asynchronously
> $ActionResumeRetryCount -1    # infinite retries if host is down
> # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
> *.* @@b.ipax.at:514

B is configured with the debian default config and:
> # provides UDP syslog reception
> $ModLoad imudp
> $UDPServerRun 514
> 
> # provides TCP syslog reception
> $ModLoad imtcp
> $InputTCPServerRun 514
> ...
> $ModLoad ommysql
> :programname, isequal, "prog1" ~
> :programname, isequal, "prog2" ~
> *.* :ommysql:localhost,Syslog,dbuser,dbpass

2) we start A and B and verify that it works correctly:
messages on A are logged to /var/log/ and sent to B

messages on B (= originating from A and B) are logged to /var/log/ and
are sent to the mysql db.

3) i connect to the mysql db and run some sql statements:
> delete from SystemEvents where SysLogTag like "prog1[%";
> delete from SystemEvents where SysLogTag like "prog2[%";
> delete from SystemEvents where SysLogTag like "pam_limits[%";

4) whilst the statement is running, issue the following command on B:
> logger testt

5) observe that testt is neither logged to the mysql db (thats expected
as delete locks the myisam table) but also not logged to /var/log/

this effectivly blocks something causing server A to not function
properly. e.g. apache2, sshd, bind, etc are not working properly.

please help :)

cheers,
raoul


Rainer Gerhards wrote:
> This is the v3-stable fix:
> 
> http://git.adiscon.com/?p=rsyslog.git;a=blobdiff;f=plugins/imuxsock/imux
> sock.c;h=60ccaffbc526a03011be3ce5869e40bc3e32c319;hp=f8798039c5d53e58fc7
> fa17807547862e08c999e;hb=8eb888d049da12e1294a7688432b6325794ade32;hpb=02
> f768c37dac9dde424bbd31e378482750fc276c
> 
> You can also easily apply it to 3.16 - I just won't do it that version
> has been superseded.
> 
> Rainer
> 
>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
>> Sent: Wednesday, August 13, 2008 2:33 PM
>> To: rsyslog-users
>> Subject: Re: [rsyslog] Problems with spooling to disk
>>
>> On Wed, 2008-08-13 at 13:04 +0200, Raoul Bhatia [IPAX] wrote:
>>> hi,
>>>
>>> Rainer Gerhards wrote:
>>>> Thanks, I now received the log files. And, of course, they made
>>>> immediately clear what is going on ;) What you experience is flow
>>>> control kicking in. Let me first elaborate a bit:
>>>>
>>>> Rsyslog knows inputs which can be delayed a bit (like tcp receiver
>> AND
>>>> the local socket) and those who can not (like UDP). The idea is
>> that we
>>>> can slow down senders where this does not result in loss of
>> messages,
>>>> leaving room inside the queue on busy systems for those where we
>> can not
>>>> do that. We had cases where not delaying caused a lot of grief.
>>>>
>>>> There are also two watermarks, the low and high delay mark. If the
>> low
>>>> delay mark is reached, a delayable source is delayed for one
>> second. It
>>>> is at 70% of the (in-memory) queue capacity. Again, this is all
>> done for
>>>> some very good reasons.
>>>>
>>>> However, when I introduced these features, I did not make them
>>>> configurable. Also, I did classify the local unix socket as one
> who
>> can
>>>> be delayed. In your scenario, this does not stop the system, but
>> once
>>>> the local log socket is filled up, it needs to wait one second for
>> each
>>>> message before it is pulled.
>>>>
>>>> Again, the rate limiting logic is there for good reasons. So what
> I
>> now
>>>> see is that I need to add a few config statements to allow to
>> control it
>>>> according to your needs. I am also unsure if I should re-classify
>>>> imuxsock as an input which cannot be delayed - but that also can
>> have
>>>> some drawbacks. Maybe the best thing to do is make its state
>>>> configurable and use "not to be delayed" as default.
>>> ok, after reading through your explanation, i (almost) understand
> the
>>> delay mechanism and that at present it is not configurable.
>>>
>>> almost, because i do not get the part where you talk about the "70%
>> of
>>> the (in-memory) queue capacity".
>> An example: if the configured queue capacity is 10,000 (the default
>> value for the main message queue), than no flow control at all happens
>> until 7,000 messages are inside the queue. Once they are (and only as
>> long as they are), flow control is applied to those inputs that permit
>> it (imuxsock permits it).
>>
>> It doesn't matter here if the queue is disk-assisted or not. Even with
>> disk-assisted queues, this setting is very important to prevent an
>> input
>> (e.g. imfile!) to send massive amounts of data to the queue when there
>> is no need to (because the input can be flow-controlled).
>>
>>> anyways, how does this relate to the original problem, that the
>>> following code stalls the logging process.
>>>
>>>>>> #! /bin/sh
>>>>>> for ((i=1;i<=10000;i+=1)); do
>>>>>>   logger Log line $i
>>>>>> done
>>> is this a capacity problem? is this another problem?
>> It is going over the flow control watermark, flow control kicks in and
>> delays imuxsock writes by one second each as long as there are more
>> than
>> 7,000 messages. No problem, intended behavior, but obviously
>> questionable. In the imuxsock case, there are also some bad cases.
>>
>>> i really consider this a critical bug, as i yesterday ran out of
>>> diskspace on my remote-rsyslog-and-mysql-on-one-host-testbed and the
>>> rsyslog-client, which logs locally and to the remote destination,
>>> stalled completely.
>> We'll - not completely, one message per second ;) But that's probably
>> complete enough ;)
>>
>> As a quick fix, I think I'll make imuxsock a non-flow-controllable
>> input
>> in the v3-stable (3.18.x). The devel will have a switch to make it
> flow
>> controlled if one desires. I'll also add some other knobs to fine-tune
>> the flow control algo, but that probably needs to wait until after my
>> summer break. These tweaks could easily break things and I don't like
>> the idea of doing them under time pressure ;)
>>
>> HTH
>> Rainer
>>> cheers,
>>> raoul
>>> ps: i am on 3.16.1-1~bpo40+1
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep  4 10:26:19 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 4 Sep 2008 10:26:19 +0200
Subject: [rsyslog] Problems with spooling to disk
In-Reply-To: <48BF9AA2.1070904@ipax.at>
References: <20080807120552.GA16724@darville.vm.bytemark.co.uk><577465F99B41C842AAFBE9ED71E70ABA44EF6B@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44EF80@grfint2.intern.adiscon.com><48A2BFA7.8000408@ipax.at>	<1218630780.7184.368.camel@rgf9dev.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44EFC8@grfint2.intern.adiscon.com>
	<48BF9AA2.1070904@ipax.at>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0A0@grfint2.intern.adiscon.com>

Hi Raoul,

could you quickly mail me a debug log of the client? I know I can set up
the lab per your instructions, but that will need some time. Depending
on what I see in the debug log, we could come much quicker to a solution
[I am currently quite busy after my vacation, so I will probably not be
able to set up the lab this week] ;). You can mail the log to me
privately.

Thanks,
Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX]
> Sent: Thursday, September 04, 2008 10:22 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] Problems with spooling to disk
> 
> hi,
> 
> i yesterday deployed 3.18.3 and verified that the fix you told
> specified
> below is in the source.
> 
> unfortunatly, this does not help and rsyslog hangs. please follow the
> steps below to reproduce the error:
> 
> 1) setup two servers. A is the rsyslog "client" and B is the rsyslog
>    server logging to mysql.
> 
> A is configured with the debian default config and:
> > $WorkDirectory /var/spool/rsyslog/ # where to place spool files
> > $ActionQueueFileName remote # unique name prefix for spool files
> > $ActionQueueMaxDiskSpace 100M   # 100mb space limit (use as much as
> possible)
> > $ActionQueueSaveOnShutdown on # save messages to disk on shutdown
> > $ActionQueueType LinkedList   # run asynchronously
> > $ActionResumeRetryCount -1    # infinite retries if host is down
> > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
> > *.* @@b.ipax.at:514
> 
> B is configured with the debian default config and:
> > # provides UDP syslog reception
> > $ModLoad imudp
> > $UDPServerRun 514
> >
> > # provides TCP syslog reception
> > $ModLoad imtcp
> > $InputTCPServerRun 514
> > ...
> > $ModLoad ommysql
> > :programname, isequal, "prog1" ~
> > :programname, isequal, "prog2" ~
> > *.* :ommysql:localhost,Syslog,dbuser,dbpass
> 
> 2) we start A and B and verify that it works correctly:
> messages on A are logged to /var/log/ and sent to B
> 
> messages on B (= originating from A and B) are logged to /var/log/ and
> are sent to the mysql db.
> 
> 3) i connect to the mysql db and run some sql statements:
> > delete from SystemEvents where SysLogTag like "prog1[%";
> > delete from SystemEvents where SysLogTag like "prog2[%";
> > delete from SystemEvents where SysLogTag like "pam_limits[%";
> 
> 4) whilst the statement is running, issue the following command on B:
> > logger testt
> 
> 5) observe that testt is neither logged to the mysql db (thats
expected
> as delete locks the myisam table) but also not logged to /var/log/
> 
> this effectivly blocks something causing server A to not function
> properly. e.g. apache2, sshd, bind, etc are not working properly.
> 
> please help :)
> 
> cheers,
> raoul
> 
> 
> Rainer Gerhards wrote:
> > This is the v3-stable fix:
> >
> >
>
http://git.adiscon.com/?p=rsyslog.git;a=blobdiff;f=plugins/imuxsock/imu
> x
> >
>
sock.c;h=60ccaffbc526a03011be3ce5869e40bc3e32c319;hp=f8798039c5d53e58fc
> 7
> >
>
fa17807547862e08c999e;hb=8eb888d049da12e1294a7688432b6325794ade32;hpb=0
> 2
> > f768c37dac9dde424bbd31e378482750fc276c
> >
> > You can also easily apply it to 3.16 - I just won't do it that
> version
> > has been superseded.
> >
> > Rainer
> >
> >> -----Original Message-----
> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >> Sent: Wednesday, August 13, 2008 2:33 PM
> >> To: rsyslog-users
> >> Subject: Re: [rsyslog] Problems with spooling to disk
> >>
> >> On Wed, 2008-08-13 at 13:04 +0200, Raoul Bhatia [IPAX] wrote:
> >>> hi,
> >>>
> >>> Rainer Gerhards wrote:
> >>>> Thanks, I now received the log files. And, of course, they made
> >>>> immediately clear what is going on ;) What you experience is flow
> >>>> control kicking in. Let me first elaborate a bit:
> >>>>
> >>>> Rsyslog knows inputs which can be delayed a bit (like tcp
receiver
> >> AND
> >>>> the local socket) and those who can not (like UDP). The idea is
> >> that we
> >>>> can slow down senders where this does not result in loss of
> >> messages,
> >>>> leaving room inside the queue on busy systems for those where we
> >> can not
> >>>> do that. We had cases where not delaying caused a lot of grief.
> >>>>
> >>>> There are also two watermarks, the low and high delay mark. If
the
> >> low
> >>>> delay mark is reached, a delayable source is delayed for one
> >> second. It
> >>>> is at 70% of the (in-memory) queue capacity. Again, this is all
> >> done for
> >>>> some very good reasons.
> >>>>
> >>>> However, when I introduced these features, I did not make them
> >>>> configurable. Also, I did classify the local unix socket as one
> > who
> >> can
> >>>> be delayed. In your scenario, this does not stop the system, but
> >> once
> >>>> the local log socket is filled up, it needs to wait one second
for
> >> each
> >>>> message before it is pulled.
> >>>>
> >>>> Again, the rate limiting logic is there for good reasons. So what
> > I
> >> now
> >>>> see is that I need to add a few config statements to allow to
> >> control it
> >>>> according to your needs. I am also unsure if I should re-classify
> >>>> imuxsock as an input which cannot be delayed - but that also can
> >> have
> >>>> some drawbacks. Maybe the best thing to do is make its state
> >>>> configurable and use "not to be delayed" as default.
> >>> ok, after reading through your explanation, i (almost) understand
> > the
> >>> delay mechanism and that at present it is not configurable.
> >>>
> >>> almost, because i do not get the part where you talk about the
"70%
> >> of
> >>> the (in-memory) queue capacity".
> >> An example: if the configured queue capacity is 10,000 (the default
> >> value for the main message queue), than no flow control at all
> happens
> >> until 7,000 messages are inside the queue. Once they are (and only
> as
> >> long as they are), flow control is applied to those inputs that
> permit
> >> it (imuxsock permits it).
> >>
> >> It doesn't matter here if the queue is disk-assisted or not. Even
> with
> >> disk-assisted queues, this setting is very important to prevent an
> >> input
> >> (e.g. imfile!) to send massive amounts of data to the queue when
> there
> >> is no need to (because the input can be flow-controlled).
> >>
> >>> anyways, how does this relate to the original problem, that the
> >>> following code stalls the logging process.
> >>>
> >>>>>> #! /bin/sh
> >>>>>> for ((i=1;i<=10000;i+=1)); do
> >>>>>>   logger Log line $i
> >>>>>> done
> >>> is this a capacity problem? is this another problem?
> >> It is going over the flow control watermark, flow control kicks in
> and
> >> delays imuxsock writes by one second each as long as there are more
> >> than
> >> 7,000 messages. No problem, intended behavior, but obviously
> >> questionable. In the imuxsock case, there are also some bad cases.
> >>
> >>> i really consider this a critical bug, as i yesterday ran out of
> >>> diskspace on my remote-rsyslog-and-mysql-on-one-host-testbed and
> the
> >>> rsyslog-client, which logs locally and to the remote destination,
> >>> stalled completely.
> >> We'll - not completely, one message per second ;) But that's
> probably
> >> complete enough ;)
> >>
> >> As a quick fix, I think I'll make imuxsock a non-flow-controllable
> >> input
> >> in the v3-stable (3.18.x). The devel will have a switch to make it
> > flow
> >> controlled if one desires. I'll also add some other knobs to fine-
> tune
> >> the flow control algo, but that probably needs to wait until after
> my
> >> summer break. These tweaks could easily break things and I don't
> like
> >> the idea of doing them under time pressure ;)
> >>
> >> HTH
> >> Rainer
> >>> cheers,
> >>> raoul
> >>> ps: i am on 3.16.1-1~bpo40+1
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> 
> 
> --
> ____________________________________________________________________
> DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
> Technischer Leiter
> 
> IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
> Barawitzkagasse 10/2/2/11           email.            office at ipax.at
> 1190 Wien                           tel.               +43 1 3670030
> FN 277995t HG Wien                  fax.            +43 1 3670030 15
> ____________________________________________________________________
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Thu Sep  4 11:52:40 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 04 Sep 2008 11:52:40 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080820170735.GB20932@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
Message-ID: <1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>

Hi,

I was now able to apply the patch series - many thanks. It is currently
in the docbook branch, which is also available on my public git server
(so that others can follow).

I am digging into what the patches actually do and, not surprisingly, I
finally need to learn a bit more about docbook to fully understand it
(looks like this gets my prime activity for the time being ;)).

One thing I already noticed. The man pages are generated via the
--enable-regenerate-man switch, but they are also in git. So when I
regenerate them, this results in a large volume of git changes.

In my POV, the man pages are now output files and as such no longer
something that belongs into git. I understand that this has the
implication that when I remove them from git, everyone who pulls the git
archive needs to have the proper tools in place to generate the doc.
However, is this really a problem? AFAIK other projects have similar
demands. So I would prefer to remove the man pages themselves from git
(but of course not from autotools config files, so that they be still
present in a release tarball).

Does this sound reasonable? Any objections (from anyone)?

I also have not yet fully understood the translation workflow. If
the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
be created with the English source doc, which I maintain)?

Please advise.

Thanks,
Rainer


On Thu, 2008-08-21 at 02:07 +0900, Satoru SATOH wrote:
> Hello,
> 
> 
> I posted the first patch but it seems the patch was too big to post. I
> list them here at once.
> 
> Could you please take some time to review these and merge them?
> 
> 
> I splitted origianl big patch into minimum units. However, to complete
> to man-i18n support, the following patches must be applied in this
> order.
> 
> All of the patches below are available from
> http://www.gnome.gr.jp/~ss/t/rsyslog/.
> 
> 
> 1. 0001-man-i18n-move-man-files-from-tools-to-man-C.patch
> 
> This patch just moves man files from tools/ to man/C/ (new dir to hold
> man related stuff) and update related Makefile.am files.
> 
> 
> 2. 0002-man-i18n-add-man-ja.patch
> 
> This patch creates new dir, man/ja/ and Makefile.am in it.
> 
> There are no man files in it and this should not have harmful effects
> for build process at all, I guess.
> 
> 
> 3. 0003-man-i18n-add-man-ja.patch
> 
> This patch adds man files in man/ja and update Makefile.am in it to
> install these.
> 
> 
> 4. 0004-man-i18n-add-docbook-xml-sources-for-man-files.patch
> 
> This patch adds docbook XML sources for man pages.
> 
> 
> 5. 0005-man-i18n-add-m4-macros-in-m4-and-make-aclocal-look.patch
> 
> This patch adds m4 macros in m4/ and make aclocal look for this dir.
> 
> These m4 files are not evaluated in actual and this should not have
> adverse effect at all, I guess.
> 
> 
> 6. 0006-man-i18n-add-build-process-of-man-pages-in-Makefile.patch
> 
> This patch adds transformation process of man pages and po files in
> Makefile.am.
> 
> Added part are in "if ENABLE_REGENERATE_MAN ... endif" and
> ENABLE_REGENERATE_MAN is not defined at this point, so this also should
> not have side effects.
> 
> 
> 7. 0007-man-i18n-add-enable-regenerate-man-option-for-con.patch
> 
> This is the last one. This patch adds "--enable-regenerate-man"
> configure option to enable man build process.
> 
> This option is disabled by default and should not affect normal build
> process, I think.
> 
> 
> How to build:
> 
> To enable the man build process, configure have to be regenerated:
> 
>   $ (autoreconf -vfi && \
>         ./configure --enable-regenerate-man [...other options] && \
>         make && make install
> 
> 
> Translator's workflow:
> 
>  a. initial translation:
> 
>    0. arrange lang dir, that is, cp man/ja to man/YOUR_LANG/ and edit
>       Makefile.am; s/ja/YOUR_LANG/.
>    1. create POT: make -C man/YOUR_LANG/ create-pot
>    2. copy POT to PO and translate it
>    3. run make
> 
>  b. maintanance:
> 
>    1. update PO: make -C man/YOUR_LANG update-po
>    2. update translations
>    3. just run make
> 
> 
> Requirements for man regeneration / translation:
>  
>    xmllint, xsltproc, xml2po in gnome-doc-utils, DocBook DTD and DocBook
>    xslt stylesheet for man pages are required.
> 
>    If xmlcatalog (e.g. /etc/xml/catalog) is configured appropriately,
>    both xmllint and xsltproc will use local DTD and stylsheet files
>    instead of these from remote site
>    (http://www.oasis-open.org/docbook/...).
> 
> 
> - satoru
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From friedl at hq.adiscon.com  Thu Sep  4 12:45:10 2008
From: friedl at hq.adiscon.com (Florian Riedl)
Date: Thu, 4 Sep 2008 12:45:10 +0200
Subject: [rsyslog] rsyslog 3.21.4 (devel) released
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0AA@grfint2.intern.adiscon.com>

Hi all,

we have just released rsyslog 3.21.4, a devel branch release. The most
important new feature is the ability to dynamically configure the
maximum length of a syslog message. Previously, this was only possible
via a recompile and can now be done via the new $MaxMessageSize config
directive. There are also a number of bugfixes new in this release. It
is a recommended update for all devel branch users.


Download:

http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-130.phtml

Changelog:

http://www.rsyslog.com/Article275.phtml

As always, feedback is appreciated.

Florian Riedl
--
Support
=======

Improving rsyslog is costly, but you can help!  We are looking for
organizations that find rsyslog useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for rsyslog are available, and they help
finance continued maintenance.  Adiscon GmbH, a privately held German
company, is currently funding rsyslog development. We are always looking
for interesting development projects. For details on how to help, please
see http://www.rsyslog.com/doc-how2help.html .



From satoru.satoh at gmail.com  Thu Sep  4 22:31:59 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Fri, 5 Sep 2008 05:31:59 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
Message-ID: <20080904203155.GA6912@localhost.localdomain>

Hi,


On Thu, Sep 04, 2008 at 11:52:40AM +0200, Rainer Gerhards wrote:
> Hi,
> 
> I was now able to apply the patch series - many thanks. It is currently
> in the docbook branch, which is also available on my public git server
> (so that others can follow).

Thanks!

> I am digging into what the patches actually do and, not surprisingly, I
> finally need to learn a bit more about docbook to fully understand it
> (looks like this gets my prime activity for the time being ;)).
> 
> One thing I already noticed. The man pages are generated via the
> --enable-regenerate-man switch, but they are also in git. So when I
> regenerate them, this results in a large volume of git changes.
 
Right.

> In my POV, the man pages are now output files and as such no longer
> something that belongs into git. I understand that this has the
> implication that when I remove them from git, everyone who pulls the git
> archive needs to have the proper tools in place to generate the doc.

Exactly. Addtional requirements are the followings.

 - xslt processor, xsltproc
 - xml validator, xmllint
 - properly configured xml catalog or internet access
 - docbook xml dtd (local or remote)
 - docbook xsl stylesheet for docbook-to-man transformation (local or
   remote)
 - xml2po in gnome-doc-utils (optional; must for translators)

I thought that not all of developers have such system and so that this
should be avoided. This is why I disabled man-regeneration process by
default.

> However, is this really a problem? AFAIK other projects have similar
> demands. So I would prefer to remove the man pages themselves from git
> (but of course not from autotools config files, so that they be still
> present in a release tarball).
> 
> Does this sound reasonable? Any objections (from anyone)?

One thing i have to mention.

Actually, man files generated from docbook xml files are slightly
different from original man files ATM. These need some refactoring.

If it's not a matter, it would be ok.

> I also have not yet fully understood the translation workflow. If
> the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
> version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
> be created with the English source doc, which I maintain)?

It is a little much complicated than that. Here are example steps for
german (de) man pages.


[initial translation]

  1. create mandir and makefile.am in it

     $ mkdir man/de && \
        sed 's/LANG = ja/LANG = de/' man/ja/Makefile.am > \
                man/de/Makefile.am

  2. add man/de/ to SUBDIRS in man/Makefile.am

     $ sed -i 's/^\(SUBDIRS.*\)/\1 de/' man/Makefile.am

  3. add man/de/Makefile.am to AC_CONFIG_FILES in configure.ac

  4. generate man/de/Makefile.am

     $ autoreconf -vfi && ./configure --prefix=$(pwd)/i \
        --enable-regenerate-man

  5. generate POT (PO template; language independent) and rename it 

     $ make -C man/de create-pot
     $ mv man/de/rsyslog.conf.5.pot man/de/rsyslog.conf.5.po
     $ mv man/de/rsyslogd.8.pot man/de/rsyslogd.8.po

  6. edit necessary header fields in PO files

     $ vim man/de/rsyslog.conf.5.po
     $ cat man/de/rsyslog.conf.5.po
     msgid ""
     msgstr ""
     "Project-Id-Version: rsyslog HEAD\n"
     "POT-Creation-Date: 2008-09-05 04:41+0900\n"
     "PO-Revision-Date: 2008-09-05 05:01+0900\n"
     "Last-Translator: XXXXX YYYYY <xxxxyyyyy at example.com>\n"
     "Language-Team: German <LL at li.org>\n"
     "MIME-Version: 1.0\n"
     "Content-Type: text/plain; charset=UTF-8\n"
     "Content-Transfer-Encoding: 8bit\n"

     (snip)

  7. translate PO files

  8. generate man files

     $ ./configure --prefix=$(pwd)/i --enable-regenerate-man && make


[update translations]

  1. update PO to follow changes in original docbook xml files

     $ make -C man/de update-po


Please refer to man/ja/Makefile.am also. 


BTW, "C" (man/C) means C (English) locale. This is the traditional dir
name to keep original English message catalogs, I think.

- satoru

(snip)
> > How to build:
> > 
> > To enable the man build process, configure have to be regenerated:
> > 
> >   $ (autoreconf -vfi && \
> >         ./configure --enable-regenerate-man [...other options] && \
> >         make && make install
> > 
> > 
> > Translator's workflow:
> > 
> >  a. initial translation:
> > 
> >    0. arrange lang dir, that is, cp man/ja to man/YOUR_LANG/ and edit
> >       Makefile.am; s/ja/YOUR_LANG/.
> >    1. create POT: make -C man/YOUR_LANG/ create-pot
> >    2. copy POT to PO and translate it
> >    3. run make
> > 
> >  b. maintanance:
> > 
> >    1. update PO: make -C man/YOUR_LANG update-po
> >    2. update translations
> >    3. just run make
> > 
> > 
> > Requirements for man regeneration / translation:
> >  
> >    xmllint, xsltproc, xml2po in gnome-doc-utils, DocBook DTD and DocBook
> >    xslt stylesheet for man pages are required.
> > 
> >    If xmlcatalog (e.g. /etc/xml/catalog) is configured appropriately,
> >    both xmllint and xsltproc will use local DTD and stylsheet files
> >    instead of these from remote site
> >    (http://www.oasis-open.org/docbook/...).
> > 
> > 
> > - satoru


From mbiebl at gmail.com  Thu Sep  4 22:53:38 2008
From: mbiebl at gmail.com (Michael Biebl)
Date: Thu, 4 Sep 2008 22:53:38 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080904203155.GA6912@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
Message-ID: <aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>

Hi,

just curious: Are you also working on getting the other documentation
in doc/ converted to docbook?
Something like [1] would be awesome for rsyslog and I think with
docbook, pdf would just be another output format, right?

While it is great to have documentation at all, the current one is a
bit inconsistent and hard to navigate.


Cheers,
Michael

[1] http://www.exim.org/exim-pdf-current/doc/spec.pdf
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


From rfujita at redhat.com  Fri Sep  5 03:06:25 2008
From: rfujita at redhat.com (Ryo Fujita)
Date: Fri, 5 Sep 2008 10:06:25 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
	<aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
Message-ID: <745EC623-B3A0-4FC8-B01C-91A9BD8B2892@redhat.com>

Hi,

Yes, I'm converting other documentation in doc/ to DocBook xml.
# About 40 docs out of 90 has been converted.

But there are some issues to convert and restructure them,
I consult with Rainer-san out of the ML.

Best Rio.

On 2008/09/05, at 5:53, Michael Biebl wrote:

> Hi,
>
> just curious: Are you also working on getting the other documentation
> in doc/ converted to docbook?
> Something like [1] would be awesome for rsyslog and I think with
> docbook, pdf would just be another output format, right?
>
> While it is great to have documentation at all, the current one is a
> bit inconsistent and hard to navigate.
>
>
> Cheers,
> Michael
>
> [1] http://www.exim.org/exim-pdf-current/doc/spec.pdf
> -- 
> 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

########################################################################
Ryo Fujita <rfujita at redhat.com>
Senior Solution Architect, RHCE
Red Hat K.K.
TEL +81-3-5798-8500
FAX +81-3-5798-8599
Ebisu Neonato 8F
4-1-18 Ebisu, Shibuya-ku,
Tokyo Japan 1500013
########################################################################



From rgerhards at hq.adiscon.com  Fri Sep  5 08:11:39 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 5 Sep 2008 08:11:39 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
References: <20080820170735.GB20932@localhost.localdomain><1220521960.12304.15.camel@rgf9dev.intern.adiscon.com><20080904203155.GA6912@localhost.localdomain>
	<aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0C5@grfint2.intern.adiscon.com>

Just one additional note:

> While it is great to have documentation at all, the current one is a
> bit inconsistent and hard to navigate.

Suggestions for improvement are welcome ;)

Rainer


From rgerhards at hq.adiscon.com  Fri Sep  5 10:42:03 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 05 Sep 2008 10:42:03 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080904203155.GA6912@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
Message-ID: <1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>

Hi,

first of all, many thanks for your continued help. Please let me say
that I so far have very little experience with i18n/l10n under linux and
so may sometimes misunderstand something ;) Your detailled instructions
help much. The rest inline...

Rainer

On Fri, 2008-09-05 at 05:31 +0900, Satoru SATOH wrote:
> Hi,
> > In my POV, the man pages are now output files and as such no longer
> > something that belongs into git. I understand that this has the
> > implication that when I remove them from git, everyone who pulls the git
> > archive needs to have the proper tools in place to generate the doc.
> 
> Exactly. Addtional requirements are the followings.
> 
>  - xslt processor, xsltproc
>  - xml validator, xmllint
>  - properly configured xml catalog or internet access
>  - docbook xml dtd (local or remote)
>  - docbook xsl stylesheet for docbook-to-man transformation (local or
>    remote)
>  - xml2po in gnome-doc-utils (optional; must for translators)
> 
> I thought that not all of developers have such system and so that this
> should be avoided. This is why I disabled man-regeneration process by
> default.

I agree that this may be a problem. However, I don't think it is a very
serious one. I myself have contributed to some projects where I could
not build the documentation. This did not cause any trouble to me while
working at the program sources. Of course, if I would like to create a
full tarball, I need to have everything in place. But only few actually
needs this (am I right here?).

In contrast, the tarball must include the generated mans, as the average
user can not be expected to have the tools at hand (while we still
expect him to have everything at hand necessary to compile the program
sources).

So I would remove the files from git, but leave them within the
distribution source tarball.

> > However, is this really a problem? AFAIK other projects have similar
> > demands. So I would prefer to remove the man pages themselves from git
> > (but of course not from autotools config files, so that they be still
> > present in a release tarball).
> > 
> > Does this sound reasonable? Any objections (from anyone)?
> 
> One thing i have to mention.
> 
> Actually, man files generated from docbook xml files are slightly
> different from original man files ATM. These need some refactoring.

Could you please elaborate a bit on this? Does that mean that the
generated man files (after doing a "make") can not be immediately be
used and need some kind of (manual?) post-processing?

> 
> If it's not a matter, it would be ok.
> 
> > I also have not yet fully understood the translation workflow. If
> > the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
> > version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
> > be created with the English source doc, which I maintain)?
> 
> It is a little much complicated than that. Here are example steps for
> german (de) man pages.

thanks for the detailed instructions, I'll first do a lab to get some experience first (plus read a bit more in various docs) and post questions when/if they come up.




From rgerhards at hq.adiscon.com  Fri Sep  5 16:01:41 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 05 Sep 2008 16:01:41 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080904203155.GA6912@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
Message-ID: <1220623301.12304.61.camel@rgf9dev.intern.adiscon.com>

Hi,


On Fri, 2008-09-05 at 05:31 +0900, Satoru SATOH wrote:
> [snip]

Thanks again for the good description. I think I now understand the
process, but I would like to make sure I really do.

First of all, there seems to be a minor nit with the current set of
files. Please have a look at what happens here:

--------------------------------
[root at rgf9dev rsyslog]# xml2po -v
0.12.2
[root at rgf9dev rsyslog]# make -C man/ja create-pot
make: Entering directory `/home/rger/proj/rsyslog/man/ja'
/usr/bin/xml2po -e -o rsyslogd.8.pot ../C/rsyslogd.8.xml
Traceback (most recent call last):
  File "/usr/bin/xml2po", line 856, in <module>
    doSerialize(doc)
  File "/usr/bin/xml2po", line 589, in doSerialize
    outtxt += doSerialize(child)
  File "/usr/bin/xml2po", line 583, in doSerialize
    (starttag, content, endtag, translation) = processElementTag(node,
repl, 1)
  File "/usr/bin/xml2po", line 525, in processElementTag
    translation = translation.replace('<placeholder-%d/>' % (i),
replacement)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
4930: ordinal not in range(128)
make: *** [rsyslogd.8.pot] Error 1
make: Leaving directory `/home/rger/proj/rsyslog/man/ja'
----------------------------------

Do you have an idea how I can find out what exactly to fix (I think I
understand that there is in invalid character in rsyslogd.8.xml, but the
error message is not very helpful at pointing me at the actual trouble
source ;)).

>From an upper level view, I now understand the workflow as follows:

When I update the documentation, I update the files in ./man/C. These
are kept in docbook format and these are the only sources for the
English language documentation.

After I have updated these files, every translator needs to run 

$ make -C man/<lang> update-po

to update the PO files. The translators will work on the .po files only.
When they are (sufficiently ;)) finished, the man files need to be
regenerated. Let me elaborate a bit on this process, I'd like to get to
some details.

As far as I understand, this results in the .po files being converted
back to docbook. Then, docbook is used to generate the ultimate
destination, e.g. the man files. The same process is used to generate
the English files, except that the docbook tools are run directly,
because there were no interim .po files.

Is this description correct? I am asking because I think it would make
sense to generate different formats (man, html, pdf at least) from the
same set of source files. So I understand that .po is just an interim
step which makes translation easier, but there will be a translated
version which in turn can be processed into any format that docbook
tools support.

I'd greatly appreciate your feedback. If you know how to do it, I would
also greatly appreciate if you could provide me a patch (or
instructions) on how to generate pdf from the "man files".

Thanks,
Rainer


> > I also have not yet fully understood the translation workflow. If
> > the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
> > version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
> > be created with the English source doc, which I maintain)?
> 
> It is a little much complicated than that. Here are example steps for
> german (de) man pages.
> 
> 
> [initial translation]
> 
>   1. create mandir and makefile.am in it
> 
>      $ mkdir man/de && \
>         sed 's/LANG = ja/LANG = de/' man/ja/Makefile.am > \
>                 man/de/Makefile.am
> 
>   2. add man/de/ to SUBDIRS in man/Makefile.am
> 
>      $ sed -i 's/^\(SUBDIRS.*\)/\1 de/' man/Makefile.am
> 
>   3. add man/de/Makefile.am to AC_CONFIG_FILES in configure.ac
> 
>   4. generate man/de/Makefile.am
> 
>      $ autoreconf -vfi && ./configure --prefix=$(pwd)/i \
>         --enable-regenerate-man
> 
>   5. generate POT (PO template; language independent) and rename it 
> 
>      $ make -C man/de create-pot
>      $ mv man/de/rsyslog.conf.5.pot man/de/rsyslog.conf.5.po
>      $ mv man/de/rsyslogd.8.pot man/de/rsyslogd.8.po
> 
>   6. edit necessary header fields in PO files
> 
>      $ vim man/de/rsyslog.conf.5.po
>      $ cat man/de/rsyslog.conf.5.po
>      msgid ""
>      msgstr ""
>      "Project-Id-Version: rsyslog HEAD\n"
>      "POT-Creation-Date: 2008-09-05 04:41+0900\n"
>      "PO-Revision-Date: 2008-09-05 05:01+0900\n"
>      "Last-Translator: XXXXX YYYYY <xxxxyyyyy at example.com>\n"
>      "Language-Team: German <LL at li.org>\n"
>      "MIME-Version: 1.0\n"
>      "Content-Type: text/plain; charset=UTF-8\n"
>      "Content-Transfer-Encoding: 8bit\n"
> 
>      (snip)
> 
>   7. translate PO files
> 
>   8. generate man files
> 
>      $ ./configure --prefix=$(pwd)/i --enable-regenerate-man && make
> 
> 
> [update translations]
> 
>   1. update PO to follow changes in original docbook xml files
> 
>      $ make -C man/de update-po
> 
> 
> Please refer to man/ja/Makefile.am also. 
> 
> 
> BTW, "C" (man/C) means C (English) locale. This is the traditional dir
> name to keep original English message catalogs, I think.
> 
> - satoru
> 
> (snip)
> > > How to build:
> > > 
> > > To enable the man build process, configure have to be regenerated:
> > > 
> > >   $ (autoreconf -vfi && \
> > >         ./configure --enable-regenerate-man [...other options] && \
> > >         make && make install
> > > 
> > > 
> > > Translator's workflow:
> > > 
> > >  a. initial translation:
> > > 
> > >    0. arrange lang dir, that is, cp man/ja to man/YOUR_LANG/ and edit
> > >       Makefile.am; s/ja/YOUR_LANG/.
> > >    1. create POT: make -C man/YOUR_LANG/ create-pot
> > >    2. copy POT to PO and translate it
> > >    3. run make
> > > 
> > >  b. maintanance:
> > > 
> > >    1. update PO: make -C man/YOUR_LANG update-po
> > >    2. update translations
> > >    3. just run make
> > > 
> > > 
> > > Requirements for man regeneration / translation:
> > >  
> > >    xmllint, xsltproc, xml2po in gnome-doc-utils, DocBook DTD and DocBook
> > >    xslt stylesheet for man pages are required.
> > > 
> > >    If xmlcatalog (e.g. /etc/xml/catalog) is configured appropriately,
> > >    both xmllint and xsltproc will use local DTD and stylsheet files
> > >    instead of these from remote site
> > >    (http://www.oasis-open.org/docbook/...).
> > > 
> > > 
> > > - satoru
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From jorge.fabregas at gmail.com  Fri Sep  5 16:03:03 2008
From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=)
Date: Fri, 5 Sep 2008 10:03:03 -0400
Subject: [rsyslog] Kernel facility & testing with logger command
Message-ID: <200809051003.03373.jorge.fabregas@gmail.com>

Hello everyone,

I'm using rsyslog for the first time and before getting into its features I'm 
doing some basic tests... This is a portion of what I have on my rsyslog.conf:

#KERN FACILITY
kern.=emerg     /var/log/syslog/kern/00-emerg
kern.=alert     /var/log/syslog/kern/01-alert
kern.=crit      /var/log/syslog/kern/02-crit
kern.=err       /var/log/syslog/kern/03-err
kern.=warning   /var/log/syslog/kern/04-warning
kern.=notice    /var/log/syslog/kern/05-notice
kern.=info      /var/log/syslog/kern/06-info
kern.=debug     /var/log/syslog/kern/07-debug

If I do any test with the logger command using the kern facility (and any 
severity) I don't see my message on any of the above files. Example:

logger -p kern.debug "this is a test"

I tried all the other facilities and they all work fine. It's just the kern 
facility. 

What am I missing ?  :)

Thanks in advance,
Jorge


From rgerhards at hq.adiscon.com  Fri Sep  5 16:04:30 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 5 Sep 2008 16:04:30 +0200
Subject: [rsyslog] Kernel facility & testing with logger command
In-Reply-To: <200809051003.03373.jorge.fabregas@gmail.com>
References: <200809051003.03373.jorge.fabregas@gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0DF@grfint2.intern.adiscon.com>

Out of my head, 98% sure: logger (and/or sylsog() call and or imuxsock) does not permit to use the kernel facility. This is to prevent someone from pretending to be the kernel.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Jorge F?bregas
> Sent: Friday, September 05, 2008 4:03 PM
> To: rsyslog at lists.adiscon.com
> Subject: [rsyslog] Kernel facility & testing with logger command
> 
> Hello everyone,
> 
> I'm using rsyslog for the first time and before getting into its
> features I'm
> doing some basic tests... This is a portion of what I have on my
> rsyslog.conf:
> 
> #KERN FACILITY
> kern.=emerg     /var/log/syslog/kern/00-emerg
> kern.=alert     /var/log/syslog/kern/01-alert
> kern.=crit      /var/log/syslog/kern/02-crit
> kern.=err       /var/log/syslog/kern/03-err
> kern.=warning   /var/log/syslog/kern/04-warning
> kern.=notice    /var/log/syslog/kern/05-notice
> kern.=info      /var/log/syslog/kern/06-info
> kern.=debug     /var/log/syslog/kern/07-debug
> 
> If I do any test with the logger command using the kern facility (and
> any
> severity) I don't see my message on any of the above files. Example:
> 
> logger -p kern.debug "this is a test"
> 
> I tried all the other facilities and they all work fine. It's just the
> kern
> facility.
> 
> What am I missing ?  :)
> 
> Thanks in advance,
> Jorge
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From hks.private at gmail.com  Fri Sep  5 16:55:11 2008
From: hks.private at gmail.com ((private) HKS)
Date: Fri, 5 Sep 2008 10:55:11 -0400
Subject: [rsyslog] Kernel facility & testing with logger command
In-Reply-To: <200809051003.03373.jorge.fabregas@gmail.com>
References: <200809051003.03373.jorge.fabregas@gmail.com>
Message-ID: <ac9ded160809050755sb94c292r65a003b22237980b@mail.gmail.com>

Can you paste in your full rsyslog.conf? It's difficult to
troubleshoot without knowing how you're setup.

-HKS

On Fri, Sep 5, 2008 at 10:03 AM, Jorge F?bregas
<jorge.fabregas at gmail.com> wrote:
> Hello everyone,
>
> I'm using rsyslog for the first time and before getting into its features I'm
> doing some basic tests... This is a portion of what I have on my rsyslog.conf:
>
> #KERN FACILITY
> kern.=emerg     /var/log/syslog/kern/00-emerg
> kern.=alert     /var/log/syslog/kern/01-alert
> kern.=crit      /var/log/syslog/kern/02-crit
> kern.=err       /var/log/syslog/kern/03-err
> kern.=warning   /var/log/syslog/kern/04-warning
> kern.=notice    /var/log/syslog/kern/05-notice
> kern.=info      /var/log/syslog/kern/06-info
> kern.=debug     /var/log/syslog/kern/07-debug
>
> If I do any test with the logger command using the kern facility (and any
> severity) I don't see my message on any of the above files. Example:
>
> logger -p kern.debug "this is a test"
>
> I tried all the other facilities and they all work fine. It's just the kern
> facility.
>
> What am I missing ?  :)
>
> Thanks in advance,
> Jorge
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From hks.private at gmail.com  Fri Sep  5 16:57:54 2008
From: hks.private at gmail.com ((private) HKS)
Date: Fri, 5 Sep 2008 10:57:54 -0400
Subject: [rsyslog] Kernel facility & testing with logger command
In-Reply-To: <ac9ded160809050755sb94c292r65a003b22237980b@mail.gmail.com>
References: <200809051003.03373.jorge.fabregas@gmail.com>
	<ac9ded160809050755sb94c292r65a003b22237980b@mail.gmail.com>
Message-ID: <ac9ded160809050757h72d919d5g12e41a54c600c2bf@mail.gmail.com>

Oh, and what your platform is.

-HKS

On Fri, Sep 5, 2008 at 10:55 AM, (private) HKS <hks.private at gmail.com> wrote:
> Can you paste in your full rsyslog.conf? It's difficult to
> troubleshoot without knowing how you're setup.
>
> -HKS
>
> On Fri, Sep 5, 2008 at 10:03 AM, Jorge F?bregas
> <jorge.fabregas at gmail.com> wrote:
>> Hello everyone,
>>
>> I'm using rsyslog for the first time and before getting into its features I'm
>> doing some basic tests... This is a portion of what I have on my rsyslog.conf:
>>
>> #KERN FACILITY
>> kern.=emerg     /var/log/syslog/kern/00-emerg
>> kern.=alert     /var/log/syslog/kern/01-alert
>> kern.=crit      /var/log/syslog/kern/02-crit
>> kern.=err       /var/log/syslog/kern/03-err
>> kern.=warning   /var/log/syslog/kern/04-warning
>> kern.=notice    /var/log/syslog/kern/05-notice
>> kern.=info      /var/log/syslog/kern/06-info
>> kern.=debug     /var/log/syslog/kern/07-debug
>>
>> If I do any test with the logger command using the kern facility (and any
>> severity) I don't see my message on any of the above files. Example:
>>
>> logger -p kern.debug "this is a test"
>>
>> I tried all the other facilities and they all work fine. It's just the kern
>> facility.
>>
>> What am I missing ?  :)
>>
>> Thanks in advance,
>> Jorge
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>
>


From satoru.satoh at gmail.com  Fri Sep  5 17:28:18 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Sat, 6 Sep 2008 00:28:18 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <1220623301.12304.61.camel@rgf9dev.intern.adiscon.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
	<1220623301.12304.61.camel@rgf9dev.intern.adiscon.com>
Message-ID: <20080905152813.GA9242@localhost.localdomain>

Hi,

On Fri, Sep 05, 2008 at 04:01:41PM +0200, Rainer Gerhards wrote:
> First of all, there seems to be a minor nit with the current set of
> files. Please have a look at what happens here:
> 
> --------------------------------
> [root at rgf9dev rsyslog]# xml2po -v
> 0.12.2
> [root at rgf9dev rsyslog]# make -C man/ja create-pot
> make: Entering directory `/home/rger/proj/rsyslog/man/ja'
> /usr/bin/xml2po -e -o rsyslogd.8.pot ../C/rsyslogd.8.xml
(snip)
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
> 4930: ordinal not in range(128)
> make: *** [rsyslogd.8.pot] Error 1
> make: Leaving directory `/home/rger/proj/rsyslog/man/ja'
> ----------------------------------
> Do you have an idea how I can find out what exactly to fix (I think I
> understand that there is in invalid character in rsyslogd.8.xml, but the
> error message is not very helpful at pointing me at the actual trouble
> source ;)).
 
This is an well-known annoying issue of python. 'ascii' is the default
internal encoding so that this happens.

There are many ways to "fix" this but to upgrade the latest
gnome-doc-utils (0.13.1; this problem is solved already), looks the
best.

> >From an upper level view, I now understand the workflow as follows:
> 
> When I update the documentation, I update the files in ./man/C. These
> are kept in docbook format and these are the only sources for the
> English language documentation.
> 
> After I have updated these files, every translator needs to run 
> 
> $ make -C man/<lang> update-po
> 
> to update the PO files. The translators will work on the .po files only.

correct if [s]he or other made the required files (PO) already.

> When they are (sufficiently ;)) finished, the man files need to be
> regenerated. Let me elaborate a bit on this process, I'd like to get to
> some details.
> 
> As far as I understand, this results in the .po files being converted
> back to docbook. Then, docbook is used to generate the ultimate
> destination, e.g. the man files. The same process is used to generate
> the English files, except that the docbook tools are run directly,
> because there were no interim .po files.

exactly. DocBook XML files just play an intermediate format role 
  
  a. to generate man pages (result)
  b. to generate POT (and PO indirectly) to facilitate translation

> Is this description correct? I am asking because I think it would make
> sense to generate different formats (man, html, pdf at least) from the
> same set of source files. So I understand that .po is just an interim
> step which makes translation easier, but there will be a translated
> version which in turn can be processed into any format that docbook
> tools support.

absolutely correct.

> I'd greatly appreciate your feedback. If you know how to do it, I would
> also greatly appreciate if you could provide me a patch (or
> instructions) on how to generate pdf from the "man files".
(snip)

OK, I'll try to make it. wait for a while, please.

Unfortunatelly, xml to pdf transformation process is much complicate
than html/man/other text based formats and it brings another
dependencies - fonts and XSL-FO processor :-P

- satoru


From satoru.satoh at gmail.com  Fri Sep  5 17:59:35 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Sat, 6 Sep 2008 00:59:35 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
	<1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>
Message-ID: <20080905155931.GB9242@localhost.localdomain>

On Fri, Sep 05, 2008 at 10:42:03AM +0200, Rainer Gerhards wrote:
> > I thought that not all of developers have such system and so that this
> > should be avoided. This is why I disabled man-regeneration process by
> > default.
> 
> I agree that this may be a problem. However, I don't think it is a very
> serious one. I myself have contributed to some projects where I could
> not build the documentation. This did not cause any trouble to me while
> working at the program sources. Of course, if I would like to create a
> full tarball, I need to have everything in place. But only few actually
> needs this (am I right here?).

right. Who needs required tools and files are

 a. developers do git-pull *and* modify man sources
 b. translators contribute initial translation or update it
 c. others just want ;-) to switch on '--enable-regenerate-man' option

> In contrast, the tarball must include the generated mans, as the average
> user can not be expected to have the tools at hand (while we still
> expect him to have everything at hand necessary to compile the program
> sources).
(snip)
 
This should be accomplished already, I think.

I made all related stuff (xml, po, man) in EXTRA_DIST so that these will
be in the archive generated by 'make dist'. 

> > Actually, man files generated from docbook xml files are slightly
> > different from original man files ATM. These need some refactoring.
> 
> Could you please elaborate a bit on this? Does that mean that the
> generated man files (after doing a "make") can not be immediately be
> used and need some kind of (manual?) post-processing?
 
No. There should be no any problems to convert xml files to man pages
but the result *looks* may different.

Transition from man (roff) to DocBook XML is similar to the transition
from old HTML to XHTML + CSS. The authors/editors/writers have to
concentrate attention at the *logical* structure of the text instead of
its appearance.

It's typical that many HTML tags to control appearance found in old HTML
sources and it makes impossible to keep complete same look in new XHTML
+ CSS sources.

- satoru


From rgerhards at hq.adiscon.com  Mon Sep  8 10:24:56 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 8 Sep 2008 10:24:56 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080905155931.GB9242@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain><1220521960.12304.15.camel@rgf9dev.intern.adiscon.com><20080904203155.GA6912@localhost.localdomain><1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>
	<20080905155931.GB9242@localhost.localdomain>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0E6@grfint2.intern.adiscon.com>

Hi,

thanks again for your insight. I'll now remove the (generated) man files
from git, but will leave them inside the tarball. I think that is a
workable solution.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Satoru SATOH
> Sent: Friday, September 05, 2008 6:00 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] [PATCH] man-i18n patches summary
> 
> On Fri, Sep 05, 2008 at 10:42:03AM +0200, Rainer Gerhards wrote:
> > > I thought that not all of developers have such system and so that
> this
> > > should be avoided. This is why I disabled man-regeneration process
> by
> > > default.
> >
> > I agree that this may be a problem. However, I don't think it is a
> very
> > serious one. I myself have contributed to some projects where I
could
> > not build the documentation. This did not cause any trouble to me
> while
> > working at the program sources. Of course, if I would like to create
> a
> > full tarball, I need to have everything in place. But only few
> actually
> > needs this (am I right here?).
> 
> right. Who needs required tools and files are
> 
>  a. developers do git-pull *and* modify man sources
>  b. translators contribute initial translation or update it
>  c. others just want ;-) to switch on '--enable-regenerate-man' option
> 
> > In contrast, the tarball must include the generated mans, as the
> average
> > user can not be expected to have the tools at hand (while we still
> > expect him to have everything at hand necessary to compile the
> program
> > sources).
> (snip)
> 
> This should be accomplished already, I think.
> 
> I made all related stuff (xml, po, man) in EXTRA_DIST so that these
> will
> be in the archive generated by 'make dist'.
> 
> > > Actually, man files generated from docbook xml files are slightly
> > > different from original man files ATM. These need some
refactoring.
> >
> > Could you please elaborate a bit on this? Does that mean that the
> > generated man files (after doing a "make") can not be immediately be
> > used and need some kind of (manual?) post-processing?
> 
> No. There should be no any problems to convert xml files to man pages
> but the result *looks* may different.
> 
> Transition from man (roff) to DocBook XML is similar to the transition
> from old HTML to XHTML + CSS. The authors/editors/writers have to
> concentrate attention at the *logical* structure of the text instead
of
> its appearance.
> 
> It's typical that many HTML tags to control appearance found in old
> HTML
> sources and it makes impossible to keep complete same look in new
XHTML
> + CSS sources.
> 
> - satoru
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Thu Sep 11 15:27:49 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 11 Sep 2008 15:27:49 +0200
Subject: [rsyslog] docbook and math
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F12B@grfint2.intern.adiscon.com>

Hi folks,

and especially those that are proficient with docbook ;) I have one
question. I am thinking about a series of design papers. I think,
however, that at least some of them will require a lot of mathematical
formulas. Typically, I'd say that should be done in LaTeX. But with
moving to docbook for the user doc, it may be good to use a single
system.

I have now investigated docbook and maths a bit, but what I found didn't
look very promising. The best I found was MathML, which is far too
verbose for any hand-editing (and I don't want to rely on specialized
formula editors). I also found some references to embedded TeX, but that
looked quite hackish.

Could somebody enlighten me on the current typical approach for such
papers? Do they still usually go the LaTeX way or is there a good way to
do it with docbook?

Many thanks in advance,
Rainer


From david at lang.hm  Mon Sep 15 07:30:15 2008
From: david at lang.hm (david at lang.hm)
Date: Sun, 14 Sep 2008 22:30:15 -0700 (PDT)
Subject: [rsyslog] making a custom input module
Message-ID: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>

my second project is to try and modify rsyslog to recieve logs from an 
application. the application sends the logs over TCP and expects an 
application-level handshake (very similar to relp). at the moment I want 
to try and avoid having to change the application (many different products 
with different release schedules), and instead teach rsyslog to deal with 
the existing log format.

at the moment I am trying to understand the imtcp module, but I am getting 
lost in the callbacks. it looks like rsyslog is calling a routine in 
imtcp, which calls a routine in tcpsrv, which calls a routine somewhere 
else to actually recieve the log.

ideally what I would like to use is to take imtcp and replace the message 
recieving/parsing logic with my own, then have it submit the parsed 
message into the queue (which looks like it would be via the SubmitMsg() 
call).

but at the moment I am lost in the twisty maze of function calls between 
source files, all of which look different.

I'm also not clear on what fields inside of the Msg structure need to be 
populated. looking at Msg.c/h I see a lot of fields there, but it looks 
like many/most of them are optional.

any pointers?

David Lang


From david at lang.hm  Mon Sep 15 07:23:11 2008
From: david at lang.hm (david at lang.hm)
Date: Sun, 14 Sep 2008 22:23:11 -0700 (PDT)
Subject: [rsyslog] optimization questions
Message-ID: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>

I've got a couple projects I'm working on that rsyslog is looking like a 
good answer to. I'm going to send questions about them in seperate 
messages.

the first project is a traditional syslog server. I've been testing 
various syslog implementations to find out what sort of performance they 
can sustain.

I've gotten the (almost) standard sysklogd to sustail almost 30,000 
messages/sec (udp) before it starts loosing significant numbers of logs

rsyslog is able to handle bursts of around 150,000 messages/sec, but it 
doesn't seem to write them out very fast, and over time seems to be 
limited to ~22,000 messages/sec

the hardware I am running this test on is insanely overpowered (four 
dual-core opterons, 16G of ram, battery-backed cache on a raid card with 
high-speed SAS drives). in production I will be working with slower 
hardware, but I'm trying to find the limits of the software before I start 
introducing lower hardware limits.

what can I look at doing to speed up the writing of data from the queues? 
does rsyslog write the messages one at a time, or does it have an option 
for writing them in batches (pulling a bunch off of the queue and sending 
them all at once)?

some sort of batch mode would be critical for writes to a database where 
you can frequently get 1000x speedups if you do the inserts as a single 
transaction as opposed to individual transactions.

David Lang


From david at lang.hm  Mon Sep 15 08:13:43 2008
From: david at lang.hm (david at lang.hm)
Date: Sun, 14 Sep 2008 23:13:43 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
Message-ID: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>

looking through the rsyslog.conf man page I see ways to tell rsyslogd to 
run a command when a file is over a given size, but I see no examples or 
details of what that command can/should do.

what I want to do is to move the file out of the way, kick rsyslogd so 
that it starts writing to a new file, then compress the old file (which 
can take a significant amount of time)

traditionally I have rotated syslogs by doing a mv of the logfile followed 
by a kill -HUP of the syslog process (usually out of crontab)

In my testing of rsyslog I have been doing this, but once in a while 
rsyslog doesn't release the file it's writing and start a new one, instead 
it keeps writing to the old file.

so this means that my command can't spawn a background task that does a mv 
of the file followed by a kill -HUP of rsyslogd.

what should I be doing?

David Lang



From rgerhards at hq.adiscon.com  Mon Sep 15 08:39:24 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 08:39:24 +0200
Subject: [rsyslog] optimization questions
In-Reply-To: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>
Message-ID: <1221460764.2682.9.camel@rgf9dev.intern.adiscon.com>

Hi David,

thanks for your message and interest. This is very welcome as I would
really like to get hold of more insight into rsyslog's performance in
real-world and extreme scenarios. So far, I have unfortunately been
unable to do that, because I had no funding for the required hardware
and time to conduct the testing. I would *really* appreciate if you
could help with that and I would be very willing to tweak the code for
optimum performance (actually, I am always very concerned about high
performance and I was a bit sad about the fact that I could not ensure
it).

Having said that, I'd first of all would like to have a look at your
rsyslog.conf, so that we are on common ground. Also, I think, this can
become quite lengthy and also of interest for others. May it be useful
to discuss this on the web forum, so that we can easier keep track of
things. If you think this is useful, I recommend this one here:

http://kb.monitorware.com/general-f34.html

some more comments inline:

On Mon, 2008-09-15 at 07:23 +0200, david at lang.hm wrote:
> I've got a couple projects I'm working on that rsyslog is looking like
> a
> good answer to. I'm going to send questions about them in seperate
> messages.
> 
> the first project is a traditional syslog server. I've been testing
> various syslog implementations to find out what sort of performance
> they
> can sustain.
> 
> I've gotten the (almost) standard sysklogd to sustail almost 30,000
> messages/sec (udp) before it starts loosing significant numbers of
> logs
> 
> rsyslog is able to handle bursts of around 150,000 messages/sec, but
> it
> doesn't seem to write them out very fast, and over time seems to be
> limited to ~22,000 messages/sec
> 
> the hardware I am running this test on is insanely overpowered (four
> dual-core opterons, 16G of ram, battery-backed cache on a raid card
> with
> high-speed SAS drives). in production I will be working with slower
> hardware, but I'm trying to find the limits of the software before I
> start
> introducing lower hardware limits.
> 
> what can I look at doing to speed up the writing of data from the
> queues?
> does rsyslog write the messages one at a time, or does it have an
> option
> for writing them in batches (pulling a bunch off of the queue and
> sending
> them all at once)?

The design is that each individual message is pushed to the output. The
output than writes the message. There has been discussion about a lazy
write, but nothing in this regard has yet been implemented.

Note that this is a good time to request new things. I am finished with
the last major thing (TLS) support and in front of the next one
(enhanced scripting), but scripting, I think, could be moved to a later
time in favour of something more important (like performance ;)).
> 
> some sort of batch mode would be critical for writes to a database
> where
> you can frequently get 1000x speedups if you do the inserts as a
> single
> transaction as opposed to individual transactions.

I am not (any longer) so much a database guy. Can I really do a batch
insert with them? Can you point me to an API?

Looking forward to your reply!
Rainer




From rgerhards at hq.adiscon.com  Mon Sep 15 08:47:13 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 08:47:13 +0200
Subject: [rsyslog] making a custom input module
In-Reply-To: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
Message-ID: <1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>

On Sun, 2008-09-14 at 22:30 -0700, david at lang.hm wrote:
> my second project is to try and modify rsyslog to recieve logs from an 
> application. the application sends the logs over TCP and expects an 
> application-level handshake (very similar to relp). at the moment I want 
> to try and avoid having to change the application (many different products 
> with different release schedules), and instead teach rsyslog to deal with 
> the existing log format.
> 
> at the moment I am trying to understand the imtcp module, but I am getting 
> lost in the callbacks. it looks like rsyslog is calling a routine in 
> imtcp, which calls a routine in tcpsrv, which calls a routine somewhere 
> else to actually recieve the log.

The imtcp module has a lot of history and too complex code. This all
stems back to various stages of GSSAPI integration. Things have been
simplified with the introduction of the transport stream layer, but the
imtcp module does not yet reflect this simplicity. So far, I am hesitant
to split these things, because we still do not have a clean gssapi
netstream driver.

I can tell you where you need to provide callbacks ... or you could
start from imrelp, which in regard means mostly from scratch, but
actually receiving tcp isn't rocket science, so it may be easier to
start with a proper template without tcp functionality and integrate
your tcp reception code into it. What do you (think ;)) you prefer?

> ideally what I would like to use is to take imtcp and replace the message 
> recieving/parsing logic with my own, then have it submit the parsed 
> message into the queue (which looks like it would be via the SubmitMsg() 
> call).
> 
> but at the moment I am lost in the twisty maze of function calls between 
> source files, all of which look different.
> 
> I'm also not clear on what fields inside of the Msg structure need to be 
> populated. looking at Msg.c/h I see a lot of fields there, but it looks 
> like many/most of them are optional.

look at imfile. This is what you need:

	CHKiRet(msgConstruct(&pMsg));
	MsgSetFlowControlType(pMsg, eFLOWCTL_FULL_DELAY);
	MsgSetInputName(pMsg, "imfile");
	MsgSetUxTradMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
	MsgSetRawMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
	MsgSetMSG(pMsg, (char*)rsCStrGetSzStr(cstrLine));
	MsgSetHOSTNAME(pMsg, (char*)glbl.GetLocalHostName());
	MsgSetTAG(pMsg, (char*)pInfo->pszTag);
	pMsg->iFacility = LOG_FAC(pInfo->iFacility);
	pMsg->iSeverity = LOG_PRI(pInfo->iSeverity);
	pMsg->bParseHOSTNAME = 0;
	datetime.getCurrTime(&(pMsg->tTIMESTAMP)); /* use the current time! */
	CHKiRet(submitMsg(pMsg))

Also look at imtemplate, which is a template input module. Sometimes it
is a bit outdated, if you have a problem during compile, tell me ;)

Rainer
> 
> any pointers?
> 
> David Lang
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep 15 08:54:59 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 08:54:59 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
Message-ID: <1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>

This, too, is quite old, to-be-replaced on demand functionality ...
without any demand for replacement up to now ;)

Do you know this guide:
http://www.rsyslog.com/doc-log_rotation_fix_size.html

The shell script could spawn off an async process, but I have never
tried this...

Also <inline>:
On Sun, 2008-09-14 at 23:13 -0700, david at lang.hm wrote:
> looking through the rsyslog.conf man page I see ways to tell rsyslogd to 
> run a command when a file is over a given size, but I see no examples or 
> details of what that command can/should do.
> 
> what I want to do is to move the file out of the way, kick rsyslogd so 
> that it starts writing to a new file, then compress the old file (which 
> can take a significant amount of time)
> 
> traditionally I have rotated syslogs by doing a mv of the logfile followed 
> by a kill -HUP of the syslog process (usually out of crontab)
> 
> In my testing of rsyslog I have been doing this, but once in a while 
> rsyslog doesn't release the file it's writing and start a new one, instead 
> it keeps writing to the old file.

This very much smells like a bug. Can you elaborate on what you did?

> 
> so this means that my command can't spawn a background task that does a mv 
> of the file followed by a kill -HUP of rsyslogd.
> 
> what should I be doing?
> 
> David Lang
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From david at lang.hm  Mon Sep 15 09:01:40 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:01:40 -0700 (PDT)
Subject: [rsyslog] optimization questions
In-Reply-To: <1221460764.2682.9.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>
	<1221460764.2682.9.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150001160.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> Hi David,
>
> thanks for your message and interest. This is very welcome as I would
> really like to get hold of more insight into rsyslog's performance in
> real-world and extreme scenarios. So far, I have unfortunately been
> unable to do that, because I had no funding for the required hardware
> and time to conduct the testing. I would *really* appreciate if you
> could help with that and I would be very willing to tweak the code for
> optimum performance (actually, I am always very concerned about high
> performance and I was a bit sad about the fact that I could not ensure
> it).
>
> Having said that, I'd first of all would like to have a look at your
> rsyslog.conf, so that we are on common ground. Also, I think, this can
> become quite lengthy and also of interest for others. May it be useful
> to discuss this on the web forum, so that we can easier keep track of
> things. If you think this is useful, I recommend this one here:
>
> http://kb.monitorware.com/general-f34.html

done, I created a topic in the developers corner

David Lang

> some more comments inline:
>
> On Mon, 2008-09-15 at 07:23 +0200, david at lang.hm wrote:
>> I've got a couple projects I'm working on that rsyslog is looking like
>> a
>> good answer to. I'm going to send questions about them in seperate
>> messages.
>>
>> the first project is a traditional syslog server. I've been testing
>> various syslog implementations to find out what sort of performance
>> they
>> can sustain.
>>
>> I've gotten the (almost) standard sysklogd to sustail almost 30,000
>> messages/sec (udp) before it starts loosing significant numbers of
>> logs
>>
>> rsyslog is able to handle bursts of around 150,000 messages/sec, but
>> it
>> doesn't seem to write them out very fast, and over time seems to be
>> limited to ~22,000 messages/sec
>>
>> the hardware I am running this test on is insanely overpowered (four
>> dual-core opterons, 16G of ram, battery-backed cache on a raid card
>> with
>> high-speed SAS drives). in production I will be working with slower
>> hardware, but I'm trying to find the limits of the software before I
>> start
>> introducing lower hardware limits.
>>
>> what can I look at doing to speed up the writing of data from the
>> queues?
>> does rsyslog write the messages one at a time, or does it have an
>> option
>> for writing them in batches (pulling a bunch off of the queue and
>> sending
>> them all at once)?
>
> The design is that each individual message is pushed to the output. The
> output than writes the message. There has been discussion about a lazy
> write, but nothing in this regard has yet been implemented.
>
> Note that this is a good time to request new things. I am finished with
> the last major thing (TLS) support and in front of the next one
> (enhanced scripting), but scripting, I think, could be moved to a later
> time in favour of something more important (like performance ;)).
>>
>> some sort of batch mode would be critical for writes to a database
>> where
>> you can frequently get 1000x speedups if you do the inserts as a
>> single
>> transaction as opposed to individual transactions.
>
> I am not (any longer) so much a database guy. Can I really do a batch
> insert with them? Can you point me to an API?
>
> Looking forward to your reply!
> Rainer
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From david at lang.hm  Mon Sep 15 09:10:42 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:10:42 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> This, too, is quite old, to-be-replaced on demand functionality ...
> without any demand for replacement up to now ;)
>
> Do you know this guide:
> http://www.rsyslog.com/doc-log_rotation_fix_size.html
>
> The shell script could spawn off an async process, but I have never
> tried this...
>
> Also <inline>:
> On Sun, 2008-09-14 at 23:13 -0700, david at lang.hm wrote:
>> looking through the rsyslog.conf man page I see ways to tell rsyslogd to
>> run a command when a file is over a given size, but I see no examples or
>> details of what that command can/should do.
>>
>> what I want to do is to move the file out of the way, kick rsyslogd so
>> that it starts writing to a new file, then compress the old file (which
>> can take a significant amount of time)
>>
>> traditionally I have rotated syslogs by doing a mv of the logfile followed
>> by a kill -HUP of the syslog process (usually out of crontab)
>>
>> In my testing of rsyslog I have been doing this, but once in a while
>> rsyslog doesn't release the file it's writing and start a new one, instead
>> it keeps writing to the old file.
>
> This very much smells like a bug. Can you elaborate on what you did?

rsyslogd 3.18.3 on one machine with the config file

$ModLoad immark
$MarkMessagePeriod 1200
$ModLoad imuxsock
$ModLoad imudp
$ModLoad imklog
$UDPServerRun 514
$AllowedSender UDP, 127.0.0.1, 192.0.0.0/8
$umask 0000
$FileGroup root
$FileOwner root
$template TraditionalFormat,"%timegenerated% %HOSTNAME% 
%syslogtag%%msg:::drop-last-lf%\n"
*.*     /var/log/messages;TraditionalFormat      # log to a file in the 
traditional format

tcpreplay on a second machine spewing log entries at it at a rate of 
~30,000 logs/sec

crontab running the following script every 5 min

#!/bin/sh
#

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

umask 022
year=`date +%Y`
month=`date +%m`
day=`date +%d`
fdate=`date +%Y%m%d.%H%M`
logroot=/var/log
logroll=$logroot/oldlogs

cd $logroot
mkdir -p $logroll/$year/$month/$day >/dev/null 2>/dev/null
mv messages $logroll/$year/$month/$day/messages.$fdate
pkill -HUP rsyslogd
2>/dev/null &
gzip -9 $logroll/$year/$month/$day/messages.$fdate


I get a couple of rotations sucessfully (with ~22,000 logs/sec in the 
files), but then rsyslog seems to hang.
lsof show it with the file open that was moved (and later deleted by 
gzip).
I need to do a kill -9 of rsyslogd to get it to recover.

David Lang

>>
>> so this means that my command can't spawn a background task that does a mv
>> of the file followed by a kill -HUP of rsyslogd.
>>
>> what should I be doing?
>>
>> David Lang
>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Mon Sep 15 09:13:16 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:13:16 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
Message-ID: <1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:10 -0700, david at lang.hm wrote:
> > This very much smells like a bug. Can you elaborate on what you did?
> 
> rsyslogd 3.18.3 on one machine with the config file
> 
> $ModLoad immark
> $MarkMessagePeriod 1200
> $ModLoad imuxsock
> $ModLoad imudp
> $ModLoad imklog
> $UDPServerRun 514
> $AllowedSender UDP, 127.0.0.1, 192.0.0.0/8
> $umask 0000
> $FileGroup root
> $FileOwner root
> $template TraditionalFormat,"%timegenerated% %HOSTNAME% 
> %syslogtag%%msg:::drop-last-lf%\n"
> *.*     /var/log/messages;TraditionalFormat      # log to a file in the 
> traditional format
> 
> tcpreplay on a second machine spewing log entries at it at a rate of 
> ~30,000 logs/sec
> 
> crontab running the following script every 5 min
> 
> #!/bin/sh
> #
> 
> PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
> 
> umask 022
> year=`date +%Y`
> month=`date +%m`
> day=`date +%d`
> fdate=`date +%Y%m%d.%H%M`
> logroot=/var/log
> logroll=$logroot/oldlogs
> 
> cd $logroot
> mkdir -p $logroll/$year/$month/$day >/dev/null 2>/dev/null
> mv messages $logroll/$year/$month/$day/messages.$fdate
> pkill -HUP rsyslogd
> 2>/dev/null &
> gzip -9 $logroll/$year/$month/$day/messages.$fdate
> 
> 
> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the 
> files), but then rsyslog seems to hang.
> lsof show it with the file open that was moved (and later deleted by 
> gzip).
> I need to do a kill -9 of rsyslogd to get it to recover.

Definitely a bug... I now "just" need to find out where. I guess there
is some mutex issue in the queue engine during shutdown. Don't expect a
fix too soon, but I'll do my best. I hope I can find a simpler error
condition (if my conclusion on the problem source is right...)

Rainer



From david at lang.hm  Mon Sep 15 09:16:23 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:16:23 -0700 (PDT)
Subject: [rsyslog] making a custom input module
In-Reply-To: <1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
	<1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Sun, 2008-09-14 at 22:30 -0700, david at lang.hm wrote:
>> my second project is to try and modify rsyslog to recieve logs from an
>> application. the application sends the logs over TCP and expects an
>> application-level handshake (very similar to relp). at the moment I want
>> to try and avoid having to change the application (many different products
>> with different release schedules), and instead teach rsyslog to deal with
>> the existing log format.
>>
>> at the moment I am trying to understand the imtcp module, but I am getting
>> lost in the callbacks. it looks like rsyslog is calling a routine in
>> imtcp, which calls a routine in tcpsrv, which calls a routine somewhere
>> else to actually recieve the log.
>
> The imtcp module has a lot of history and too complex code. This all
> stems back to various stages of GSSAPI integration. Things have been
> simplified with the introduction of the transport stream layer, but the
> imtcp module does not yet reflect this simplicity. So far, I am hesitant
> to split these things, because we still do not have a clean gssapi
> netstream driver.
>
> I can tell you where you need to provide callbacks ... or you could
> start from imrelp, which in regard means mostly from scratch, but
> actually receiving tcp isn't rocket science, so it may be easier to
> start with a proper template without tcp functionality and integrate
> your tcp reception code into it. What do you (think ;)) you prefer?

the simpler the better. I'm pretty rusty with my C and I never did much 
network or threaded programming in the first place, so while I can debug 
programs in any language, I'm currently not much beyond the cut-n-past 
stage here.

it sounds like I should not start from imtcp.

however when I looked at imrelp it looked like everything in in the relp 
libraries, and I was hoping to avoid diving into them for the moment.

are any of the other tcp-based transports in better shape? or should I 
start from scratch with the imtemplate plugin?

David Lang

>> ideally what I would like to use is to take imtcp and replace the message
>> recieving/parsing logic with my own, then have it submit the parsed
>> message into the queue (which looks like it would be via the SubmitMsg()
>> call).
>>
>> but at the moment I am lost in the twisty maze of function calls between
>> source files, all of which look different.
>>
>> I'm also not clear on what fields inside of the Msg structure need to be
>> populated. looking at Msg.c/h I see a lot of fields there, but it looks
>> like many/most of them are optional.
>
> look at imfile. This is what you need:
>
> 	CHKiRet(msgConstruct(&pMsg));
> 	MsgSetFlowControlType(pMsg, eFLOWCTL_FULL_DELAY);
> 	MsgSetInputName(pMsg, "imfile");
> 	MsgSetUxTradMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
> 	MsgSetRawMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
> 	MsgSetMSG(pMsg, (char*)rsCStrGetSzStr(cstrLine));
> 	MsgSetHOSTNAME(pMsg, (char*)glbl.GetLocalHostName());
> 	MsgSetTAG(pMsg, (char*)pInfo->pszTag);
> 	pMsg->iFacility = LOG_FAC(pInfo->iFacility);
> 	pMsg->iSeverity = LOG_PRI(pInfo->iSeverity);
> 	pMsg->bParseHOSTNAME = 0;
> 	datetime.getCurrTime(&(pMsg->tTIMESTAMP)); /* use the current time! */
> 	CHKiRet(submitMsg(pMsg))
>
> Also look at imtemplate, which is a template input module. Sometimes it
> is a bit outdated, if you have a problem during compile, tell me ;)
>
> Rainer
>>
>> any pointers?
>>
>> David Lang
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From david at lang.hm  Mon Sep 15 09:17:47 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:17:47 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

>> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the
>> files), but then rsyslog seems to hang.
>> lsof show it with the file open that was moved (and later deleted by
>> gzip).
>> I need to do a kill -9 of rsyslogd to get it to recover.
>
> Definitely a bug... I now "just" need to find out where. I guess there
> is some mutex issue in the queue engine during shutdown. Don't expect a
> fix too soon, but I'll do my best. I hope I can find a simpler error
> condition (if my conclusion on the problem source is right...)

let me know if you need me to try anything. given the volume of logs I 
don't know if it would be worth trying to do a strace.

David Lang


From rgerhards at hq.adiscon.com  Mon Sep 15 09:19:43 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:19:43 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
Message-ID: <1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:17 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> >> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the
> >> files), but then rsyslog seems to hang.
> >> lsof show it with the file open that was moved (and later deleted by
> >> gzip).
> >> I need to do a kill -9 of rsyslogd to get it to recover.
> >
> > Definitely a bug... I now "just" need to find out where. I guess there
> > is some mutex issue in the queue engine during shutdown. Don't expect a
> > fix too soon, but I'll do my best. I hope I can find a simpler error
> > condition (if my conclusion on the problem source is right...)
> 
> let me know if you need me to try anything. given the volume of logs I 
> don't know if it would be worth trying to do a strace.

I agree, it doesn't make any sense. It may be worth trying to run
rsyslog with runtime instrumentation turned on in debug mode. That will
generate tons of debug output and it will make things awfully slow, but
at least we may be able to get some information out of it.

... well... one thing: could you run an unmodified version of WinSyslog
under valgrind and let me know if there are any valgrind exceptions
before it hangs? This, too, will make it very slow, but I guess/hope
that doesn't affect the outcome.

Rainer



From rgerhards at hq.adiscon.com  Mon Sep 15 09:20:57 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:20:57 +0200
Subject: [rsyslog] making a custom input module
In-Reply-To: <alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
	<1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>
Message-ID: <1221463257.2682.34.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:16 -0700, david at lang.hm wrote:
> the simpler the better. I'm pretty rusty with my C and I never did much 
> network or threaded programming in the first place, so while I can debug 
> programs in any language, I'm currently not much beyond the cut-n-past 
> stage here.
> 
> it sounds like I should not start from imtcp.
> 
> however when I looked at imrelp it looked like everything in in the relp 
> libraries, and I was hoping to avoid diving into them for the moment.
> 
> are any of the other tcp-based transports in better shape? or should I 
> start from scratch with the imtemplate plugin?

Bear a bit with me (but ping me if I don't reply by mid-week). I'll have
a look and recommend the way I think is best given the constraints.

Rainer



From david at lang.hm  Mon Sep 15 09:26:57 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:26:57 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:17 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>
>>>> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the
>>>> files), but then rsyslog seems to hang.
>>>> lsof show it with the file open that was moved (and later deleted by
>>>> gzip).
>>>> I need to do a kill -9 of rsyslogd to get it to recover.
>>>
>>> Definitely a bug... I now "just" need to find out where. I guess there
>>> is some mutex issue in the queue engine during shutdown. Don't expect a
>>> fix too soon, but I'll do my best. I hope I can find a simpler error
>>> condition (if my conclusion on the problem source is right...)
>>
>> let me know if you need me to try anything. given the volume of logs I
>> don't know if it would be worth trying to do a strace.
>
> I agree, it doesn't make any sense. It may be worth trying to run
> rsyslog with runtime instrumentation turned on in debug mode. That will
> generate tons of debug output and it will make things awfully slow, but
> at least we may be able to get some information out of it.

do I need to recompile it, or is it a config/command line option?

> ... well... one thing: could you run an unmodified version of WinSyslog
> under valgrind and let me know if there are any valgrind exceptions
> before it hangs? This, too, will make it very slow, but I guess/hope
> that doesn't affect the outcome.

I'm running on linux machines, so I don't know if WinSyslog can be made to 
work. I would need to be pointed at the source.

David Lang


From david at lang.hm  Mon Sep 15 09:27:47 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:27:47 -0700 (PDT)
Subject: [rsyslog] making a custom input module
In-Reply-To: <1221463257.2682.34.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
	<1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>
	<1221463257.2682.34.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150027110.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:16 -0700, david at lang.hm wrote:
>> the simpler the better. I'm pretty rusty with my C and I never did much
>> network or threaded programming in the first place, so while I can debug
>> programs in any language, I'm currently not much beyond the cut-n-past
>> stage here.
>>
>> it sounds like I should not start from imtcp.
>>
>> however when I looked at imrelp it looked like everything in in the relp
>> libraries, and I was hoping to avoid diving into them for the moment.
>>
>> are any of the other tcp-based transports in better shape? or should I
>> start from scratch with the imtemplate plugin?
>
> Bear a bit with me (but ping me if I don't reply by mid-week). I'll have
> a look and recommend the way I think is best given the constraints.

Ok, in the meantime I'll forget about trying to untangle imtcp and see 
what I can do seperatly.

David Lang


From rgerhards at hq.adiscon.com  Mon Sep 15 09:28:04 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:28:04 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
Message-ID: <1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:26 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> > I agree, it doesn't make any sense. It may be worth trying to run
> > rsyslog with runtime instrumentation turned on in debug mode. That will
> > generate tons of debug output and it will make things awfully slow, but
> > at least we may be able to get some information out of it.
> 
> do I need to recompile it, or is it a config/command line option?

you need to compile it, but let's do the valgrind test first (less
effort required).
> 
> > ... well... one thing: could you run an unmodified version of WinSyslog
> > under valgrind and let me know if there are any valgrind exceptions
> > before it hangs? This, too, will make it very slow, but I guess/hope
> > that doesn't affect the outcome.
> 
> I'm running on linux machines, so I don't know if WinSyslog can be made to 
> work. I would need to be pointed at the source.

lol - that happens if you have two conversations open at one time ;) Actually, I meant rsyslog. Forget about the WinSyslog part ;)

Rainer



From david at lang.hm  Mon Sep 15 09:34:17 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:34:17 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:26 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>
>>> I agree, it doesn't make any sense. It may be worth trying to run
>>> rsyslog with runtime instrumentation turned on in debug mode. That will
>>> generate tons of debug output and it will make things awfully slow, but
>>> at least we may be able to get some information out of it.
>>
>> do I need to recompile it, or is it a config/command line option?
>
> you need to compile it, but let's do the valgrind test first (less
> effort required).
>>
>>> ... well... one thing: could you run an unmodified version of WinSyslog
>>> under valgrind and let me know if there are any valgrind exceptions
>>> before it hangs? This, too, will make it very slow, but I guess/hope
>>> that doesn't affect the outcome.
>>
>> I'm running on linux machines, so I don't know if WinSyslog can be made to
>> work. I would need to be pointed at the source.
>
> lol - that happens if you have two conversations open at one time ;) Actually, I meant rsyslog. Forget about the WinSyslog part ;)

ok, I've never run vagrind, let me see what I can find.

David Lang


From rgerhards at hq.adiscon.com  Mon Sep 15 09:37:20 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:37:20 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
Message-ID: <1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:34 -0700, david at lang.hm wrote:
> ok, I've never run vagrind, let me see what I can find.

It's far easier than I thought when I used valgrind for the first time:
simply install a recent release and start rsyslog as usual, just add
"valgrind" before rsyslog (so valgrind is the command and rsyslog an
arguement". e.g.

$ ./rsyslogd -c3

becomes

$ valgrind ./rsyslogd -c3

That's it! :-)

There are a couple of options for valgrind, but for starters the defaults are fine.

Rainer



From david at lang.hm  Mon Sep 15 09:53:41 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:53:41 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> Date: Mon, 15 Sep 2008 09:37:20 +0200
> From: Rainer Gerhards <rgerhards at hq.adiscon.com>
> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
> To: rsyslog-users <rsyslog at lists.adiscon.com>
> Subject: Re: [rsyslog] how to best rotate files
> 
> On Mon, 2008-09-15 at 00:34 -0700, david at lang.hm wrote:
>> ok, I've never run vagrind, let me see what I can find.
>
> It's far easier than I thought when I used valgrind for the first time:
> simply install a recent release and start rsyslog as usual, just add
> "valgrind" before rsyslog (so valgrind is the command and rsyslog an
> arguement". e.g.
>
> $ ./rsyslogd -c3
>
> becomes
>
> $ valgrind ./rsyslogd -c3
>
> That's it! :-)
>
> There are a couple of options for valgrind, but for starters the defaults are fine.

I did --trace-children=yes (otherwise it wouldn't stay attached) and 
--leak-detail=yes (since it seemed to report memory leaks in the first 
run)

this seemed to run into problems with the first rotation (which given that 
there was no process to do a kill -HUP on, isn't surprising)

David Lang

==10726== Memcheck, a memory error detector.
==10726== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==10726== Using LibVEX rev 1658, a library for dynamic binary translation.
==10726== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==10726== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.
==10726== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==10726== For more details, rerun with: -v
==10726==
==10726== My PID = 10726, parent PID = 13696.  Prog and args are:
==10726==    /usr/local/sbin/rsyslogd
==10726==    -c3
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x40091D5: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x40091DE: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010B04: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010C61: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006E47: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Invalid read of size 8
==10726==    at 0x4010C54: (within /lib/ld-2.3.6.so)
==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10726==    by 0x4007113: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010A70: (within /lib/ld-2.3.6.so)
==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006117: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10726==    by 0x4008B91: (within /lib/ld-2.3.6.so)
==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Invalid read of size 8
==10726==    at 0x4010C20: (within /lib/ld-2.3.6.so)
==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10726==    by 0x4006123: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
==10726== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
==10726== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
==10726== For counts of detected errors, rerun with: -v
==10726== searching for pointers to 437 not-freed blocks.
==10726== checked 172,368 bytes.
==10726==
==10726== LEAK SUMMARY:
==10726==    definitely lost: 0 bytes in 0 blocks.
==10726==      possibly lost: 0 bytes in 0 blocks.
==10726==    still reachable: 24,090 bytes in 437 blocks.
==10726==         suppressed: 0 bytes in 0 blocks.
==10726== Reachable blocks (those to which a pointer was found) are not 
shown.
==10726== To see them, rerun with: --show-reachable=yes




==10730== Memcheck, a memory error detector.
==10730== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==10730== Using LibVEX rev 1658, a library for dynamic binary translation.
==10730== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==10730== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.
==10730== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==10730== For more details, rerun with: -v
==10730==
==10730== My PID = 10730, parent PID = 13696.  Prog and args are:
==10730==    /usr/local/sbin/rsyslogd
==10730==    -c3
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x40091D5: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x40091DE: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010B04: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010C61: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006E47: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Invalid read of size 8
==10730==    at 0x4010C54: (within /lib/ld-2.3.6.so)
==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10730==    by 0x4007113: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010A70: (within /lib/ld-2.3.6.so)
==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006117: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10730==    by 0x4008B91: (within /lib/ld-2.3.6.so)
==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Invalid read of size 8
==10730==    at 0x4010C20: (within /lib/ld-2.3.6.so)
==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10730==    by 0x4006123: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10731== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
hints
==10731==    This could cause spurious value errors to appear.
==10731==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
proper wrapper.
==10731==
==10731== Conditional jump or move depends on uninitialised value(s)
==10731==    at 0x4009442: (within /lib/ld-2.3.6.so)
==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==
==10731== Conditional jump or move depends on uninitialised value(s)
==10731==    at 0x4009339: (within /lib/ld-2.3.6.so)
==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==
==10731== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)
==10731==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
==10731==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
==10731==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
==10731==    by 0x4145F1: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
==10731==    by 0x5295B57: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)
==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
==10731==  Address 0x7FEFFB401 is on thread 1's stack
==10730==
==10730== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
==10730== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
==10730== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
==10730== For counts of detected errors, rerun with: -v
==10730== searching for pointers to 437 not-freed blocks.
==10730== checked 173,712 bytes.
==10730==
==10730== LEAK SUMMARY:
==10730==    definitely lost: 0 bytes in 0 blocks.
==10730==      possibly lost: 0 bytes in 0 blocks.
==10730==    still reachable: 24,090 bytes in 437 blocks.
==10730==         suppressed: 0 bytes in 0 blocks.
==10730== Reachable blocks (those to which a pointer was found) are not 
shown.
==10730== To see them, rerun with: --show-reachable=yes
==10731==
==10731== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from 
1)
==10731== malloc/free: in use at exit: 13,231 bytes in 85 blocks.
==10731== malloc/free: 3,058,176 allocs, 3,058,091 frees, 619,413,167 
bytes allocated.
==10731== For counts of detected errors, rerun with: -v
==10731== searching for pointers to 85 not-freed blocks.
==10731== checked 33,675,000 bytes.
==10731==
==10731==
==10731== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely 
lost in loss record 9 of 25
==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
==10731==    by 0x5295A31: ???
==10731==    by 0x5295C3C: ???
==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
==10731==
==10731==
==10731== 584 (104 direct, 480 indirect) bytes in 2 blocks are definitely 
lost in loss record 13 of 25
==10731==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10731==    by 0x502F63F: (within /lib/libc-2.3.6.so)
==10731==    by 0x502FD95: __nss_database_lookup (in /lib/libc-2.3.6.so)
==10731==    by 0x59B373F: ???
==10731==    by 0x59B4532: ???
==10731==    by 0x4FE5BF4: getgrnam_r (in /lib/libc-2.3.6.so)
==10731==    by 0x4272C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
==10731==
==10731==
==10731== 544 bytes in 4 blocks are possibly lost in loss record 20 of 25
==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
==10731==    by 0x400EA3D: _dl_allocate_tls (in /lib/ld-2.3.6.so)
==10731==    by 0x4C3B500: pthread_create@@GLIBC_2.2.5 (in 
/lib/libpthread-2.3.6.so)
==10731==    by 0x41690E: wtpAdviseMaxWorkers (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x41A4EF: queueStart (in /usr/local/sbin/rsyslogd)
==10731==    by 0x40B5BC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
==10731==
==10731==
==10731== 1,420 (928 direct, 492 indirect) bytes in 2 blocks are 
definitely lost in loss record 23 of 25
==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
==10731==    by 0x41F13F: msgConstruct (in /usr/local/sbin/rsyslogd)
==10731==    by 0x40ABA9: logmsgInternal (in /usr/local/sbin/rsyslogd)
==10731==    by 0x40BEC9: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40C07A: realMain (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
==10731==
==10731== LEAK SUMMARY:
==10731==    definitely lost: 1,064 bytes in 5 blocks.
==10731==    indirectly lost: 1,036 bytes in 34 blocks.
==10731==      possibly lost: 544 bytes in 4 blocks.
==10731==    still reachable: 10,587 bytes in 42 blocks.
==10731==         suppressed: 0 bytes in 0 blocks.
==10731== Reachable blocks (those to which a pointer was found) are not 
shown.
==10731== To see them, rerun with: --show-reachable=yes



From rgerhards at hq.adiscon.com  Mon Sep 15 10:23:51 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 10:23:51 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
Message-ID: <1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:53 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> I did --trace-children=yes (otherwise it wouldn't stay attached) and 
> --leak-detail=yes (since it seemed to report memory leaks in the first 
> run)

Well, I am actually not so much interested in what the forked processes
do. They have "memory leaks", but these "leaks" stem from process
duplication and are cleaned up by the OS when the forked process
terminates. Cleaning them up oneself creates unnecessary CPU, as the OS
does it much more efficient. Also, the hang is related to the parent
process. Thus, I'd actually pefer --trace-children=no ;)

I also notice that it would be of advantage to do a compile with

./configure --enable-debug --enable-valgrind

as this leads to better debug trace information. But the parent trace is most interesting first (if there is anything reported from valgrind).

Rainer

> 
> this seemed to run into problems with the first rotation (which given that 
> there was no process to do a kill -HUP on, isn't surprising)
> 
> David Lang
> 
> ==10726== Memcheck, a memory error detector.
> ==10726== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> ==10726== Using LibVEX rev 1658, a library for dynamic binary translation.
> ==10726== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> ==10726== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
> framework.
> ==10726== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> ==10726== For more details, rerun with: -v
> ==10726==
> ==10726== My PID = 10726, parent PID = 13696.  Prog and args are:
> ==10726==    /usr/local/sbin/rsyslogd
> ==10726==    -c3
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x40091D5: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x40091DE: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010B04: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010C61: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006E47: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Invalid read of size 8
> ==10726==    at 0x4010C54: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10726==    by 0x4007113: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010A70: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006117: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4008B91: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Invalid read of size 8
> ==10726==    at 0x4010C20: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10726==    by 0x4006123: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
> ==10726== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
> ==10726== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
> ==10726== For counts of detected errors, rerun with: -v
> ==10726== searching for pointers to 437 not-freed blocks.
> ==10726== checked 172,368 bytes.
> ==10726==
> ==10726== LEAK SUMMARY:
> ==10726==    definitely lost: 0 bytes in 0 blocks.
> ==10726==      possibly lost: 0 bytes in 0 blocks.
> ==10726==    still reachable: 24,090 bytes in 437 blocks.
> ==10726==         suppressed: 0 bytes in 0 blocks.
> ==10726== Reachable blocks (those to which a pointer was found) are not 
> shown.
> ==10726== To see them, rerun with: --show-reachable=yes
> 
> 
> 
> 
> ==10730== Memcheck, a memory error detector.
> ==10730== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> ==10730== Using LibVEX rev 1658, a library for dynamic binary translation.
> ==10730== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> ==10730== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
> framework.
> ==10730== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> ==10730== For more details, rerun with: -v
> ==10730==
> ==10730== My PID = 10730, parent PID = 13696.  Prog and args are:
> ==10730==    /usr/local/sbin/rsyslogd
> ==10730==    -c3
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x40091D5: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x40091DE: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010B04: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010C61: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006E47: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Invalid read of size 8
> ==10730==    at 0x4010C54: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10730==    by 0x4007113: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010A70: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006117: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4008B91: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Invalid read of size 8
> ==10730==    at 0x4010C20: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10730==    by 0x4006123: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10731== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
> hints
> ==10731==    This could cause spurious value errors to appear.
> ==10731==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
> proper wrapper.
> ==10731==
> ==10731== Conditional jump or move depends on uninitialised value(s)
> ==10731==    at 0x4009442: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==
> ==10731== Conditional jump or move depends on uninitialised value(s)
> ==10731==    at 0x4009339: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==
> ==10731== Syscall param socketcall.sendto(msg) points to uninitialised 
> byte(s)
> ==10731==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
> ==10731==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4145F1: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x5295B57: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==  Address 0x7FEFFB401 is on thread 1's stack
> ==10730==
> ==10730== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
> ==10730== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
> ==10730== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
> ==10730== For counts of detected errors, rerun with: -v
> ==10730== searching for pointers to 437 not-freed blocks.
> ==10730== checked 173,712 bytes.
> ==10730==
> ==10730== LEAK SUMMARY:
> ==10730==    definitely lost: 0 bytes in 0 blocks.
> ==10730==      possibly lost: 0 bytes in 0 blocks.
> ==10730==    still reachable: 24,090 bytes in 437 blocks.
> ==10730==         suppressed: 0 bytes in 0 blocks.
> ==10730== Reachable blocks (those to which a pointer was found) are not 
> shown.
> ==10730== To see them, rerun with: --show-reachable=yes
> ==10731==
> ==10731== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from 
> 1)
> ==10731== malloc/free: in use at exit: 13,231 bytes in 85 blocks.
> ==10731== malloc/free: 3,058,176 allocs, 3,058,091 frees, 619,413,167 
> bytes allocated.
> ==10731== For counts of detected errors, rerun with: -v
> ==10731== searching for pointers to 85 not-freed blocks.
> ==10731== checked 33,675,000 bytes.
> ==10731==
> ==10731==
> ==10731== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely 
> lost in loss record 9 of 25
> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> ==10731==    by 0x5295A31: ???
> ==10731==    by 0x5295C3C: ???
> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> ==10731==
> ==10731==
> ==10731== 584 (104 direct, 480 indirect) bytes in 2 blocks are definitely 
> lost in loss record 13 of 25
> ==10731==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10731==    by 0x502F63F: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x502FD95: __nss_database_lookup (in /lib/libc-2.3.6.so)
> ==10731==    by 0x59B373F: ???
> ==10731==    by 0x59B4532: ???
> ==10731==    by 0x4FE5BF4: getgrnam_r (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4272C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
> ==10731==
> ==10731==
> ==10731== 544 bytes in 4 blocks are possibly lost in loss record 20 of 25
> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> ==10731==    by 0x400EA3D: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==10731==    by 0x4C3B500: pthread_create@@GLIBC_2.2.5 (in 
> /lib/libpthread-2.3.6.so)
> ==10731==    by 0x41690E: wtpAdviseMaxWorkers (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x41A4EF: queueStart (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B5BC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> ==10731==
> ==10731==
> ==10731== 1,420 (928 direct, 492 indirect) bytes in 2 blocks are 
> definitely lost in loss record 23 of 25
> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> ==10731==    by 0x41F13F: msgConstruct (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40ABA9: logmsgInternal (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40BEC9: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40C07A: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> ==10731==
> ==10731== LEAK SUMMARY:
> ==10731==    definitely lost: 1,064 bytes in 5 blocks.
> ==10731==    indirectly lost: 1,036 bytes in 34 blocks.
> ==10731==      possibly lost: 544 bytes in 4 blocks.
> ==10731==    still reachable: 10,587 bytes in 42 blocks.
> ==10731==         suppressed: 0 bytes in 0 blocks.
> ==10731== Reachable blocks (those to which a pointer was found) are not 
> shown.
> ==10731== To see them, rerun with: --show-reachable=yes
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From david at lang.hm  Mon Sep 15 10:31:47 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 01:31:47 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:53 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>> I did --trace-children=yes (otherwise it wouldn't stay attached) and
>> --leak-detail=yes (since it seemed to report memory leaks in the first
>> run)
>
> Well, I am actually not so much interested in what the forked processes
> do. They have "memory leaks", but these "leaks" stem from process
> duplication and are cleaned up by the OS when the forked process
> terminates. Cleaning them up oneself creates unnecessary CPU, as the OS
> does it much more efficient. Also, the hang is related to the parent
> process. Thus, I'd actually pefer --trace-children=no ;)
>
> I also notice that it would be of advantage to do a compile with
>
> ./configure --enable-debug --enable-valgrind
>
> as this leads to better debug trace information. But the parent trace is most interesting first (if there is anything reported from valgrind).

Ok, I will do this in the morning.

one other item that occured to me, should I even be doing the kill -HUP? 
or does rsyslog open the file for writing each time (so that I just have 
to mv the file away and it will create a new one)?

David Lang

> Rainer
>
>>
>> this seemed to run into problems with the first rotation (which given that
>> there was no process to do a kill -HUP on, isn't surprising)
>>
>> David Lang
>>
>> ==10726== Memcheck, a memory error detector.
>> ==10726== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10726== Using LibVEX rev 1658, a library for dynamic binary translation.
>> ==10726== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
>> ==10726== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
>> framework.
>> ==10726== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10726== For more details, rerun with: -v
>> ==10726==
>> ==10726== My PID = 10726, parent PID = 13696.  Prog and args are:
>> ==10726==    /usr/local/sbin/rsyslogd
>> ==10726==    -c3
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x40091D5: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x40091DE: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010B04: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010C61: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006E47: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Invalid read of size 8
>> ==10726==    at 0x4010C54: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
>> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10726==    by 0x4007113: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010A70: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006117: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4008B91: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Invalid read of size 8
>> ==10726==    at 0x4010C20: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
>> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10726==    by 0x4006123: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
>> ==10726== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
>> ==10726== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
>> ==10726== For counts of detected errors, rerun with: -v
>> ==10726== searching for pointers to 437 not-freed blocks.
>> ==10726== checked 172,368 bytes.
>> ==10726==
>> ==10726== LEAK SUMMARY:
>> ==10726==    definitely lost: 0 bytes in 0 blocks.
>> ==10726==      possibly lost: 0 bytes in 0 blocks.
>> ==10726==    still reachable: 24,090 bytes in 437 blocks.
>> ==10726==         suppressed: 0 bytes in 0 blocks.
>> ==10726== Reachable blocks (those to which a pointer was found) are not
>> shown.
>> ==10726== To see them, rerun with: --show-reachable=yes
>>
>>
>>
>>
>> ==10730== Memcheck, a memory error detector.
>> ==10730== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10730== Using LibVEX rev 1658, a library for dynamic binary translation.
>> ==10730== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
>> ==10730== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
>> framework.
>> ==10730== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10730== For more details, rerun with: -v
>> ==10730==
>> ==10730== My PID = 10730, parent PID = 13696.  Prog and args are:
>> ==10730==    /usr/local/sbin/rsyslogd
>> ==10730==    -c3
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x40091D5: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x40091DE: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010B04: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010C61: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006E47: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Invalid read of size 8
>> ==10730==    at 0x4010C54: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
>> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10730==    by 0x4007113: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010A70: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006117: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4008B91: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Invalid read of size 8
>> ==10730==    at 0x4010C20: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
>> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10730==    by 0x4006123: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10731== Warning: noted but unhandled ioctl 0x5422 with no size/direction
>> hints
>> ==10731==    This could cause spurious value errors to appear.
>> ==10731==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
>> proper wrapper.
>> ==10731==
>> ==10731== Conditional jump or move depends on uninitialised value(s)
>> ==10731==    at 0x4009442: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==
>> ==10731== Conditional jump or move depends on uninitialised value(s)
>> ==10731==    at 0x4009339: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==
>> ==10731== Syscall param socketcall.sendto(msg) points to uninitialised
>> byte(s)
>> ==10731==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4145F1: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x5295B57: addAllowedSenderLine (in
>> /usr/local/lib/rsyslog/lmnet.so)
>> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==  Address 0x7FEFFB401 is on thread 1's stack
>> ==10730==
>> ==10730== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
>> ==10730== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
>> ==10730== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
>> ==10730== For counts of detected errors, rerun with: -v
>> ==10730== searching for pointers to 437 not-freed blocks.
>> ==10730== checked 173,712 bytes.
>> ==10730==
>> ==10730== LEAK SUMMARY:
>> ==10730==    definitely lost: 0 bytes in 0 blocks.
>> ==10730==      possibly lost: 0 bytes in 0 blocks.
>> ==10730==    still reachable: 24,090 bytes in 437 blocks.
>> ==10730==         suppressed: 0 bytes in 0 blocks.
>> ==10730== Reachable blocks (those to which a pointer was found) are not
>> shown.
>> ==10730== To see them, rerun with: --show-reachable=yes
>> ==10731==
>> ==10731== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from
>> 1)
>> ==10731== malloc/free: in use at exit: 13,231 bytes in 85 blocks.
>> ==10731== malloc/free: 3,058,176 allocs, 3,058,091 frees, 619,413,167
>> bytes allocated.
>> ==10731== For counts of detected errors, rerun with: -v
>> ==10731== searching for pointers to 85 not-freed blocks.
>> ==10731== checked 33,675,000 bytes.
>> ==10731==
>> ==10731==
>> ==10731== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely
>> lost in loss record 9 of 25
>> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
>> ==10731==    by 0x5295A31: ???
>> ==10731==    by 0x5295C3C: ???
>> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
>> ==10731==
>> ==10731==
>> ==10731== 584 (104 direct, 480 indirect) bytes in 2 blocks are definitely
>> lost in loss record 13 of 25
>> ==10731==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10731==    by 0x502F63F: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x502FD95: __nss_database_lookup (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x59B373F: ???
>> ==10731==    by 0x59B4532: ???
>> ==10731==    by 0x4FE5BF4: getgrnam_r (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4272C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
>> ==10731==
>> ==10731==
>> ==10731== 544 bytes in 4 blocks are possibly lost in loss record 20 of 25
>> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
>> ==10731==    by 0x400EA3D: _dl_allocate_tls (in /lib/ld-2.3.6.so)
>> ==10731==    by 0x4C3B500: pthread_create@@GLIBC_2.2.5 (in
>> /lib/libpthread-2.3.6.so)
>> ==10731==    by 0x41690E: wtpAdviseMaxWorkers (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x41A4EF: queueStart (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B5BC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
>> ==10731==
>> ==10731==
>> ==10731== 1,420 (928 direct, 492 indirect) bytes in 2 blocks are
>> definitely lost in loss record 23 of 25
>> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
>> ==10731==    by 0x41F13F: msgConstruct (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40ABA9: logmsgInternal (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40BEC9: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40C07A: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
>> ==10731==
>> ==10731== LEAK SUMMARY:
>> ==10731==    definitely lost: 1,064 bytes in 5 blocks.
>> ==10731==    indirectly lost: 1,036 bytes in 34 blocks.
>> ==10731==      possibly lost: 544 bytes in 4 blocks.
>> ==10731==    still reachable: 10,587 bytes in 42 blocks.
>> ==10731==         suppressed: 0 bytes in 0 blocks.
>> ==10731== Reachable blocks (those to which a pointer was found) are not
>> shown.
>> ==10731== To see them, rerun with: --show-reachable=yes
>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Mon Sep 15 10:57:26 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 10:57:26 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
Message-ID: <1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> one other item that occured to me, should I even be doing the kill -HUP? 
> or does rsyslog open the file for writing each time (so that I just have 
> to mv the file away and it will create a new one)?

no, you need the HUP. Otherwise the file is kept open (so this is no
easy way to improve performance ;))

Rainer



From david at lang.hm  Mon Sep 15 11:07:22 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 02:07:22 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>
>> one other item that occured to me, should I even be doing the kill -HUP?
>> or does rsyslog open the file for writing each time (so that I just have
>> to mv the file away and it will create a new one)?
>
> no, you need the HUP. Otherwise the file is kept open (so this is no
> easy way to improve performance ;))

here is a run with the debug and valgrind options

==11835== Memcheck, a memory error detector.

==11835== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.

==11835== Using LibVEX rev 1658, a library for dynamic binary translation.

==11835== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.

==11835== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.

==11835== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.

==11835== For more details, rerun with: -v

==11835==

==11835== My PID = 11835, parent PID = 11702.  Prog and args are:

==11835==    /usr/local/sbin/rsyslogd

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x40091D5: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==11835==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x40091DE: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==11835==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010AEE: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010AF9: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010B04: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010C61: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006E47: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Invalid read of size 8

==11835==    at 0x4010C54: (within /lib/ld-2.3.6.so)

==11835==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==11835==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==  Address 0x5198EB0 is 16 bytes inside a block of size 23 alloc'd

==11835==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==11835==    by 0x4007113: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010A70: (within /lib/ld-2.3.6.so)

==11835==    by 0x400610A: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010A7F: (within /lib/ld-2.3.6.so)

==11835==    by 0x400610A: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010A8E: (within /lib/ld-2.3.6.so)

==11835==    by 0x400610A: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006117: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==11835==    by 0x4008B91: (within /lib/ld-2.3.6.so)

==11835==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Invalid read of size 8

==11835==    at 0x4010C20: (within /lib/ld-2.3.6.so)

==11835==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==11835==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==  Address 0x519B1C0 is 32 bytes inside a block of size 35 alloc'd

==11835==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==11835==    by 0x4006123: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11836== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
hints

==11836==    This could cause spurious value errors to appear.

==11836==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
proper wrapper.

==11836==

==11836== Conditional jump or move depends on uninitialised value(s)

==11836==    at 0x4009442: (within /lib/ld-2.3.6.so)

==11836==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11836==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11836==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11836==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==11836==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==11836==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==11836==

==11836== Conditional jump or move depends on uninitialised value(s)

==11836==    at 0x4009339: (within /lib/ld-2.3.6.so)

==11836==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11836==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11836==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11836==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==11836==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==11836==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==11836==

==11836== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)

==11836==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)

==11836==    by 0x503E8C9: (within /lib/libc-2.3.6.so)

==11836==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)

==11836==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)

==11836==    by 0x5295D97: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==11836==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==11836==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==11836==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==11836==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x40D3D1: realMain (in /usr/local/sbin/rsyslogd)
==11836==  Address 0x7FEFFB371 is on thread 1's stack

==11835==

==11835== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)

==11835== malloc/free: in use at exit: 25,332 bytes in 459 blocks.

==11835== malloc/free: 606 allocs, 147 frees, 36,928 bytes allocated.

==11835== For counts of detected errors, rerun with: -v

==11835== searching for pointers to 459 not-freed blocks.

==11835== checked 175,080 bytes.

==11835==

==11835== LEAK SUMMARY:

==11835==    definitely lost: 0 bytes in 0 blocks.

==11835==      possibly lost: 0 bytes in 0 blocks.

==11835==    still reachable: 25,332 bytes in 459 blocks.

==11835==         suppressed: 0 bytes in 0 blocks.

==11835== Reachable blocks (those to which a pointer was found) are not 
shown.

==11835== To see them, rerun with: --show-reachable=yes

==11836==

==11836== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from 
1)

==11836== malloc/free: in use at exit: 20,815 bytes in 114 blocks.

==11836== malloc/free: 1,738 allocs, 1,624 frees, 255,036 bytes allocated.

==11836== For counts of detected errors, rerun with: -v

==11836== searching for pointers to 114 not-freed blocks.

==11836== checked 33,711,344 bytes.

==11836==

==11836== LEAK SUMMARY:

==11836==    definitely lost: 2,020 bytes in 35 blocks.

==11836==      possibly lost: 544 bytes in 4 blocks.

==11836==    still reachable: 18,251 bytes in 75 blocks.

==11836==         suppressed: 0 bytes in 0 blocks.

==11836== Use --leak-check=full to see details of leaked memory.




From rgerhards at hq.adiscon.com  Mon Sep 15 11:28:19 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 11:28:19 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
Message-ID: <1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 02:07 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> > On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
> >> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> >
> >> one other item that occured to me, should I even be doing the kill -HUP?
> >> or does rsyslog open the file for writing each time (so that I just have
> >> to mv the file away and it will create a new one)?
> >
> > no, you need the HUP. Otherwise the file is kept open (so this is no
> > easy way to improve performance ;))
> 
> here is a run with the debug and valgrind options

mmhhh... it still is missing lots of information. Did "make install"
install to incorrect locations? This happens quite often, especially on
x64 systems (I've fallen myself more than once into this trap).

Rainer



From david at lang.hm  Mon Sep 15 11:51:30 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 02:51:30 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 02:07 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>
>>> On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
>>>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>>
>>>> one other item that occured to me, should I even be doing the kill -HUP?
>>>> or does rsyslog open the file for writing each time (so that I just have
>>>> to mv the file away and it will create a new one)?
>>>
>>> no, you need the HUP. Otherwise the file is kept open (so this is no
>>> easy way to improve performance ;))
>>
>> here is a run with the debug and valgrind options
>
> mmhhh... it still is missing lots of information. Did "make install"
> install to incorrect locations? This happens quite often, especially on
> x64 systems (I've fallen myself more than once into this trap).

trying again (this time remembering to add -c3 to the command line)

==12351== Memcheck, a memory error detector.

==12351== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.

==12351== Using LibVEX rev 1658, a library for dynamic binary translation.

==12351== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.

==12351== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.

==12351== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.

==12351== For more details, rerun with: -v

==12351==

==12351== My PID = 12351, parent PID = 11702.  Prog and args are:

==12351==    /usr/local/sbin/rsyslogd

==12351==    -c3

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x40091D5: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x40091DE: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010AEE: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010AF9: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010B04: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010C61: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006E47: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Invalid read of size 8

==12351==    at 0x4010C54: (within /lib/ld-2.3.6.so)

==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==  Address 0x5198EB0 is 16 bytes inside a block of size 23 alloc'd

==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12351==    by 0x4007113: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010A70: (within /lib/ld-2.3.6.so)

==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010A7F: (within /lib/ld-2.3.6.so)

==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010A8E: (within /lib/ld-2.3.6.so)

==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006117: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==12351==    by 0x4008B91: (within /lib/ld-2.3.6.so)

==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Invalid read of size 8

==12351==    at 0x4010C20: (within /lib/ld-2.3.6.so)

==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==  Address 0x519B1C0 is 32 bytes inside a block of size 35 alloc'd

==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12351==    by 0x4006123: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12352== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
hints

==12352==    This could cause spurious value errors to appear.

==12352==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
proper wrapper.

==12352==

==12352== Conditional jump or move depends on uninitialised value(s)

==12352==    at 0x4009442: (within /lib/ld-2.3.6.so)

==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==

==12352== Conditional jump or move depends on uninitialised value(s)

==12352==    at 0x4009339: (within /lib/ld-2.3.6.so)

==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==

==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)

==12352==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)

==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)

==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)

==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)

==12352==    by 0x5295D97: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D3D1: realMain (in /usr/local/sbin/rsyslogd)

==12352==  Address 0x7FEFFB361 is on thread 1's stack

==12351==

==12351== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)

==12351== malloc/free: in use at exit: 24,243 bytes in 445 blocks.

==12351== malloc/free: 585 allocs, 140 frees, 33,424 bytes allocated.

==12351== For counts of detected errors, rerun with: -v

==12351== searching for pointers to 445 not-freed blocks.

==12351== checked 174,016 bytes.

==12351==

==12351== LEAK SUMMARY:

==12351==    definitely lost: 0 bytes in 0 blocks.

==12351==      possibly lost: 0 bytes in 0 blocks.

==12351==    still reachable: 24,243 bytes in 445 blocks.

==12351==         suppressed: 0 bytes in 0 blocks.

==12351== Reachable blocks (those to which a pointer was found) are not 
shown.

==12351== To see them, rerun with: --show-reachable=yes

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAEDD: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF02: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF10: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E44 is 4 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF1E: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid write of size 4

==12352==    at 0x57AAF14: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid write of size 4

==12352==    at 0x57AAF38: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF4A: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid free() / delete / delete[]

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAF62: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)

==12352==    at 0x50202D0: sendto (in /lib/libc-2.3.6.so)

==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)

==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)

==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)

==12352==    by 0x5295D97: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==  Address 0x7FEFFB361 is on thread 1's stack

==12352==

==12352== Thread 5:

==12352== Invalid read of size 4

==12352==    at 0x57AB092: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)

==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AB063: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)

==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Thread 1:

==12352== Invalid read of size 4

==12352==    at 0x5295196: closeUDPListenSockets (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF20: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)



valgrind: m_mallocfree.c:194 (get_bszB_as_is): Assertion 'bszB_lo == 
bszB_hi' failed.

valgrind: Heap block lo/hi size mismatch: lo = 2, hi = 562949953486848.

Probably caused by overrunning/underrunning a heap block's bounds.



==12352==    at 0x3801770A: report_and_quit (m_libcassert.c:136)

==12352==    by 0x38017A6D: vgPlain_assert_fail (m_libcassert.c:200)

==12352==    by 0x380208D8: vgPlain_arena_malloc (m_mallocfree.c:191)

==12352==    by 0x3803523B: vgPlain_cli_malloc (replacemalloc_core.c:101)

==12352==    by 0x38002487: vgMemCheck_calloc (mc_malloc_wrappers.c:182)

==12352==    by 0x3803592F: do_client_request (scheduler.c:1166)

==12352==    by 0x38036FAD: vgPlain_scheduler (scheduler.c:869)

==12352==    by 0x38051849: run_a_thread_NORETURN (syswrap-linux.c:87)



sched status:

   running_tid=1



Thread 1: status = VgTs_Runnable

==12352==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)

==12352==    by 0x414B72: rsCStrConstruct (in /usr/local/sbin/rsyslogd)

==12352==    by 0x414D0C: rsCStrConstructFromszStr (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4162FB: rsParsConstructFromSz (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x5295D52: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)




From satoru.satoh at gmail.com  Mon Sep 15 11:56:29 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Mon, 15 Sep 2008 18:56:29 +0900
Subject: [rsyslog] docbook and math
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F12B@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F12B@grfint2.intern.adiscon.com>
Message-ID: <20080915095627.GA14056@localhost.localdomain>

Hi,


I don't have enough experience with docbook and math formulas but LaTeX
might be better for now unfortunatelly, I guess.

If you go with docbook, current dtd-based docbook (4.x) does not well
with MathML natively and you might have to convert math formula to some
formats of image somehow. There may be two choices.

 1) write math formulas in LaTex and convert to images (EPS, PNG, ...)
 2) write math formulas in MathML and convert to images (SVG, ...)

Here are some related links.

 * http://www.sagehill.net/docbookxsl/MathML.html
 * http://www.grigoriev.ru/svgmath/
 * http://www.sagehill.net/docbookxsl/SVGimages.html

IIWM, I would choose 2) (mathml -> svg) and try svgmath.

Other random notes about MathML:

 * OpenOffice.org-Math supports MathML output.

 * Gecho based browsers (e.g. firefox) can display MathML docs.
   * http://www.mozilla.org/projects/mathml/authoring.html
   * http://www.mozilla.org/projects/mathml/fonts/ (MathML fonts)

 * MathML has two ways to markup; contents markup and presentation
   markup. MathMLc2p
   (http://www.lri.fr/~pietriga/mathmlc2p/mathmlc2p.html) might 
   help if you have to transform from the former into the later.


- satoru

On Thu, Sep 11, 2008 at 03:27:49PM +0200, Rainer Gerhards wrote:
> Hi folks,
> 
> and especially those that are proficient with docbook ;) I have one
> question. I am thinking about a series of design papers. I think,
> however, that at least some of them will require a lot of mathematical
> formulas. Typically, I'd say that should be done in LaTeX. But with
> moving to docbook for the user doc, it may be good to use a single
> system.
> 
> I have now investigated docbook and maths a bit, but what I found didn't
> look very promising. The best I found was MathML, which is far too
> verbose for any hand-editing (and I don't want to rely on specialized
> formula editors). I also found some references to embedded TeX, but that
> looked quite hackish.
> 
> Could somebody enlighten me on the current typical approach for such
> papers? Do they still usually go the LaTeX way or is there a good way to
> do it with docbook?
> 
> Many thanks in advance,
> Rainer


From rgerhards at hq.adiscon.com  Mon Sep 15 11:57:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 11:57:14 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
Message-ID: <1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>

mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
still has no source line information. Without that, it has very little
value. OK, I'll look at some other ways.

Rainer

On Mon, 2008-09-15 at 02:51 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> > On Mon, 2008-09-15 at 02:07 -0700, david at lang.hm wrote:
> >> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> >>
> >>> On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
> >>>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> >>>
> >>>> one other item that occured to me, should I even be doing the kill -HUP?
> >>>> or does rsyslog open the file for writing each time (so that I just have
> >>>> to mv the file away and it will create a new one)?
> >>>
> >>> no, you need the HUP. Otherwise the file is kept open (so this is no
> >>> easy way to improve performance ;))
> >>
> >> here is a run with the debug and valgrind options
> >
> > mmhhh... it still is missing lots of information. Did "make install"
> > install to incorrect locations? This happens quite often, especially on
> > x64 systems (I've fallen myself more than once into this trap).
> 
> trying again (this time remembering to add -c3 to the command line)
> 
> ==12351== Memcheck, a memory error detector.
> 
> ==12351== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> 
> ==12351== Using LibVEX rev 1658, a library for dynamic binary translation.
> 
> ==12351== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> 
> ==12351== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
> framework.
> 
> ==12351== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> 
> ==12351== For more details, rerun with: -v
> 
> ==12351==
> 
> ==12351== My PID = 12351, parent PID = 11702.  Prog and args are:
> 
> ==12351==    /usr/local/sbin/rsyslogd
> 
> ==12351==    -c3
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x40091D5: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x40091DE: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010B04: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010C61: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006E47: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Invalid read of size 8
> 
> ==12351==    at 0x4010C54: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==  Address 0x5198EB0 is 16 bytes inside a block of size 23 alloc'd
> 
> ==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12351==    by 0x4007113: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010A70: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006117: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4008B91: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Invalid read of size 8
> 
> ==12351==    at 0x4010C20: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==  Address 0x519B1C0 is 32 bytes inside a block of size 35 alloc'd
> 
> ==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12351==    by 0x4006123: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12352== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
> hints
> 
> ==12352==    This could cause spurious value errors to appear.
> 
> ==12352==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
> proper wrapper.
> 
> ==12352==
> 
> ==12352== Conditional jump or move depends on uninitialised value(s)
> 
> ==12352==    at 0x4009442: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==
> 
> ==12352== Conditional jump or move depends on uninitialised value(s)
> 
> ==12352==    at 0x4009339: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==
> 
> ==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
> byte(s)
> 
> ==12352==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x5295D97: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D3D1: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==  Address 0x7FEFFB361 is on thread 1's stack
> 
> ==12351==
> 
> ==12351== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
> 
> ==12351== malloc/free: in use at exit: 24,243 bytes in 445 blocks.
> 
> ==12351== malloc/free: 585 allocs, 140 frees, 33,424 bytes allocated.
> 
> ==12351== For counts of detected errors, rerun with: -v
> 
> ==12351== searching for pointers to 445 not-freed blocks.
> 
> ==12351== checked 174,016 bytes.
> 
> ==12351==
> 
> ==12351== LEAK SUMMARY:
> 
> ==12351==    definitely lost: 0 bytes in 0 blocks.
> 
> ==12351==      possibly lost: 0 bytes in 0 blocks.
> 
> ==12351==    still reachable: 24,243 bytes in 445 blocks.
> 
> ==12351==         suppressed: 0 bytes in 0 blocks.
> 
> ==12351== Reachable blocks (those to which a pointer was found) are not 
> shown.
> 
> ==12351== To see them, rerun with: --show-reachable=yes
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAEDD: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF02: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF10: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E44 is 4 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF1E: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid write of size 4
> 
> ==12352==    at 0x57AAF14: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid write of size 4
> 
> ==12352==    at 0x57AAF38: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF4A: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid free() / delete / delete[]
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAF62: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
> byte(s)
> 
> ==12352==    at 0x50202D0: sendto (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x5295D97: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==  Address 0x7FEFFB361 is on thread 1's stack
> 
> ==12352==
> 
> ==12352== Thread 5:
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AB092: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)
> 
> ==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AB063: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)
> 
> ==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Thread 1:
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x5295196: closeUDPListenSockets (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF20: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> 
> 
> valgrind: m_mallocfree.c:194 (get_bszB_as_is): Assertion 'bszB_lo == 
> bszB_hi' failed.
> 
> valgrind: Heap block lo/hi size mismatch: lo = 2, hi = 562949953486848.
> 
> Probably caused by overrunning/underrunning a heap block's bounds.
> 
> 
> 
> ==12352==    at 0x3801770A: report_and_quit (m_libcassert.c:136)
> 
> ==12352==    by 0x38017A6D: vgPlain_assert_fail (m_libcassert.c:200)
> 
> ==12352==    by 0x380208D8: vgPlain_arena_malloc (m_mallocfree.c:191)
> 
> ==12352==    by 0x3803523B: vgPlain_cli_malloc (replacemalloc_core.c:101)
> 
> ==12352==    by 0x38002487: vgMemCheck_calloc (mc_malloc_wrappers.c:182)
> 
> ==12352==    by 0x3803592F: do_client_request (scheduler.c:1166)
> 
> ==12352==    by 0x38036FAD: vgPlain_scheduler (scheduler.c:869)
> 
> ==12352==    by 0x38051849: run_a_thread_NORETURN (syswrap-linux.c:87)
> 
> 
> 
> sched status:
> 
>    running_tid=1
> 
> 
> 
> Thread 1: status = VgTs_Runnable
> 
> ==12352==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> 
> ==12352==    by 0x414B72: rsCStrConstruct (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x414D0C: rsCStrConstructFromszStr (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4162FB: rsParsConstructFromSz (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x5295D52: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep 15 12:13:45 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 12:13:45 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
	<1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
Message-ID: <1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>

side-note: do you mind if we concentrate on the performance issue first
and keep an eye on this here (as a secondary goal) while we do it? I
think that would enable me to address both most quickly (I can add
instrumentation code/checks while I modify the file output). There may
come a time when reversing priorities makes sense, but for now I think
this would be the best way...

Rainer
On Mon, 2008-09-15 at 11:57 +0200, Rainer Gerhards wrote:
> mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
> still has no source line information. Without that, it has very little
> value. OK, I'll look at some other ways.




From david at lang.hm  Mon Sep 15 13:14:42 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 04:14:42 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
	<1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
	<1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> side-note: do you mind if we concentrate on the performance issue first
> and keep an eye on this here (as a secondary goal) while we do it? I
> think that would enable me to address both most quickly (I can add
> instrumentation code/checks while I modify the file output). There may
> come a time when reversing priorities makes sense, but for now I think
> this would be the best way...

no problem.

> Rainer
> On Mon, 2008-09-15 at 11:57 +0200, Rainer Gerhards wrote:
>> mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
>> still has no source line information. Without that, it has very little
>> value. OK, I'll look at some other ways.
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From lorenzo at sancho.ccd.uniroma2.it  Fri Sep 12 12:40:20 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Fri, 12 Sep 2008 12:40:20 +0200 (CEST)
Subject: [rsyslog] rsyslog frequent crashes
Message-ID: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>

The system is a dual processor / quad core Xeon E5335 running a 64 bit 
debian lenny distribution; I've enabled both debug and rtinst configure,
and installed an unstripped binary; I'm attaching the full backtrace here.

the system should act as a client to a remote syslog server; I'm enclosing 
the conf files too.

In the previous attempts (before enabling rtinst and debug), I got lines 
like "rsyslogd: double free or corruption (!prev): 0x0000000000674c50"
in the failover log (corresponding to the _nodebug backtrace); this last 
time, the line I've got is

"msg.c:273: msgDestruct: Assertion `(unsigned) ((obj_t*)
            (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed."

and the double free detector didn't fire.

I'm really at a loss now: I've been lured into experimenting rsyslog from 
the high level architectural description being this clean and seemingly 
powerful, but now I fear I still cannot rely on this logger in production.

Eager to help in debugging, sincerely yours

 	lorenzo



+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Core was generated by `/usr/sbin/rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 16283]
[New process 16285]
[New process 16284]
[New process 16282]
[New process 16281]
#0  0x00002b44aa374ef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 16281):
#0  0x00002b44aa40bf12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x000000000040efb9 in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:2563
	dbgCALLStaCK_POP_POINT = 0
	iRet = <value optimized out>
	i = <value optimized out>
	p = <value optimized out>
	num_fds = <value optimized out>
	ch = <value optimized out>
	hent = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0x1, 
    sa_sigaction = 0x1}, sa_mask = {__val = {0 <repeats 16 times>}}, 
  sa_flags = 0, sa_restorer = 0}
	bIsFirstOption = <value optimized out>
	bEOptionWasGiven = <value optimized out>
	bImUxSockLoaded = <value optimized out>
	arg = <value optimized out>
	legacyConfLine = '\0' <repeats 79 times>
	pdbgFuncDB = (dbgFuncDB_t *) 0x66e320
	__func__ = "realMain"
#2  0x00002b44aa3611a6 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#3  0x00000000004096b9 in _start ()
No locals.

Thread 4 (process 16282):
#0  0x00002b44a9d23fad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x0000000000416333 in dbgCondTimedWait (cond=0x686fe0, 
    pmut=0xffffffffffffff92, abstime=0x407fffd0, pFuncDB=0x6a6bc0, ln=403, 
    iStackPtr=<value optimized out>) at debug.c:555
	ret = <value optimized out>
#2  0x0000000000421f59 in wtiWorker (pThis=0x688160) at wti.c:403
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130748, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727512550297697851, 1727653793608105531}, __mask_was_saved = 0}}, 
  __pad = {0x408000d0, 0x0, 0x68a740, 0x19f}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 1
	iCancelStateSave = 0
	t = {tv_sec = 1221174340, tv_nsec = 609910833}
	pWtp = (wtp_t *) 0x687b50
	bInactivityTOOccured = 0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6a6bc0
	__func__ = "wtiWorker"
	__PRETTY_FUNCTION__ = "wtiWorker"
#3  0x00000000004209c2 in wtpWorker (arg=0x688160) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130512, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727511424978517563, 1727653794260319803}, __mask_was_saved = 0}}, 
  __pad = {0x408001e0, 0x0, 0x40800950, 0x40800950}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 0
	iCancelStateSave = 0
	pWti = (wti_t *) 0x688160
	pThis = (wtp_t *) 0x687b50
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x68a740
	__func__ = "wtpWorker"
	__PRETTY_FUNCTION__ = "wtpWorker"
#4  0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 3 (process 16284):
#0  0x00002b44aa40bf12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b44aacb4773 in runInput (pThrd=<value optimized out>)
    at imuxsock.c:235
	maxfds = 0
	nfds = <value optimized out>
	i = <value optimized out>
	fd = <value optimized out>
	readfds = {fds_bits = {1, 0 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x6aa6f0
	__func__ = "runInput"
#2  0x000000000041be2d in thrdStarter (arg=0x6a8a40) at threads.c:139
	dbgCALLStaCK_POP_POINT = 0
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x6aa620
	__func__ = "thrdStarter"
	__PRETTY_FUNCTION__ = "thrdStarter"
#3  0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 2 (process 16285):
#0  0x00002b44a9d267eb in read () from /lib/libpthread.so.0
No symbol table info available.
#1  0x00002b44aaeb91c7 in klogLogKMsg () at linux.c:454
	dbgCALLStaCK_POP_POINT = 2
	pdbgFuncDB = (dbgFuncDB_t *) 0x6af730
	__func__ = "klogLogKMsg"
#2  0x00002b44aaeb84a4 in runInput (pThrd=0x6abae0) at imklog.c:208
	dbgCALLStaCK_POP_POINT = 1
	iRet = RS_RET_OK
	pdbgFuncDB = (dbgFuncDB_t *) 0x6af660
	__func__ = "runInput"
#3  0x000000000041be2d in thrdStarter (arg=0x6abae0) at threads.c:139
	dbgCALLStaCK_POP_POINT = 0
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x6aa620
	__func__ = "thrdStarter"
	__PRETTY_FUNCTION__ = "thrdStarter"
#4  0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 1 (process 16283):
#0  0x00002b44aa374ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b44aa376413 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x0000000000415a5f in sigsegvHdlr (signum=6) at debug.c:741
	signame = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
  sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0}
#3  <signal handler called>
No symbol table info available.
#4  0x00002b44aa374ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#5  0x00002b44aa376413 in abort () from /lib/libc.so.6
No symbol table info available.
#6  0x00002b44aa36ddc9 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#7  0x000000000042e550 in msgDestruct (ppThis=0x692a20) at msg.c:273
	dbgCALLStaCK_POP_POINT = 8
	iCancelStateSave = <value optimized out>
	pThis = (msg_t *) 0x2aaaac0008c0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6addf0
	__func__ = "msgDestruct"
	__PRETTY_FUNCTION__ = "msgDestruct"
#8  0x000000000043d346 in actionCallAction (pAction=0x6929c0, 
    pMsg=0x2aaaac000ac0) at action.c:661
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {6891968, 
        1727510324980350523, 6, 4240656, 1090522784, 1090522696, 
        1727510325009710651, 1727653804676349499}, __mask_was_saved = 0}}, 
  __pad = {0x41000f60, 0x0, 0x692820, 0x40b510}}
	__cancel_arg = (void *) 0x692a70
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 7
	iRet = <value optimized out>
	iCancelStateSave = 0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ad2b0
	__func__ = "actionCallAction"
	__PRETTY_FUNCTION__ = "actionCallAction"
#9  0x000000000040b567 in processMsgDoActions (pData=0x6929c0, 
    pParam=0x41000ea0) at syslogd.c:1094
	dbgCALLStaCK_POP_POINT = 6
	iRet = <value optimized out>
	iRetMod = <value optimized out>
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ad180
	__func__ = "processMsgDoActions"
	__PRETTY_FUNCTION__ = "processMsgDoActions"
#10 0x000000000043c0ce in llExecFunc (pThis=0x692820, 
    pFunc=0x40b510 <processMsgDoActions>, pParam=0x41000ea0)
    at linkedlist.c:390
	dbgCALLStaCK_POP_POINT = 5
	iRet = RS_RET_OK
	iRetLL = RS_RET_OK
	pData = (void *) 0x6929c0
	llCookie = (linkedListCookie_t) 0x6920c0
	llCookiePrev = (linkedListCookie_t) 0x0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ad050
	__func__ = "llExecFunc"
	__PRETTY_FUNCTION__ = "llExecFunc"
#11 0x000000000040b0c9 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x2aaaac000ac0) at syslogd.c:1137
	dbgCALLStaCK_POP_POINT = 3
	pMsg = (msg_t *) 0x2aaaac000ac0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6accb0
	__func__ = "msgConsumer"
	__PRETTY_FUNCTION__ = "msgConsumer"
#12 0x000000000042521f in queueConsumerReg (pThis=0x692db0, pWti=0x6a6900, 
    iCancelStateSave=<value optimized out>) at queue.c:1570
	dbgCALLStaCK_POP_POINT = 2
	iRet = RS_RET_OK
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ac8d0
	__func__ = "queueConsumerReg"
	__PRETTY_FUNCTION__ = "queueConsumerReg"
#13 0x0000000000421eb0 in wtiWorker (pThis=0x6a6900) at wti.c:413
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523452, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727510324967767611, 1727653793608105531}, __mask_was_saved = 0}}, 
  __pad = {0x410010d0, 0x0, 0x68a740, 0x19f}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 1
	iCancelStateSave = 0
	t = {tv_sec = 1221174340, tv_nsec = 478220993}
	pWtp = (wtp_t *) 0x680d90
	bInactivityTOOccured = 0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6a6bc0
	__func__ = "wtiWorker"
	__PRETTY_FUNCTION__ = "wtiWorker"
#14 0x00000000004209c2 in wtpWorker (arg=0x6a6900) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523216, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727510324930018875, 1727653794260319803}, __mask_was_saved = 0}}, 
  __pad = {0x410011e0, 0x0, 0x0, 0x0}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 0
	iCancelStateSave = 0
	pWti = (wti_t *) 0x6a6900
	pThis = (wtp_t *) 0x680d90
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x68a740
	__func__ = "wtpWorker"
	__PRETTY_FUNCTION__ = "wtpWorker"
#15 0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#16 0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#17 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) 
-------------- next part --------------
#  /etc/rsyslog.conf	Configuration file for rsyslog v3.
#
#			For more information see 
#			/usr/share/doc/rsyslog-doc/html/rsyslog_conf.html


#################
#### MODULES ####
#################

$ModLoad imuxsock # provides support for local system logging
$ModLoad imklog   # provides kernel logging support (previously done by rklogd) 
#$ModLoad immark  # provides --MARK-- message capability

# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514


###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use default timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf


###############
#### RULES ####
###############

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*			/var/log/auth.log
*.*;auth,authpriv.none		-/var/log/syslog
#cron.*				/var/log/cron.log
daemon.*			-/var/log/daemon.log
kern.*				-/var/log/kern.log
lpr.*				-/var/log/lpr.log
#mail.*				-/var/log/mail.log
user.*				-/var/log/user.log

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info			-/var/log/mail.info
mail.warn			-/var/log/mail.warn
mail.err			/var/log/mail.err

#
# Logging for INN news system.
#
news.crit			/var/log/news/news.crit
news.err			/var/log/news/news.err
news.notice			-/var/log/news/news.notice

#
# Some "catch-all" log files.
#
*.=debug;\
	auth,authpriv.none;\
	news.none;mail.none	-/var/log/debug
*.=info;*.=notice;*.=warn;\
	auth,authpriv.none;\
	cron,daemon.none;\
	mail,news.none		-/var/log/messages

#
# Emergencies are sent to everybody logged in.
#
*.emerg				*

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;\
#	news.=crit;news.=err;news.=notice;\
#	*.=debug;*.=info;\
#	*.=notice;*.=warn	/dev/tty8

# The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
# you must invoke `xconsole' with the `-file' option:
# 
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
#      busy site..
#
daemon.*;mail.*;\
	news.err;\
	*.=debug;*.=info;\
	*.=notice;*.=warn	|/dev/xconsole
-------------- next part --------------
#$ModLoad omrelp 
$WorkDirectory /var/log/rsyslog 
$ActionQueueType LinkedList   # use asynchronous processing
$ActionQueueFileName srvrfwd  # set file name, also enables disk mode
$ActionResumeRetryCount -1    # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
mail.* @@<remote_addr>:514

$ActionExecOnlyIfPreviousIsSuspended on
& /var/log/rsyslog/failover.log
$ActionExecOnlyIfPreviousIsSuspended off

-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Core was generated by `/usr/sbin/rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 23847]
[New process 23849]
[New process 23848]
[New process 23846]
[New process 23845]
#0  0x00002b479d1c3ef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 23845):
#0  0x00002b479d25af12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x000000000040e0c9 in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:2563
	iRet = <value optimized out>
	i = <value optimized out>
	p = <value optimized out>
	num_fds = <value optimized out>
	ch = <value optimized out>
	hent = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0x1, 
    sa_sigaction = 0x1}, sa_mask = {__val = {0 <repeats 16 times>}}, 
  sa_flags = 0, sa_restorer = 0}
	bIsFirstOption = <value optimized out>
	bEOptionWasGiven = <value optimized out>
	bImUxSockLoaded = <value optimized out>
	arg = <value optimized out>
	legacyConfLine = '\0' <repeats 79 times>
#2  0x00002b479d1b01a6 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#3  0x0000000000409609 in _start ()
No locals.

Thread 4 (process 23846):
#0  0x00002b479cb72fad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x0000000000418e00 in wtiWorker (pThis=0x64f4a0) at wti.c:403
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130748, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094035857682333242, 9093894727638318650}, __mask_was_saved = 0}}, 
  __pad = {0x408000d0, 0x0, 0x40800950, 0x40800950}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	t = {tv_sec = 1221135378, tv_nsec = 723151645}
	pWtp = (wtp_t *) 0x64f360
	bInactivityTOOccured = 0
#2  0x0000000000418032 in wtpWorker (arg=<value optimized out>) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130512, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094034911474613818, 9093894729333866042}, __mask_was_saved = 0}}, 
  __pad = {0x408001e0, 0x0, 0x40800950, 0x40800950}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	pWti = (wti_t *) 0x64f4a0
	pThis = (wtp_t *) 0x64f360
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#3  0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 3 (process 23848):
#0  0x00002b479d25af12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b479db01413 in runInput (pThrd=<value optimized out>)
    at imuxsock.c:235
	maxfds = 0
	nfds = <value optimized out>
	i = <value optimized out>
	fd = <value optimized out>
	readfds = {fds_bits = {1, 0 <repeats 15 times>}}
#2  0x0000000000416420 in thrdStarter (arg=0x66bd70) at threads.c:139
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#3  0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 2 (process 23849):
#0  0x00002b479cb757eb in read () from /lib/libpthread.so.0
No symbol table info available.
#1  0x00002b479dd05c5f in klogLogKMsg () at linux.c:454
No locals.
#2  0x00002b479dd0517c in runInput (pThrd=0x66c1f0) at imklog.c:208
	iRet = <value optimized out>
#3  0x0000000000416420 in thrdStarter (arg=0x66c1f0) at threads.c:139
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#4  0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 1 (process 23847):
#0  0x00002b479d1c3ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b479d1c5413 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x0000000000411abf in sigsegvHdlr (signum=6) at debug.c:741
	signame = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
  sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0}
#3  <signal handler called>
No symbol table info available.
#4  0x00002b479d1c3ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#5  0x00002b479d1c5413 in abort () from /lib/libc.so.6
No symbol table info available.
#6  0x00002b479d2003e8 in __libc_message () from /lib/libc.so.6
No symbol table info available.
#7  0x00002b479d205968 in malloc_printerr () from /lib/libc.so.6
No symbol table info available.
#8  0x00002b479d207a76 in free () from /lib/libc.so.6
No symbol table info available.
#9  0x0000000000420f2d in msgDestruct (ppThis=0x6532a0) at msg.c:284
	iCancelStateSave = 0
	pThis = (msg_t *) 0x2aaab401e480
#10 0x000000000042a797 in actionCallAction (pAction=0x653240, 
    pMsg=0x2aaab0020620) at action.c:661
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090522832, 
        9093895273491594810, 6631600, 1090522832, 4238944, 1090522856, 
        9094038209632009786, 9093894735514959418}, __mask_was_saved = 0}}, 
  __pad = {0x41000f70, 0x0, 0xbf11, 0x0}}
	__cancel_arg = (void *) 0x6532f0
	not_first_call = <value optimized out>
	iRet = <value optimized out>
	iCancelStateSave = 0
#11 0x000000000040ae79 in processMsgDoActions (pData=0x5d25, pParam=0x41000ed0)
    at syslogd.c:1094
	iRet = <value optimized out>
	iRetMod = <value optimized out>
#12 0x0000000000429b97 in llExecFunc (pThis=0x6530b0, 
    pFunc=0x40ae60 <processMsgDoActions>, pParam=0x41000ed0)
    at linkedlist.c:390
	iRet = RS_RET_OK
	llCookie = (linkedListCookie_t) 0x652c60
	llCookiePrev = (linkedListCookie_t) 0x0
#13 0x000000000040aab0 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=<value optimized out>) at syslogd.c:1137
	pMsg = (msg_t *) 0x2aaab0020620
#14 0x000000000041aa31 in queueConsumerReg (pThis=0x656980, pWti=0x64bcf0, 
    iCancelStateSave=<value optimized out>) at queue.c:1570
	iRet = RS_RET_OK
#15 0x0000000000418e6f in wtiWorker (pThis=0x64bcf0) at wti.c:413
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523452, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094038209713798714, 9093894727638318650}, __mask_was_saved = 0}}, 
  __pad = {0x410010d0, 0x0, 0x0, 0x0}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	t = {tv_sec = 1221135378, tv_nsec = 595602238}
	pWtp = (wtp_t *) 0x64bbb0
	bInactivityTOOccured = 0
#16 0x0000000000418032 in wtpWorker (arg=<value optimized out>) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523216, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094038210546368058, 9093894729333866042}, __mask_was_saved = 0}}, 
  __pad = {0x410011e0, 0x0, 0x0, 0x0}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	pWti = (wti_t *) 0x64bcf0
	pThis = (wtp_t *) 0x64bbb0
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#17 0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#18 0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#19 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) quit

From hks.private at gmail.com  Mon Sep 15 19:06:23 2008
From: hks.private at gmail.com ((private) HKS)
Date: Mon, 15 Sep 2008 13:06:23 -0400
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
Message-ID: <ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>

What version of rsyslog is this?

-HKS

On Fri, Sep 12, 2008 at 6:40 AM, Lorenzo M. Catucci
<lorenzo at sancho.ccd.uniroma2.it> wrote:
> The system is a dual processor / quad core Xeon E5335 running a 64 bit
> debian lenny distribution; I've enabled both debug and rtinst configure,
> and installed an unstripped binary; I'm attaching the full backtrace here.
>
> the system should act as a client to a remote syslog server; I'm enclosing
> the conf files too.
>
> In the previous attempts (before enabling rtinst and debug), I got lines
> like "rsyslogd: double free or corruption (!prev): 0x0000000000674c50"
> in the failover log (corresponding to the _nodebug backtrace); this last
> time, the line I've got is
>
> "msg.c:273: msgDestruct: Assertion `(unsigned) ((obj_t*)
>           (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed."
>
> and the double free detector didn't fire.
>
> I'm really at a loss now: I've been lured into experimenting rsyslog from
> the high level architectural description being this clean and seemingly
> powerful, but now I fear I still cannot rely on this logger in production.
>
> Eager to help in debugging, sincerely yours
>
>        lorenzo
>
>
>
> +-------------------------+----------------------------------------------+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
> +-------------------------+----------------------------------------------+
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
>


From david at lang.hm  Tue Sep 16 06:44:30 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 21:44:30 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
	<1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
	<1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>
Message-ID: <alpine.DEB.1.10.0809152143060.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, david at lang.hm wrote:

> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>
>> side-note: do you mind if we concentrate on the performance issue first
>> and keep an eye on this here (as a secondary goal) while we do it? I
>> think that would enable me to address both most quickly (I can add
>> instrumentation code/checks while I modify the file output). There may
>> come a time when reversing priorities makes sense, but for now I think
>> this would be the best way...
>
> no problem.

an interesting tidbit, once I started the performance testing with name 
lookups turned off I haven't had a failure of the rotation.

I left it running overnight under heavy load, so I'll see how far it got 
in the morning.

David Lang

>> Rainer
>> On Mon, 2008-09-15 at 11:57 +0200, Rainer Gerhards wrote:
>>> mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
>>> still has no source line information. Without that, it has very little
>>> value. OK, I'll look at some other ways.
>>
>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Tue Sep 16 07:17:02 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 16 Sep 2008 07:17:02 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809152143060.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm><1221462796.2682.28.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm><1221463183.2682.32.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm><1221463684.2682.37.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm><1221464240.2682.41.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm><1221467031.2682.48.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm><1221469046.2682.50.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm><1221470899.2682.60.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm><1221472634.2682.62.camel@rgf9dev.intern.adiscon.com><1221473625.2682.65.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>
	<alpine.DEB.1.10.0809152143060.17326@asg ard.lang.hm>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F147@grfint2.intern.adiscon.com>

> an interesting tidbit, once I started the performance testing with
name
> lookups turned off I haven't had a failure of the rotation.
> 
> I left it running overnight under heavy load, so I'll see how far it
> got
> in the morning.

Oh, that's very interesting.

Looking forward to the results.

Rainer


From lorenzo at sancho.ccd.uniroma2.it  Tue Sep 16 09:50:11 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Tue, 16 Sep 2008 09:50:11 +0200 (CEST)
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
	<ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>

On Mon, 15 Sep 2008, (private) HKS wrote:

> What version of rsyslog is this?
>
> -HKS
>

At first it was with pristine debian's 3.18.2; I later tried upgrading to 
3.18.3 but the problem persisted.

Sorry for confusion.

Thank you,

 	lorenzo


From hks.private at gmail.com  Tue Sep 16 15:52:49 2008
From: hks.private at gmail.com ((private) HKS)
Date: Tue, 16 Sep 2008 09:52:49 -0400
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
	<ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>
	<alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>
Message-ID: <ac9ded160809160652v7a6e0598q37a17452523d270a@mail.gmail.com>

This looks similar to the issue I reported at
http://kb.monitorware.com/random-daemon-stops-t8626.html

I haven't been able to reproduce it with any frequency, so hopefully
your data will be what Rainer needs to track this down.

-HKS


On Tue, Sep 16, 2008 at 3:50 AM, Lorenzo M. Catucci
<lorenzo at sancho.ccd.uniroma2.it> wrote:
> On Mon, 15 Sep 2008, (private) HKS wrote:
>
>> What version of rsyslog is this?
>>
>> -HKS
>>
>
> At first it was with pristine debian's 3.18.2; I later tried upgrading to
> 3.18.3 but the problem persisted.
>
> Sorry for confusion.
>
> Thank you,
>
>        lorenzo
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Tue Sep 16 15:54:00 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 16 Sep 2008 15:54:00 +0200
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <ac9ded160809160652v7a6e0598q37a17452523d270a@mail.gmail.com>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it><ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com><alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>
	<ac9ded160809160652v7a6e0598q37a17452523d270a@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F155@grfint2.intern.adiscon.com>

Sorry for not replying yet. I am currently very busy with another
activity. Though not a crash, I'd like to finish that first, before I
lose the context that was so costly to achive ;)

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of (private) HKS
> Sent: Tuesday, September 16, 2008 3:53 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog frequent crashes
> 
> This looks similar to the issue I reported at
> http://kb.monitorware.com/random-daemon-stops-t8626.html
> 
> I haven't been able to reproduce it with any frequency, so hopefully
> your data will be what Rainer needs to track this down.
> 
> -HKS
> 
> 
> On Tue, Sep 16, 2008 at 3:50 AM, Lorenzo M. Catucci
> <lorenzo at sancho.ccd.uniroma2.it> wrote:
> > On Mon, 15 Sep 2008, (private) HKS wrote:
> >
> >> What version of rsyslog is this?
> >>
> >> -HKS
> >>
> >
> > At first it was with pristine debian's 3.18.2; I later tried
> upgrading to
> > 3.18.3 but the problem persisted.
> >
> > Sorry for confusion.
> >
> > Thank you,
> >
> >        lorenzo
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> >
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From david at lang.hm  Tue Sep 16 19:03:54 2008
From: david at lang.hm (david at lang.hm)
Date: Tue, 16 Sep 2008 10:03:54 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F147@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F147@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809161002240.21981@asgard.lang.hm>

On Tue, 16 Sep 2008, Rainer Gerhards wrote:

>> an interesting tidbit, once I started the performance testing with
> name
>> lookups turned off I haven't had a failure of the rotation.
>>
>> I left it running overnight under heavy load, so I'll see how far it
>> got
>> in the morning.
>
> Oh, that's very interesting.
>
> Looking forward to the results.

a little more detail.

if I do an strace of a thread when I do the HUP, that thread does not 
close properly and never releases the file (I think the same thing was 
happening when I tried to run it under valgrind)

with name lookups disabled it ran overnight rotating once a min 
(processing 40,000 requests/sec)

David Lang


From rgerhards at hq.adiscon.com  Wed Sep 17 15:42:16 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 17 Sep 2008 15:42:16 +0200
Subject: [rsyslog] Change to mark message algo
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F16A@grfint2.intern.adiscon.com>

Hi,

initially driven by a performance discussion, the question has come up
when mark messages should be processed.

The current implementation is (by design) close to what sysklogd does:
marks are generated in intervals for all outputs (files and such) and
are send to each of the outputs. The outputs process the mark message if
the output was idle for at least half the past interval (otherwise, the
mark is simply ignored).

So, looking from an individual output's point of view, mark messages do
not happen at precise intervals after the last message was processed by
the output, but seem to be rather random from that POV.

In rsyslog, I use the time the message was handed over to the output as
the time of last processing. Some (namely David Lang in the link below)
can argue that this is incorrect, or at least not the only way to handle
it valid. The argument is that the time of message reception is the one
to look at when processing marks. After some hesitation, I see some
logic in this definition and I am very tempted to change rsyslog to use
that definition. Obviously, this can result in different mark handling
than to what we have today. Usually, though, things are not really
different, but they may become quite different if a messages was stuck
in a queue for some time.

I invite you to have a look at the relevant forum discussion. This is a
good entry point:

http://kb.monitorware.com/rsyslog-performance-t8691-30.html#p13825

Please let me know if you have any concerns. If I do not hear anything,
I'll change rsyslog to use the reception timestamp. This also has
performance benefit.

Thanks,
Rainer


From hks.private at gmail.com  Wed Sep 17 16:41:22 2008
From: hks.private at gmail.com ((private) HKS)
Date: Wed, 17 Sep 2008 10:41:22 -0400
Subject: [rsyslog] Change to mark message algo
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F16A@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16A@grfint2.intern.adiscon.com>
Message-ID: <ac9ded160809170741t29870421g9f68c5b0e176cbee@mail.gmail.com>

No concerns here - that makes significantly more sense to an
undereducated sysadmin.

-HKS

On Wed, Sep 17, 2008 at 9:42 AM, Rainer Gerhards
<rgerhards at hq.adiscon.com> wrote:
> Hi,
>
> initially driven by a performance discussion, the question has come up
> when mark messages should be processed.
>
> The current implementation is (by design) close to what sysklogd does:
> marks are generated in intervals for all outputs (files and such) and
> are send to each of the outputs. The outputs process the mark message if
> the output was idle for at least half the past interval (otherwise, the
> mark is simply ignored).
>
> So, looking from an individual output's point of view, mark messages do
> not happen at precise intervals after the last message was processed by
> the output, but seem to be rather random from that POV.
>
> In rsyslog, I use the time the message was handed over to the output as
> the time of last processing. Some (namely David Lang in the link below)
> can argue that this is incorrect, or at least not the only way to handle
> it valid. The argument is that the time of message reception is the one
> to look at when processing marks. After some hesitation, I see some
> logic in this definition and I am very tempted to change rsyslog to use
> that definition. Obviously, this can result in different mark handling
> than to what we have today. Usually, though, things are not really
> different, but they may become quite different if a messages was stuck
> in a queue for some time.
>
> I invite you to have a look at the relevant forum discussion. This is a
> good entry point:
>
> http://kb.monitorware.com/rsyslog-performance-t8691-30.html#p13825
>
> Please let me know if you have any concerns. If I do not hear anything,
> I'll change rsyslog to use the reception timestamp. This also has
> performance benefit.
>
> Thanks,
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Wed Sep 17 17:57:25 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 17 Sep 2008 17:57:25 +0200
Subject: [rsyslog] abort cases
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>

Hi,

just an update. While I have been silent, I am looking at the aborts
that were recently reported. I think they are related to threading
issues. I am reviewing some code and conducting some tests. This
unfortunately takes some time. I just wanted to let you know that
something is happening ;)

Interestingly, this seems to play nicely with the performance
optimization effort. It may even be that removing the cause could
improve performance, but it is too early to be sure it will... I have
not yet identified a sure cause.

I will keep you updated and post questions when I have them.

Thanks,
Rainer


From lorenzo at sancho.ccd.uniroma2.it  Wed Sep 17 18:46:22 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Wed, 17 Sep 2008 18:46:22 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>

On Wed, 17 Sep 2008, Rainer Gerhards wrote:

> Hi,
>
> just an update. While I have been silent, I am looking at the aborts
> that were recently reported. I think they are related to threading
> issues. I am reviewing some code and conducting some tests. This
> unfortunately takes some time. I just wanted to let you know that
> something is happening ;)
>

In the meanwhile, I've compiled once more with --enable-valgrind and I'm 
running the daemon under valgrind. Since with no other change the daemon 
is still running, while it usually didn't last more than 12 hours, it 
seems the timing variation does somewhat cure the symptoms.

>
> Interestingly, this seems to play nicely with the performance
> optimization effort. It may even be that removing the cause could
> improve performance, but it is too early to be sure it will... I have
> not yet identified a sure cause.
>
> I will keep you updated and post questions when I have them.
>

We are all waiting for you questions... in the hope we can be of any help!

Thank you, yours

 	lorenzo


From rgerhards at hq.adiscon.com  Wed Sep 17 18:49:01 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 17 Sep 2008 18:49:01 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>

> > just an update. While I have been silent, I am looking at the aborts
> > that were recently reported. I think they are related to threading
> > issues. I am reviewing some code and conducting some tests. This
> > unfortunately takes some time. I just wanted to let you know that
> > something is happening ;)
> >
> 
> In the meanwhile, I've compiled once more with --enable-valgrind and
> I'm
> running the daemon under valgrind. Since with no other change the
> daemon
> is still running, while it usually didn't last more than 12 hours, it
> seems the timing variation does somewhat cure the symptoms.

This is what I am thinking, too. I am running it under helgrind. If you
do that, you'll see a couple of warnings, most have been found to be
harmless by previous analysis. Anyhow, I am re-doing the analysis now
(what takes quite a bit of time). I am just telling you so that you
don't wonder when you see so many warnings. I think there is even a
discussion thread somewhere telling why this is. Mostly it is cases
where we do not really need sync... or so I thought ;)

Rainer


From lorenzo at sancho.ccd.uniroma2.it  Wed Sep 17 19:36:42 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Wed, 17 Sep 2008 19:36:42 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>

>> is still running, while it usually didn't last more than 12 hours, it
>> seems the timing variation does somewhat cure the symptoms.
>
> This is what I am thinking, too. I am running it under helgrind. If you
> do that, you'll see a couple of warnings, most have been found to be
> harmless by previous analysis. Anyhow, I am re-doing the analysis now
> (what takes quite a bit of time). I am just telling you so that you
> don't wonder when you see so many warnings. I think there is even a
> discussion thread somewhere telling why this is. Mostly it is cases
> where we do not really need sync... or so I thought ;)
>

Just to help me understand, do you think val-grinding this time is 
near-to-useless, and I'd better restart the daemon under helgrind, or you 
prefer I continue valgrinding while you helgrind?

I feared uttering the words "race condition" would have been doing just 
like the patient telling the doctor what he does want to hear as a 
dyagnosis... now that I see you are looking for missing syncs I think we 
share this gut feeling... Please let me know if I can help more, since 
I'm somewhat in the hope this dreaded shared memory 8 way system could 
very well shake the races... As a matter of fact, the destination server 
is a twin-brother of the source one, and is running (and logging to 
postgresql) without any hiccup since started-up.

Thank you very much, yours,

 	lorenzo


From rgerhards at hq.adiscon.com  Thu Sep 18 09:23:11 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 09:23:11 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
Message-ID: <1221722591.2682.137.camel@rgf9dev.intern.adiscon.com>

On Wed, 2008-09-17 at 19:36 +0200, Lorenzo M. Catucci wrote:
> >> is still running, while it usually didn't last more than 12 hours, it
> >> seems the timing variation does somewhat cure the symptoms.
> >
> > This is what I am thinking, too. I am running it under helgrind. If you
> > do that, you'll see a couple of warnings, most have been found to be
> > harmless by previous analysis. Anyhow, I am re-doing the analysis now
> > (what takes quite a bit of time). I am just telling you so that you
> > don't wonder when you see so many warnings. I think there is even a
> > discussion thread somewhere telling why this is. Mostly it is cases
> > where we do not really need sync... or so I thought ;)
> >
> 
> Just to help me understand, do you think val-grinding this time is 
> near-to-useless, and I'd better restart the daemon under helgrind, or you 
> prefer I continue valgrinding while you helgrind?

>From a pragmatical POV: if running it under valgrind helps ease the
immediate problem, please do that. I suspect valgrind will not report
anything, but if it does, that would probably be very interesting.

Using valgrind's helgrind tool does not make sense to you, because it
emits lots of message, which need to be interpreted by someone with deep
knowledge of the code. This is what I am looking at.

> I feared uttering the words "race condition" would have been doing just 
> like the patient telling the doctor what he does want to hear as a 
> dyagnosis... now that I see you are looking for missing syncs I think we 
> share this gut feeling... 

Yes, definitely. There is also one not directly technical reason that
makes me believe this: we had almost no serious issue with rsyslog since
the highly parallel multi-threading engine was introduced. I was a bit
astonished, because doing such a complex beast absolutely correctly in
the first place - even with the lots of testing it received in my
environment - is something I only very seldomly hear about. Now, out of
the sudden, multiple bug reports, all pointing into the same direction
come in. I now conclude that many folks were hesitant to actually use
the new version and now that time has passed, deployments into high
demand environments begin. Unfortunately, I do not have funding for the
high end machines and the amount of time required to do all these high
end testing after the release was finished (and even if I had, I'd
probably still not seen one issue or the other). So it sounds somewhat
logical to me that we have now begun to actually do the firedrill for
the new highly parallel processing part. And that, of course, points
into issues with thread execution order, aka race conditions ;) This
direction would also explain why the issues did not come up earlier
(with reasoning given above).

> Please let me know if I can help more, since 
> I'm somewhat in the hope this dreaded shared memory 8 way system could 
> very well shake the races... As a matter of fact, the destination server 
> is a twin-brother of the source one, and is running (and logging to 
> postgresql) without any hiccup since started-up.

All you can do at this time is being patient. I am reviewing the code.
The worker thread pools and all this logic is highly complex. I must
make sure that I have again a very tight grip on it, review all the
subtle cases I came along and then look at the helgrind output and other
diagnostic sources to see where the issue is. Probably then it would be
useful to have a gdb backtrace of an aborted process (or the more the
better), but my experience with these kinds of problems is that good
analysis is more likely to solve them than any captured real-time data.

As soon as I have a question, I'll post. Should you notice something
that you find interesting, please post. Ignoring something is easy, not
knowing something that may potentially help would be bad ;)

Rainer



From rgerhards at hq.adiscon.com  Thu Sep 18 09:35:17 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 09:35:17 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
Message-ID: <1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>

> Please let me know if I can help more, since 
> I'm somewhat in the hope this dreaded shared memory 8 way system could 
> very well shake the races... As a matter of fact, the destination server 
> is a twin-brother of the source one, and is running (and logging to 
> postgresql) without any hiccup since started-up.

Oh, I forgot, there is one thing you could actually do: I do not intend
to do any threading changes to the current stable. This may sound silly,
because it looks like a bug, but I expect that a lot of changes need to
be done, especially to make helgrind happy (so that it can be used). The
amount of changes I expect are far too intrusive for the stable. After
all, the majority of folks do not experience the bug. So the "fix" will
become part of the current devel.

As such, it would be very useful for me if you could try out the latest
devel versions as I modify them. It would be really great if you could
pull them from my git archive at git.adiscon.com/git/rsyslog.git

The same to everyone else interested in this work ;)

Rainer



From rgerhards at hq.adiscon.com  Thu Sep 18 09:59:15 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 09:59:15 +0200
Subject: [rsyslog] rsyslog 3.18.4 released
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F170@grfint2.intern.adiscon.com>

Hi all,

I have just released rsyslog 3.18.4, a member of the v3-stable branch.
This is a bugfixing release. It contains a number of fixes, most
importantly one that could cause undesired message discarding when the
queue is nearly full. This was caused by an invalid default enabling
discard-on-queue-full when this was not explicitly configured. There are
also other fixes. All users of the v3-stable branch are advised to
update to this release.

Changelog with full details:
http://www.rsyslog.com/Article277.phtml

Download:
http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-131.phtml

I hope this release is useful. As always, feedback is greatly
appreciated.
Rainer


From rgerhards at hq.adiscon.com  Thu Sep 18 10:14:35 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 10:14:35 +0200
Subject: [rsyslog] autoconf support for atomic operations
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>

Hi all,

in my effort to get a clean helgrind output (and to solve the stability
problems that recently showed up, I am going to re-enable support for
atomic operations). Unfortunately, the following post is still correct
and I do not know how to use autotools to check for the ability of
atomic operations:

http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html

While the post contains a potentially good pointer to a solution, I do
not know how to apply it to rsyslog ;) If anyone could lend me a helping
hand, that would be great. In the meantime, I'll simply go and make a
--enable-atomic ./configure switch - that's IMHO the best solution given
the current state of affairs.

Rainer


From rgerhards at hq.adiscon.com  Thu Sep 18 10:35:27 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 10:35:27 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>

Hold on... I should have searched first, then asked. Looks like I found
a solution. Will post more later.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Thursday, September 18, 2008 10:15 AM
> To: rsyslog-users
> Subject: [rsyslog] autoconf support for atomic operations
> 
> Hi all,
> 
> in my effort to get a clean helgrind output (and to solve the
stability
> problems that recently showed up, I am going to re-enable support for
> atomic operations). Unfortunately, the following post is still correct
> and I do not know how to use autotools to check for the ability of
> atomic operations:
> 
> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> 
> While the post contains a potentially good pointer to a solution, I do
> not know how to apply it to rsyslog ;) If anyone could lend me a
> helping
> hand, that would be great. In the meantime, I'll simply go and make a
> --enable-atomic ./configure switch - that's IMHO the best solution
> given
> the current state of affairs.
> 
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Thu Sep 18 10:50:38 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 10:50:38 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>

Yes, looks like it works. This is what I did:

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123c
83383ba256c4e67679c8d

Comments are appreciated.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Thursday, September 18, 2008 10:35 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] autoconf support for atomic operations
> 
> Hold on... I should have searched first, then asked. Looks like I
found
> a solution. Will post more later.
> 
> Rainer
> 
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> > Sent: Thursday, September 18, 2008 10:15 AM
> > To: rsyslog-users
> > Subject: [rsyslog] autoconf support for atomic operations
> >
> > Hi all,
> >
> > in my effort to get a clean helgrind output (and to solve the
> stability
> > problems that recently showed up, I am going to re-enable support
for
> > atomic operations). Unfortunately, the following post is still
> correct
> > and I do not know how to use autotools to check for the ability of
> > atomic operations:
> >
> > http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> >
> > While the post contains a potentially good pointer to a solution, I
> do
> > not know how to apply it to rsyslog ;) If anyone could lend me a
> > helping
> > hand, that would be great. In the meantime, I'll simply go and make
a
> > --enable-atomic ./configure switch - that's IMHO the best solution
> > given
> > the current state of affairs.
> >
> > Rainer
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From lorenzo at sancho.ccd.uniroma2.it  Thu Sep 18 11:08:29 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Thu, 18 Sep 2008 11:08:29 +0200 (CEST)
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>

Rainer,
 	I cloned your repo with

$ git clone http://git.adiscon.com/git/rsyslog.git rsyslog.git

now, I'm completely clueless about git, but I'm unable to find the 
helgrind branch with

$ git branch -r

I tried doing a git pull, but all I got was an "Already up-to-date." 
reply...

Should I simply wait for the helgrind branch to get merged into master, or 
there is some way to pull the new branch here?

Thank you very much, yours

 	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

On Thu, 18 Sep 2008, Rainer Gerhards wrote:

> Yes, looks like it works. This is what I did:
>
> http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123c
> 83383ba256c4e67679c8d
>
> Comments are appreciated.
>
> Rainer
>
>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
>> Sent: Thursday, September 18, 2008 10:35 AM
>> To: rsyslog-users
>> Subject: Re: [rsyslog] autoconf support for atomic operations
>>
>> Hold on... I should have searched first, then asked. Looks like I
> found
>> a solution. Will post more later.
>>
>> Rainer
>>
>>> -----Original Message-----
>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
>>> Sent: Thursday, September 18, 2008 10:15 AM
>>> To: rsyslog-users
>>> Subject: [rsyslog] autoconf support for atomic operations
>>>
>>> Hi all,
>>>
>>> in my effort to get a clean helgrind output (and to solve the
>> stability
>>> problems that recently showed up, I am going to re-enable support
> for
>>> atomic operations). Unfortunately, the following post is still
>> correct
>>> and I do not know how to use autotools to check for the ability of
>>> atomic operations:
>>>
>>> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
>>>
>>> While the post contains a potentially good pointer to a solution, I
>> do
>>> not know how to apply it to rsyslog ;) If anyone could lend me a
>>> helping
>>> hand, that would be great. In the meantime, I'll simply go and make
> a
>>> --enable-atomic ./configure switch - that's IMHO the best solution
>>> given
>>> the current state of affairs.
>>>
>>> Rainer
>>> _______________________________________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>

From rgerhards at hq.adiscon.com  Thu Sep 18 11:10:13 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 11:10:13 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F175@grfint2.intern.adiscon.com>

Hi Lorenzo,

I pushed the helgrind branch only a few minutes ago. It may be worth retrying

$ git pull
$ git branch -r

In any case, I expect that I merge the helgrind branch into master as soon as possible (which may mean quite a while, though).

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Lorenzo M. Catucci
> Sent: Thursday, September 18, 2008 11:08 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] autoconf support for atomic operations
> 
> Rainer,
>  	I cloned your repo with
> 
> $ git clone http://git.adiscon.com/git/rsyslog.git rsyslog.git
> 
> now, I'm completely clueless about git, but I'm unable to find the
> helgrind branch with
> 
> $ git branch -r
> 
> I tried doing a git pull, but all I got was an "Already up-to-date."
> reply...
> 
> Should I simply wait for the helgrind branch to get merged into master,
> or
> there is some way to pull the new branch here?
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+
> 
> On Thu, 18 Sep 2008, Rainer Gerhards wrote:
> 
> > Yes, looks like it works. This is what I did:
> >
> >
> http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123
> c
> > 83383ba256c4e67679c8d
> >
> > Comments are appreciated.
> >
> > Rainer
> >
> >> -----Original Message-----
> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >> Sent: Thursday, September 18, 2008 10:35 AM
> >> To: rsyslog-users
> >> Subject: Re: [rsyslog] autoconf support for atomic operations
> >>
> >> Hold on... I should have searched first, then asked. Looks like I
> > found
> >> a solution. Will post more later.
> >>
> >> Rainer
> >>
> >>> -----Original Message-----
> >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >>> Sent: Thursday, September 18, 2008 10:15 AM
> >>> To: rsyslog-users
> >>> Subject: [rsyslog] autoconf support for atomic operations
> >>>
> >>> Hi all,
> >>>
> >>> in my effort to get a clean helgrind output (and to solve the
> >> stability
> >>> problems that recently showed up, I am going to re-enable support
> > for
> >>> atomic operations). Unfortunately, the following post is still
> >> correct
> >>> and I do not know how to use autotools to check for the ability of
> >>> atomic operations:
> >>>
> >>> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> >>>
> >>> While the post contains a potentially good pointer to a solution, I
> >> do
> >>> not know how to apply it to rsyslog ;) If anyone could lend me a
> >>> helping
> >>> hand, that would be great. In the meantime, I'll simply go and make
> > a
> >>> --enable-atomic ./configure switch - that's IMHO the best solution
> >>> given
> >>> the current state of affairs.
> >>>
> >>> Rainer
> >>> _______________________________________________
> >>> rsyslog mailing list
> >>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> >


From rgerhards at hq.adiscon.com  Thu Sep 18 12:24:29 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 12:24:29 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
Message-ID: <1221733469.2682.146.camel@rgf9dev.intern.adiscon.com>

Lorenzo and all,

much quicker than I expected, I found one quirk that could - though very
unlikely - be at the root of all these problems. I have done a first
fix, which can be found here:

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=4c96ebdcfe075e80810b01257cf21ea1c9b3ec0e

I'd appreciate if you could pull the helgrind branch and see if
something changes. If you can't pull it for whatever reason, a snapshot
is available via the gitweb:

http://git.adiscon.com/?p=rsyslog.git;a=snapshot;h=4c96ebdcfe075e80810b01257cf21ea1c9b3ec0e;sf=tgz

Rainer

On Thu, 2008-09-18 at 11:08 +0200, Lorenzo M. Catucci wrote:
> Rainer,
>  	I cloned your repo with
> 
> $ git clone http://git.adiscon.com/git/rsyslog.git rsyslog.git
> 
> now, I'm completely clueless about git, but I'm unable to find the 
> helgrind branch with
> 
> $ git branch -r
> 
> I tried doing a git pull, but all I got was an "Already up-to-date." 
> reply...
> 
> Should I simply wait for the helgrind branch to get merged into master, or 
> there is some way to pull the new branch here?
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> 
> +-------------------------+----------------------------------------------+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
> +-------------------------+----------------------------------------------+
> 
> On Thu, 18 Sep 2008, Rainer Gerhards wrote:
> 
> > Yes, looks like it works. This is what I did:
> >
> > http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123c
> > 83383ba256c4e67679c8d
> >
> > Comments are appreciated.
> >
> > Rainer
> >
> >> -----Original Message-----
> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >> Sent: Thursday, September 18, 2008 10:35 AM
> >> To: rsyslog-users
> >> Subject: Re: [rsyslog] autoconf support for atomic operations
> >>
> >> Hold on... I should have searched first, then asked. Looks like I
> > found
> >> a solution. Will post more later.
> >>
> >> Rainer
> >>
> >>> -----Original Message-----
> >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >>> Sent: Thursday, September 18, 2008 10:15 AM
> >>> To: rsyslog-users
> >>> Subject: [rsyslog] autoconf support for atomic operations
> >>>
> >>> Hi all,
> >>>
> >>> in my effort to get a clean helgrind output (and to solve the
> >> stability
> >>> problems that recently showed up, I am going to re-enable support
> > for
> >>> atomic operations). Unfortunately, the following post is still
> >> correct
> >>> and I do not know how to use autotools to check for the ability of
> >>> atomic operations:
> >>>
> >>> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> >>>
> >>> While the post contains a potentially good pointer to a solution, I
> >> do
> >>> not know how to apply it to rsyslog ;) If anyone could lend me a
> >>> helping
> >>> hand, that would be great. In the meantime, I'll simply go and make
> > a
> >>> --enable-atomic ./configure switch - that's IMHO the best solution
> >>> given
> >>> the current state of affairs.
> >>>
> >>> Rainer
> >>> _______________________________________________
> >>> rsyslog mailing list
> >>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> >
> _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Thu Sep 18 12:55:23 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 12:55:23 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>

Please also read this:

http://kb.monitorware.com/post13847.html#p13847

It has some other interesting findings which leads me to believe I have
really found the culprit (or at least one of them ;)).

Feedback appreciated.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Thursday, September 18, 2008 9:35 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] abort cases
> 
> > Please let me know if I can help more, since
> > I'm somewhat in the hope this dreaded shared memory 8 way system
> could
> > very well shake the races... As a matter of fact, the destination
> server
> > is a twin-brother of the source one, and is running (and logging to
> > postgresql) without any hiccup since started-up.
> 
> Oh, I forgot, there is one thing you could actually do: I do not
intend
> to do any threading changes to the current stable. This may sound
> silly,
> because it looks like a bug, but I expect that a lot of changes need
to
> be done, especially to make helgrind happy (so that it can be used).
> The
> amount of changes I expect are far too intrusive for the stable. After
> all, the majority of folks do not experience the bug. So the "fix"
will
> become part of the current devel.
> 
> As such, it would be very useful for me if you could try out the
latest
> devel versions as I modify them. It would be really great if you could
> pull them from my git archive at git.adiscon.com/git/rsyslog.git
> 
> The same to everyone else interested in this work ;)
> 
> Rainer
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From r.bhatia at ipax.at  Thu Sep 18 13:46:28 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 18 Sep 2008 13:46:28 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
Message-ID: <48D23F94.9060904@ipax.at>

hi,

as i am quite frequently using gossamer-threads to search mailinglists
such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
could too move to gossamer-threads.

from the bottom of [1] i take:
> 
> Interested in having your list archived? Contact lists at gossamer-threads.com 
> 

rainer, any objections to sign up there?

cheers,
raoul

[1] http://www.gossamer-threads.com/lists
-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep 18 13:52:10 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 13:52:10 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <48D23F94.9060904@ipax.at>
References: <48D23F94.9060904@ipax.at>
Message-ID: <1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>

On Thu, 2008-09-18 at 13:46 +0200, Raoul Bhatia [IPAX] wrote:
> hi,
> 
> as i am quite frequently using gossamer-threads to search mailinglists
> such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
> could too move to gossamer-threads.

"move" implies that the current solution goes away... I hope that's
wrong understanding. I guess it is more like www.mail-archive.com, which
simply subscribes to the list, archives posts and indexes them.
> 
> from the bottom of [1] i take:
> > 
> > Interested in having your list archived? Contact lists at gossamer-threads.com 
> > 
> 
> rainer, any objections to sign up there?

If it is like mail-archive and I do not need to do anything than to say
"OK", that's fine with me. If it is more work, I quite honestly do not
see why I should want that ;)

Rainer
> 
> cheers,
> raoul
> 
> [1] http://www.gossamer-threads.com/lists



From r.bhatia at ipax.at  Thu Sep 18 13:54:40 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 18 Sep 2008 13:54:40 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>
References: <48D23F94.9060904@ipax.at>
	<1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>
Message-ID: <48D24180.7030409@ipax.at>

Rainer Gerhards wrote:
> On Thu, 2008-09-18 at 13:46 +0200, Raoul Bhatia [IPAX] wrote:
>> hi,
>>
>> as i am quite frequently using gossamer-threads to search mailinglists
>> such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
>> could too move to gossamer-threads.
> 
> "move" implies that the current solution goes away... I hope that's
> wrong understanding. I guess it is more like www.mail-archive.com, which
> simply subscribes to the list, archives posts and indexes them.
>> from the bottom of [1] i take:
>>> Interested in having your list archived? Contact lists at gossamer-threads.com 
>>>
>> rainer, any objections to sign up there?
> 
> If it is like mail-archive and I do not need to do anything than to say
> "OK", that's fine with me. If it is more work, I quite honestly do not
> see why I should want that ;)

to my understanding, it indeed is archiving only. and thats the sole
reason i suggested that. so let me rephrase it without the wrong term
"move":

i was wondering whether rsyslog could also be archived via
gossamer-threads.

;)

cheers,
raoul
-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep 18 13:58:05 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 13:58:05 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <48D24180.7030409@ipax.at>
References: <48D23F94.9060904@ipax.at><1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>
	<48D24180.7030409@ipax.at>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F177@grfint2.intern.adiscon.com>

Hi there,

it was suggested from users of the rsyslog project, that we have the
rsyslog mailing list added to Gossamer threads (see below). It is a
mailman mailing list hosted at 

http://lists.adiscon.net/mailman/listinfo/rsyslog

I was pointed to this mail address. Please let us know what needs to be
done or whatever information you may need.

Many thanks for looking into this.

Rainer Gerhards
rsyslog project admin

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX]
> Sent: Thursday, September 18, 2008 1:55 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] archiving rsyslog list via gossamer-threads
> 
> Rainer Gerhards wrote:
> > On Thu, 2008-09-18 at 13:46 +0200, Raoul Bhatia [IPAX] wrote:
> >> hi,
> >>
> >> as i am quite frequently using gossamer-threads to search
> mailinglists
> >> such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
> >> could too move to gossamer-threads.
> >
> > "move" implies that the current solution goes away... I hope that's
> > wrong understanding. I guess it is more like www.mail-archive.com,
> which
> > simply subscribes to the list, archives posts and indexes them.
> >> from the bottom of [1] i take:
> >>> Interested in having your list archived? Contact lists at gossamer-
> threads.com
> >>>
> >> rainer, any objections to sign up there?
> >
> > If it is like mail-archive and I do not need to do anything than to
> say
> > "OK", that's fine with me. If it is more work, I quite honestly do
> not
> > see why I should want that ;)
> 
> to my understanding, it indeed is archiving only. and thats the sole
> reason i suggested that. so let me rephrase it without the wrong term
> "move":
> 
> i was wondering whether rsyslog could also be archived via
> gossamer-threads.


From r.bhatia at ipax.at  Thu Sep 18 14:43:17 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 18 Sep 2008 14:43:17 +0200
Subject: [rsyslog] news and download link for 3.18.4
Message-ID: <48D24CE5.6030605@ipax.at>

hi,

somehow, i think that either something is messed up with the website
cms or that the news/download has not been altered yet.

	http://www.rsyslog.com/Downloads-index-req-viewdownload-cid-1-orderby-dateD.phtml
-> no download link

http://www.rsyslog.com/index.php?name=News -> no news.

cheers,
raoul
-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep 18 14:44:55 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 14:44:55 +0200
Subject: [rsyslog] news and download link for 3.18.4
In-Reply-To: <48D24CE5.6030605@ipax.at>
References: <48D24CE5.6030605@ipax.at>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F178@grfint2.intern.adiscon.com>

> somehow, i think that either something is messed up with the website
> cms or that the news/download has not been altered yet.
> 
> 	http://www.rsyslog.com/Downloads-index-req-viewdownload-cid-1-
> orderby-dateD.phtml
> -> no download link

This is the instable branch. I have to admit this is not well visible,
but there is a link to the stable releases on the top of that page, this
one:

http://www.rsyslog.com/Downloads-req-viewsdownload-sid-1.phtml

> http://www.rsyslog.com/index.php?name=News -> no news.

This, indeed, I have forgotten :) -- thx

Rainer


From lorenzo at sancho.ccd.uniroma2.it  Thu Sep 18 19:13:01 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Thu, 18 Sep 2008 19:13:01 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>

I just tried compiling and running the helgrind branch. To let configure 
finish its work, I've had to delete the PKG_CHECK_MODULES lines for RELP 
and LIBLOGGING.

Worst thing is that the daemon crashed once more; I'm enclosing the whole 
backtrace, that I've got via:

$ gdb /usr/sbin/rsyslogd /var/core-dumps/rsyslogd.core. > rsyslog_helgrind.bt << __eoc__
thread apply all bt
__eoc__

I don't know if the last line of failover.log could be of any help:

syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*) 
(pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.

Time for helgrind or valgrind?

Thank you, yours

 	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /usr/lib/rsyslog/lmnetstrms.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnetstrms.so
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/lmnsd_ptcp.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnsd_ptcp.so
Core was generated by `rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 2747]
[New process 2749]
[New process 2748]
[New process 2746]
[New process 2745]
#0  0x00002ad35493eef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 2745):
#0  0x00002ad3549d5f12 in select () from /lib/libc.so.6
#1  0x000000000040db33 in mainThread () at syslogd.c:2585
#2  0x000000000040ed0c in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:3483
#3  0x00002ad35492b1a6 in __libc_start_main () from /lib/libc.so.6
#4  0x0000000000409f79 in _start ()

Thread 4 (process 2746):
#0  0x00002ad3549c4d17 in sched_yield () from /lib/libc.so.6
#1  0x0000000000431844 in wtiWorker (pThis=0x685200) at wti.c:371
#2  0x00000000004301da in wtpWorker (arg=0x685200) at wtp.c:419
#3  0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 3 (process 2748):
#0  0x00002ad3549d5f12 in select () from /lib/libc.so.6
#1  0x00002ad35507b9dd in runInput (pThrd=<value optimized out>)
    at imuxsock.c:278
#2  0x0000000000441eef in thrdStarter (arg=0x6a6700) at ../threads.c:139
#3  0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 2 (process 2749):
#0  0x00002ad3542f07eb in read () from /lib/libpthread.so.0
#1  0x00002ad3552801bf in klogLogKMsg () at linux.c:449
#2  0x00002ad35527f554 in runInput (pThrd=0x6a7b90) at imklog.c:214
#3  0x0000000000441eef in thrdStarter (arg=0x6a7b90) at ../threads.c:139
#4  0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#5  0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (process 2747):
#0  0x00002ad35493eef5 in raise () from /lib/libc.so.6
#1  0x00002ad354940413 in abort () from /lib/libc.so.6
#2  0x0000000000422019 in sigsegvHdlr (signum=6) at debug.c:758
#3  <signal handler called>
#4  0x00002ad35493eef5 in raise () from /lib/libc.so.6
#5  0x00002ad354940413 in abort () from /lib/libc.so.6
#6  0x00002ad354937dc9 in __assert_fail () from /lib/libc.so.6
#7  0x000000000041bad6 in msgDestruct (ppThis=0x6905f8) at msg.c:274
#8  0x0000000000441824 in actionCallAction (pAction=0x690580, pMsg=0x6aeb70)
    at ../action.c:741
#9  0x000000000040afb7 in processMsgDoActions (pData=0x690580, 
    pParam=0x41000e90) at syslogd.c:1117
#10 0x000000000041c938 in llExecFunc (pThis=0x6903e0, 
    pFunc=0x40af60 <processMsgDoActions>, pParam=0x41000e90)
    at linkedlist.c:391
#11 0x000000000040ab19 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x6aeb70) at syslogd.c:1160
#12 0x000000000043ae97 in queueConsumerReg (pThis=0x690980, pWti=0x6a4600, 
    iCancelStateSave=<value optimized out>) at queue.c:1574
#13 0x0000000000431970 in wtiWorker (pThis=0x6a4600) at wti.c:413
#14 0x00000000004301da in wtpWorker (arg=0x6a4600) at wtp.c:419
#15 0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#16 0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#17 0x0000000000000000 in ?? ()
(gdb) quit

From rgerhards at hq.adiscon.com  Thu Sep 18 21:12:05 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 21:12:05 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <20080918114004.A0E4.80590B96@gossamer-threads.com>
References: <48D24180.7030409@ipax.at>
	<577465F99B41C842AAFBE9ED71E70ABA44F177@grfint2.intern.adiscon.com>
	<20080918114004.A0E4.80590B96@gossamer-threads.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F182@grfint2.intern.adiscon.com>

Hi Alex,

Thanks a lot for your fast and efficient help. Much appreciated.

Rainer 

> -----Original Message-----
> From: Alex Krohn [mailto:alex at gossamer-threads.com] 
> Sent: Thursday, September 18, 2008 8:42 PM
> To: Rainer Gerhards
> Subject: Re: [rsyslog] archiving rsyslog list via gossamer-threads
> 
> Hi Rainer,
> 
> > it was suggested from users of the rsyslog project, that we have the
> > rsyslog mailing list added to Gossamer threads (see below). It is a
> > mailman mailing list hosted at 
> > 
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > 
> > I was pointed to this mail address. Please let us know what 
> needs to be
> > done or whatever information you may need.
> 
> Sure, I've added it in:
> 
>     http://www.gossamer-threads.com/lists/rsyslog/users/
> 
> Please feel free to pass this on to the rsyslog list as I'm not
> subscribed. 
> 
> Cheers,
> 
> Alex
> 
> --
> Alex Krohn <alex at gossamer-threads.com>
> Gossamer Threads Inc. http://www.gossamer-threads.com/
> Tel: (604) 687-5804 Fax: (604) 687-5806
> 
> 


From rgerhards at hq.adiscon.com  Fri Sep 19 08:50:16 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 19 Sep 2008 08:50:16 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F186@grfint2.intern.adiscon.com>

> I don't know if the last line of failover.log could be of any help:
> 
> syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*)
> (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.
> 
Interesting...

> Time for helgrind or valgrind?

Could you run it in debug mode (-dn) and send me the log file? Maybe it
has some interesting findings in it.

On valgrind and helgrind: both is fine. If the problem is reproducible,
first run it under the memory checker and then the thread checker.
Helgrind will report a couple (20 or so) exceptions at the END of
program run, that is fine. Any other exception - in either of both - is
interesting and probably helpful.

Rainer


From rgerhards at hq.adiscon.com  Fri Sep 19 15:59:42 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 19 Sep 2008 15:59:42 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>

OK, I (thankfully) was able to see a potential race in my test environment that actually fits very well to the assert message you see. In my environment, it happens very (very!) seldom, even helgrind didn't notice until now. Please wait until I create a patch for it, I do NOT need any further info in the meantime.

Rainer

> -----Original Message-----
> From: Lorenzo M. Catucci [mailto:lorenzo at sancho.ccd.uniroma2.it]
> Sent: Thursday, September 18, 2008 7:13 PM
> To: Rainer Gerhards
> Cc: rsyslog-users
> Subject: Re: [rsyslog] abort cases
> 
> I just tried compiling and running the helgrind branch. To let
> configure
> finish its work, I've had to delete the PKG_CHECK_MODULES lines for
> RELP
> and LIBLOGGING.
> 
> Worst thing is that the daemon crashed once more; I'm enclosing the
> whole
> backtrace, that I've got via:
> 
> $ gdb /usr/sbin/rsyslogd /var/core-dumps/rsyslogd.core. >
> rsyslog_helgrind.bt << __eoc__
> thread apply all bt
> __eoc__
> 
> I don't know if the last line of failover.log could be of any help:
> 
> syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*)
> (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.
> 
> Time for helgrind or valgrind?
> 
> Thank you, yours
> 
>  	lorenzo
> 
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From rgerhards at hq.adiscon.com  Fri Sep 19 17:55:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 19 Sep 2008 17:55:14 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it><1221723317.2682.142.camel@rgf9dev.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F199@grfint2.intern.adiscon.com>

Lorenzo,

I would appreciate if you could run the latest code from "helgrind" branch. I have created one patch. It is probably not a 100% solution, but I won't manage to do much more today. And so it would be very helpful for me to know if something changes in your environment.

Thanks,
Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Friday, September 19, 2008 4:00 PM
> To: Lorenzo M. Catucci
> Cc: rsyslog-users
> Subject: Re: [rsyslog] abort cases
> 
> OK, I (thankfully) was able to see a potential race in my test
> environment that actually fits very well to the assert message you see.
> In my environment, it happens very (very!) seldom, even helgrind didn't
> notice until now. Please wait until I create a patch for it, I do NOT
> need any further info in the meantime.
> 
> Rainer
> 
> > -----Original Message-----
> > From: Lorenzo M. Catucci [mailto:lorenzo at sancho.ccd.uniroma2.it]
> > Sent: Thursday, September 18, 2008 7:13 PM
> > To: Rainer Gerhards
> > Cc: rsyslog-users
> > Subject: Re: [rsyslog] abort cases
> >
> > I just tried compiling and running the helgrind branch. To let
> > configure
> > finish its work, I've had to delete the PKG_CHECK_MODULES lines for
> > RELP
> > and LIBLOGGING.
> >
> > Worst thing is that the daemon crashed once more; I'm enclosing the
> > whole
> > backtrace, that I've got via:
> >
> > $ gdb /usr/sbin/rsyslogd /var/core-dumps/rsyslogd.core. >
> > rsyslog_helgrind.bt << __eoc__
> > thread apply all bt
> > __eoc__
> >
> > I don't know if the last line of failover.log could be of any help:
> >
> > syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*)
> > (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.
> >
> > Time for helgrind or valgrind?
> >
> > Thank you, yours
> >
> >  	lorenzo
> >
> >
> > +-------------------------+------------------------------------------
> --
> > --+
> > |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> > |
> > | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> > Vergata" |
> > |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> > ITALY |
> > |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> > |
> > +-------------------------+------------------------------------------
> --
> > --+
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From lorenzo at sancho.ccd.uniroma2.it  Fri Sep 19 23:37:31 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Fri, 19 Sep 2008 23:37:31 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F199@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it><1221723317.2682.142.camel@rgf9dev.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F199@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809192331410.19819@sancho.ccd.uniroma2.it>

As promised, I've just logged in to the server, to check if the daemon was 
still on. I found a 33M core dump; I'm enclosing the backtrace here.

Have a nice week-end,

 	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /usr/lib/rsyslog/lmnetstrms.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnetstrms.so
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/lmnsd_ptcp.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnsd_ptcp.so
Core was generated by `rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 31084]
[New process 31086]
[New process 31085]
[New process 31083]
[New process 31082]
#0  0x00002b67305cdef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 31082):
#0  0x00002b6730664f12 in select () from /lib/libc.so.6
#1  0x000000000040db33 in mainThread () at syslogd.c:2585
#2  0x000000000040ed0c in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:3483
#3  0x00002b67305ba1a6 in __libc_start_main () from /lib/libc.so.6
#4  0x0000000000409f79 in _start ()

Thread 4 (process 31083):
#0  0x00002b672ff7cfad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#1  0x0000000000431a13 in wtiWorker (pThis=0x685200) at wti.c:403
#2  0x00000000004301da in wtpWorker (arg=0x685200) at wtp.c:419
#3  0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b673066b7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 3 (process 31085):
#0  0x00002b6730664f12 in select () from /lib/libc.so.6
#1  0x00002b6730d0a9dd in runInput (pThrd=<value optimized out>)
    at imuxsock.c:278
#2  0x0000000000441eef in thrdStarter (arg=0x6a4830) at ../threads.c:139
#3  0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b673066b7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 2 (process 31086):
#0  0x00002b672ff7f7eb in read () from /lib/libpthread.so.0
#1  0x00002b6730f0f1bf in klogLogKMsg () at linux.c:449
#2  0x00002b6730f0e554 in runInput (pThrd=0x6a8340) at imklog.c:214
#3  0x0000000000441eef in thrdStarter (arg=0x6a8340) at ../threads.c:139
#4  0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#5  0x00002b673066b7cd in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (process 31084):
#0  0x00002b67305cdef5 in raise () from /lib/libc.so.6
#1  0x00002b67305cf413 in abort () from /lib/libc.so.6
#2  0x0000000000422019 in sigsegvHdlr (signum=6) at debug.c:758
#3  <signal handler called>
#4  0x00002b67305cdef5 in raise () from /lib/libc.so.6
#5  0x00002b67305cf413 in abort () from /lib/libc.so.6
#6  0x00002b67305c6dc9 in __assert_fail () from /lib/libc.so.6
#7  0x000000000041bad6 in msgDestruct (ppThis=0x68e728) at msg.c:274
#8  0x0000000000441824 in actionCallAction (pAction=0x68e6b0, 
    pMsg=0x2aaaac0014c0) at ../action.c:741
#9  0x000000000040afb7 in processMsgDoActions (pData=0x68e6b0, 
    pParam=0x41000e90) at syslogd.c:1117
#10 0x000000000041c938 in llExecFunc (pThis=0x68e510, 
    pFunc=0x40af60 <processMsgDoActions>, pParam=0x41000e90)
    at linkedlist.c:391
#11 0x000000000040ab19 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x2aaaac0014c0) at syslogd.c:1160
#12 0x000000000043ae97 in queueConsumerReg (pThis=0x68eab0, pWti=0x6a2730, 
    iCancelStateSave=<value optimized out>) at queue.c:1574
#13 0x0000000000431970 in wtiWorker (pThis=0x6a2730) at wti.c:413
#14 0x00000000004301da in wtpWorker (arg=0x6a2730) at wtp.c:419
#15 0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#16 0x00002b673066b7cd in clone () from /lib/libc.so.6
#17 0x0000000000000000 in ?? ()
(gdb) quit

From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 14:48:55 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 14:48:55 +0200 (CEST)
Subject: [rsyslog] problems with autoconf and configuration examples
Message-ID: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>

Last week, I referred in a very terse way to configure problems; to have 
configure finish its job, I have to remove both PKG_CHECK_MODULES from 
configure.ac:

  ./configure: line 26534: syntax error near unexpected token `RELP,'
  ./configure: line 26534: `      PKG_CHECK_MODULES(RELP, relp >= 0.1.1)'

and, after removing the RELP line group:

  ./configure: line 26560: syntax error near unexpected token `LIBLOGGING,'
  ./configure: line 26560: `      PKG_CHECK_MODULES(LIBLOGGING, liblogging >= 0.7.1)'

As for the configuration examples, I still find references to
$ActionExecOnlyIfPreviousIsSuspended both on-line and in the sample
section of ./doc/rsconf1_actionexeconlywhenpreviousissuspended.html.

If there is no way to keep the previous syntax running and spewing a
deprecation warning, please do correct all the google reachable
pages showing the wrong syntax... and add a note like
"in the past, rsyslogd supported the now removed syntax 
$ActionExecOnlyIfPreviousIsSuspended"

Thank you very much, yours

 	lorenzo


From rgerhards at hq.adiscon.com  Mon Sep 22 14:52:01 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 14:52:01 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
Message-ID: <1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>

Hi all,

On Mon, 2008-09-22 at 14:48 +0200, Lorenzo M. Catucci wrote:
> Last week, I referred in a very terse way to configure problems; to have 
> configure finish its job, I have to remove both PKG_CHECK_MODULES from 
> configure.ac:
> 
>   ./configure: line 26534: syntax error near unexpected token `RELP,'
>   ./configure: line 26534: `      PKG_CHECK_MODULES(RELP, relp >= 0.1.1)'
> 
> and, after removing the RELP line group:
> 
>   ./configure: line 26560: syntax error near unexpected token `LIBLOGGING,'
>   ./configure: line 26560: `      PKG_CHECK_MODULES(LIBLOGGING, liblogging >= 0.7.1)'
> 

I unfortunately have no idea what this problem may be caused by. Can
someone with a better understanding of autotools help out?

> As for the configuration examples, I still find references to
> $ActionExecOnlyIfPreviousIsSuspended both on-line and in the sample
> section of ./doc/rsconf1_actionexeconlywhenpreviousissuspended.html.
> 
> If there is no way to keep the previous syntax running and spewing a
> deprecation warning, please do correct all the google reachable
> pages showing the wrong syntax... and add a note like
> "in the past, rsyslogd supported the now removed syntax 
> $ActionExecOnlyIfPreviousIsSuspended"
> 

Sorry if I am missing the obvious here (I am probably ;)), but I do not
get what exactly you are refering to. Please elaborate a bit.

Thanks,
Rainer

> Thank you very much, yours
> 
>  	lorenzo
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From mbiebl at gmail.com  Mon Sep 22 14:55:00 2008
From: mbiebl at gmail.com (Michael Biebl)
Date: Mon, 22 Sep 2008 14:55:00 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
Message-ID: <aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>

2008/9/22 Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:
> Last week, I referred in a very terse way to configure problems; to have
> configure finish its job, I have to remove both PKG_CHECK_MODULES from
> configure.ac:
>
>  ./configure: line 26534: syntax error near unexpected token `RELP,'
>  ./configure: line 26534: `      PKG_CHECK_MODULES(RELP, relp >= 0.1.1)'
>
> and, after removing the RELP line group:
>
>  ./configure: line 26560: syntax error near unexpected token `LIBLOGGING,'
>  ./configure: line 26560: `      PKG_CHECK_MODULES(LIBLOGGING, liblogging >= 0.7.1)'

Please install the pkg-config package and re-run
autoreconf -vfi


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


From rgerhards at hq.adiscon.com  Mon Sep 22 15:02:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 15:02:14 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1A4@grfint2.intern.adiscon.com>

Me again ;)

I have done some further testing today. I begin to think that the issue
left is only related to HUPing rsyslogd. Can you confirm this? Do
problems happen before the first HUP is sent?

Thanks,
Rainer


From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 16:03:46 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 16:03:46 +0200 (CEST)
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0809221550120.1580@sancho.ccd.uniroma2.it>

On Mon, 22 Sep 2008, Michael Biebl wrote:

MB> 
MB> Please install the pkg-config package and re-run
MB> autoreconf -vfi
MB> 

Did do the trick; still, I'm unsure if the requirement for pkg-config is 
really justified just for two non-mandatory libraries.

Thank you very much, yours

	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 16:18:14 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 16:18:14 +0200 (CEST)
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809221607540.1580@sancho.ccd.uniroma2.it>

RG> 
RG> Sorry if I am missing the obvious here (I am probably ;)), but I do not
RG> get what exactly you are refering to. Please elaborate a bit.
RG> 
RG> 

The misleading documentation is available, both online at
  http://kb.monitorware.com/problem-in-failover-syslogserver-t8465.html
  http://wiki.rsyslog.com/index.php/FailoverSyslogServer 

There is a talk-back item for the wiki page at
  http://wiki.rsyslog.com/index.php/Talk:FailoverSyslogServer

Whats strange is that the same error is repeated at 
./doc/rsconf1_actionexeconlywhenpreviousissuspended.html  

and that the $ActionExecOnlyWhenPreviousIsSuspended is undocumented.


Thank you very much, yours,

	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From rgerhards at hq.adiscon.com  Mon Sep 22 16:32:45 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 16:32:45 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221607540.1580@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809221607540.1580@sancho.ccd.uniroma2.it>
Message-ID: <1222093965.2682.165.camel@rgf9dev.intern.adiscon.com>

Thanks for letting me know. It's fixed now.

Rainer

On Mon, 2008-09-22 at 16:18 +0200, Lorenzo M. Catucci wrote:
> RG> 
> RG> Sorry if I am missing the obvious here (I am probably ;)), but I do not
> RG> get what exactly you are refering to. Please elaborate a bit.
> RG> 
> RG> 
> 
> The misleading documentation is available, both online at
>   http://kb.monitorware.com/problem-in-failover-syslogserver-t8465.html
>   http://wiki.rsyslog.com/index.php/FailoverSyslogServer 
> 
> There is a talk-back item for the wiki page at
>   http://wiki.rsyslog.com/index.php/Talk:FailoverSyslogServer
> 
> Whats strange is that the same error is repeated at 
> ./doc/rsconf1_actionexeconlywhenpreviousissuspended.html  
> 
> and that the $ActionExecOnlyWhenPreviousIsSuspended is undocumented.
> 
> 
> Thank you very much, yours,
> 
> 	lorenzo
> 
> +-------------------------+----------------------------------------------+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
> +-------------------------+----------------------------------------------+
> _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep 22 16:42:51 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 16:42:51 +0200
Subject: [rsyslog] someone with experience in DejaGNU on this list?
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1A7@grfint2.intern.adiscon.com>

Hi,

I am looking for ways to improve the rsyslog test suites. I have written
a handful few via custom programs, but turning them into a full blow (or
at least somewhat sufficiently full blow ;)) test suite is far from
being trivial. I am looking for a suite that can be executed as part of
make distcheck and look at all the important things.

I know that there is DejaGNU out, which promises to ease creating
testsuites, but I have never used it. So before I invest any time in
looking at it, is there some wisdom about it, or another open source
testing tool, available on this list?

If you know something, please comment.

Thanks,
Rainer


From mbiebl at gmail.com  Mon Sep 22 17:00:02 2008
From: mbiebl at gmail.com (Michael Biebl)
Date: Mon, 22 Sep 2008 17:00:02 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221550120.1580@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>
	<alpine.DEB.1.10.0809221550120.1580@sancho.ccd.uniroma2.it>
Message-ID: <aa76cdac0809220800w18aab7fs4d9f7c3db819a303@mail.gmail.com>

2008/9/22 Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:
> On Mon, 22 Sep 2008, Michael Biebl wrote:
>
> MB>
> MB> Please install the pkg-config package and re-run
> MB> autoreconf -vfi
> MB>
>
> Did do the trick; still, I'm unsure if the requirement for pkg-config is
> really justified just for two non-mandatory libraries.
>
> Thank you very much, yours

pkg-config is *so* widely used nowadays, I was actually pretty
surprised you hadn't installed it by default.

Cheers,
Michael


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


From rgerhards at hq.adiscon.com  Mon Sep 22 17:23:41 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 17:23:41 +0200
Subject: [rsyslog] Another helgrind log
In-Reply-To: <alpine.DEB.1.10.0809221653340.2559@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221653340.2559@sancho.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1AE@grfint2.intern.adiscon.com>

Hi all,

just a quick wrap-up. Lorenzo sent me a couple of traces privately (on my request to keep the list free of the big attachments). I have reviewed them and I have to admit I am a bit puzzled by the traces. This just made me post a question on the valgrind mailing list. I hope to get some feedback from there soon.

Other than that, I have run a number of new tests today, during one I detected a problem inside imuxsock, but this one is probably unrelated as it isn't loaded. I will continue testing. Any more feedback is welcome. As soon as I have new news, I'll post.

Rainer

> This time I'm sure no HUP has been delivered to the daemon before
> helgrind
> did terminate it.
> 
> I'm restarting the "free-running" daemon and will wait till a SEGV
> comes
> to it.
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 17:30:18 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 17:30:18 +0200 (CEST)
Subject: [rsyslog] Another gdb backtrace
Message-ID: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>

Now I'm sure no HUP could have been deilivered to the daemon while 
running. This is a backtrace from a standard

$ rsyslogd -c3

run inside a screen session...

Thank you very much, yours

 	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /usr/lib/rsyslog/lmnetstrms.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnetstrms.so
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/lmnsd_ptcp.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnsd_ptcp.so
Core was generated by `rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 27165]
[New process 27167]
[New process 27166]
[New process 27164]
[New process 27163]
#0  0x00002b6f58c7fef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 27163):
#0  0x00002b6f58d16f12 in select () from /lib/libc.so.6
#1  0x000000000040db33 in mainThread () at syslogd.c:2585
#2  0x000000000040ed0c in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:3483
#3  0x00002b6f58c6c1a6 in __libc_start_main () from /lib/libc.so.6
#4  0x0000000000409f79 in _start ()

Thread 4 (process 27164):
#0  0x00002b6f5862efad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#1  0x0000000000431a13 in wtiWorker (pThis=0x685200) at wti.c:403
#2  0x00000000004301da in wtpWorker (arg=0x685200) at wtp.c:419
#3  0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 3 (process 27166):
#0  0x00002b6f58d16f12 in select () from /lib/libc.so.6
#1  0x00002b6f593bc9dd in runInput (pThrd=<value optimized out>)
    at imuxsock.c:278
#2  0x0000000000441eef in thrdStarter (arg=0x6a5b30) at ../threads.c:139
#3  0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 2 (process 27167):
#0  0x00002b6f586317eb in read () from /lib/libpthread.so.0
#1  0x00002b6f595c11bf in klogLogKMsg () at linux.c:449
#2  0x00002b6f595c0554 in runInput (pThrd=0x6a8c60) at imklog.c:214
#3  0x0000000000441eef in thrdStarter (arg=0x6a8c60) at ../threads.c:139
#4  0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#5  0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (process 27165):
#0  0x00002b6f58c7fef5 in raise () from /lib/libc.so.6
#1  0x00002b6f58c81413 in abort () from /lib/libc.so.6
#2  0x0000000000422019 in sigsegvHdlr (signum=6) at debug.c:758
#3  <signal handler called>
#4  0x00002b6f58c7fef5 in raise () from /lib/libc.so.6
#5  0x00002b6f58c81413 in abort () from /lib/libc.so.6
#6  0x00002b6f58c78dc9 in __assert_fail () from /lib/libc.so.6
#7  0x000000000041bad6 in msgDestruct (ppThis=0x68fa28) at msg.c:274
#8  0x0000000000441824 in actionCallAction (pAction=0x68f9b0, pMsg=0x6b1ce0)
    at ../action.c:741
#9  0x000000000040afb7 in processMsgDoActions (pData=0x68f9b0, 
    pParam=0x41000e90) at syslogd.c:1117
#10 0x000000000041c938 in llExecFunc (pThis=0x68e510, 
    pFunc=0x40af60 <processMsgDoActions>, pParam=0x41000e90)
    at linkedlist.c:391
#11 0x000000000040ab19 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x6b1ce0) at syslogd.c:1160
#12 0x000000000043ae97 in queueConsumerReg (pThis=0x68fdb0, pWti=0x6a3a30, 
    iCancelStateSave=<value optimized out>) at queue.c:1574
#13 0x0000000000431970 in wtiWorker (pThis=0x6a3a30) at wti.c:413
#14 0x00000000004301da in wtpWorker (arg=0x6a3a30) at wtp.c:419
#15 0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#16 0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#17 0x0000000000000000 in ?? ()
(gdb) quit

From rgerhards at hq.adiscon.com  Mon Sep 22 17:33:54 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 17:33:54 +0200
Subject: [rsyslog] Another gdb backtrace
In-Reply-To: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1B0@grfint2.intern.adiscon.com>

Just to double-check: does the abort happen

a) immediately
b) relatively soon after start
c) some time after start, probably late

I think it is b). Reason for question: I would eventually like to add some instrumentation, but that makes sense only if we do not need to wade through several GB of debug log...

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Lorenzo M. Catucci
> Sent: Monday, September 22, 2008 5:30 PM
> To: rsyslog-users
> Subject: [rsyslog] Another gdb backtrace
> 
> Now I'm sure no HUP could have been deilivered to the daemon while
> running. This is a backtrace from a standard
> 
> $ rsyslogd -c3
> 
> run inside a screen session...
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 17:52:43 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 17:52:43 +0200 (CEST)
Subject: [rsyslog] Another gdb backtrace
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1B0@grfint2.intern.adiscon.com>
References: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F1B0@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809221738520.2559@sancho.ccd.uniroma2.it>

On Mon, 22 Sep 2008, Rainer Gerhards wrote:

RG> Just to double-check: does the abort happen
RG> 
RG> a) immediately
RG> b) relatively soon after start
RG> c) some time after start, probably late
RG> 
RG> I think it is b). Reason for question: I would eventually like to add 
RG> some instrumentation, but that makes sense only if we do not need to 
RG> wade through several GB of debug log...
RG> 

The free-running doesn't survive more than a couple of hours; I still 
haven't tried a free-running with -dn appended; let me know if you'd 
prefer for me to try starting the daemon now, or if it's better if 
I wait for some more commits.

As for testing, in as much as I understand, to reproduce the problem we 
are going after there would be a need for a load-test harness, and some 
patience, since, in my case, the "writer" server does work without any 
problem, and the crashes do happen on one of my loaded mail gateways, 
which get some thousand messages per hour, and do antispam and antivirus 
work, with sendmail, mailscanner and clamav each spewing a lot of messages 
to filter and dispose of.

See you later, yours

	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From aoz.syn at gmail.com  Tue Sep 23 05:31:29 2008
From: aoz.syn at gmail.com (RB)
Date: Mon, 22 Sep 2008 21:31:29 -0600
Subject: [rsyslog] RPM spec file
Message-ID: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>

I was building a virtual host the other day and noticed only
rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
rather disappointed and immediately whipped up something based on the
2.0.0 specfile.

Attached is a spec file for 3.21.4, but should be usable for most of
the 3.x series.  YMMV, this has not been tested too terribly much.
I'd appreciate a callback if anyone uses it or has a problem - I've
done plenty of packaging, just not for RPM-based distros.


RB

From rgerhards at hq.adiscon.com  Tue Sep 23 08:54:55 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 08:54:55 +0200
Subject: [rsyslog] cisco router config and plain TCP syslog
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>

Hi list,

is there someone on the list successfully using plain TCP syslog
logging? I have one problem case inside the forum where the router does
not properly terminate messages with LF, the required framing:

http://kb.monitorware.com/tcp-syslog-fill-s-up-buffer-and-doesn-t-log-si
ngle-events-t8705.html

I am not an IOS guy, so I would appreciate if someone could drop me the
right configuration for the routers. Actually, I wonder that they do not
seem to do that by default. As far as I remember, this has never been an
issue. I have limited personal experience with PIX, which terminated
messages correct by default.

Any pointer would be appreciated,
Rainer


From rgerhards at hq.adiscon.com  Tue Sep 23 10:31:59 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 10:31:59 +0200
Subject: [rsyslog] FW: [Valgrind-users] helgrind points to race in
	pthread_mutex_lock?
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1B9@grfint2.intern.adiscon.com>

Hi all,

An update on the abort case bug.

Below is one of the responses I got from the valgrind mailing list about
my inquiry. In short, the helgrind log I received seems not to be
absolutely correct and thus is unfortunately of very limited use for
troubleshooting.

There are new versions out and I will ask Lorenzo if it is possible to
run one of those. I'll do that via private mail as I need to forward
some more messages (unfortunately the valgrind mailing list archive
lacks behind several days, so I can not yet refer to the archive...).

Rainer

> ---------- Forwarded message ----------
> From: Julian Seward < >
> Date: Mon, Sep 22, 2008 at 8:54 PM
> Subject: Re: [Valgrind-users] helgrind points to race in
> pthread_mutex_lock?
> To: valgrind-users at lists.sourceforge.net
> Cc: Konstantin Serebryany < >, Rainer
> Gerhards < m>
> 
> 
> 
> On Monday 22 September 2008, Konstantin Serebryany wrote:
> 
> > helgrind is under active development now in two separate branches
> > (HGDEV & YARD).
> > The version in trunk is outdated. Please try YARD first:
> > svn co svn://svn.valgrind.org/valgrind/branches/YARD YARD
> 
> Yes, do try YARD; you might like it more than the 3.3.1 helgrind.
> 
> Nevertheless, the error you show:
> 
> > > ==31831== Possible data race during read of size 4 at 0x6622E8
> > > ==31831==    at 0x50464FE: pthread_mutex_lock
> (pthread_mutex_lock.c:87)
> > > ==31831==    by 0x4C2217B: pthread_mutex_lock
(hg_intercepts.c:400)
> > > ==31831==    by 0x420AFC: dbgGetThrdInfo (debug.c:604)
> > [...]
> 
> should have been suppressed, so you should not see it.  It is due to
an
> internal implementation limitation which is hard to avoid, so in some
> cases we suppress errors which we know cannot be from end-user code.
> 
> I think the relevant suppression in glibc-2.34567-NPTL-helgrind.supp
> is:
> 
>  {
>     helgrind-glibc25-101
>     Helgrind:Race
>     obj:/lib*/libpthread-2.5.*so
>     fun:pthread_*
>  }
> 
> (or corresponding other versions for glibc > 2.5, in the same file)
> 
> One possible reason it did not suppress the error is that you have
> debug information on/for your libpthread, which is an unusual setup
> that
> Helgrind has not been properly tested against.
> 
> But I am not 100% sure about that.
> 
> * if you uninstall the libc debuginfo rpm/deb, does that change
> anything?
> 
> * what glibc version are you using?
> 
> J


From mic at npgx.com.au  Tue Sep 23 11:07:02 2008
From: mic at npgx.com.au (Michael Mansour)
Date: Tue, 23 Sep 2008 20:07:02 +1100
Subject: [rsyslog] RPM spec file
In-Reply-To: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
Message-ID: <20080923090507.M89321@npgx.com.au>

Hi,

> I was building a virtual host the other day and noticed only
> rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> rather disappointed and immediately whipped up something based on the
> 2.0.0 specfile.
> 
> Attached is a spec file for 3.21.4, but should be usable for most of
> the 3.x series.  YMMV, this has not been tested too terribly much.
> I'd appreciate a callback if anyone uses it or has a problem - I've
> done plenty of packaging, just not for RPM-based distros.

I'd love to test this so could you attach the spec or make it available?

I published mine in the rsyslog wiki.

Thanks.

Michael.

> RB
------- End of Original Message -------



From rgerhards at hq.adiscon.com  Tue Sep 23 11:24:05 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 11:24:05 +0200
Subject: [rsyslog] RPM spec file
In-Reply-To: <20080923090507.M89321@npgx.com.au>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<20080923090507.M89321@npgx.com.au>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1BF@grfint2.intern.adiscon.com>

[listadmin speaking]
Ah, I didn't notice. The list processor removes almost all attachments
in order to keep message sizes reasonable and block spread of viruses
should such files be able to go past the first line of defense. Sorry
for the inconvenience this causes...

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Michael Mansour
> Sent: Tuesday, September 23, 2008 11:07 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] RPM spec file
> 
> Hi,
> 
> > I was building a virtual host the other day and noticed only
> > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > rather disappointed and immediately whipped up something based on
the
> > 2.0.0 specfile.
> >
> > Attached is a spec file for 3.21.4, but should be usable for most of
> > the 3.x series.  YMMV, this has not been tested too terribly much.
> > I'd appreciate a callback if anyone uses it or has a problem - I've
> > done plenty of packaging, just not for RPM-based distros.
> 
> I'd love to test this so could you attach the spec or make it
> available?
> 
> I published mine in the rsyslog wiki.
> 
> Thanks.
> 
> Michael.
> 
> > RB
> ------- End of Original Message -------
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From mic at npgx.com.au  Tue Sep 23 12:16:41 2008
From: mic at npgx.com.au (Michael Mansour)
Date: Tue, 23 Sep 2008 21:16:41 +1100
Subject: [rsyslog] [Spam?DateIssue] Re:  RPM spec file
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1BF@grfint2.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<20080923090507.M89321@npgx.com.au>
	<577465F99B41C842AAFBE9ED71E70ABA44F1BF@grfint2.intern.adiscon.com>
Message-ID: <20080923101451.M62228@npgx.com.au>

> [listadmin speaking]
> Ah, I didn't notice. The list processor removes almost all 
> attachments in order to keep message sizes reasonable and block 
> spread of viruses should such files be able to go past the first 
> line of defense. Sorry for the inconvenience this causes...

RB, if you cannot post this to the list could you email it to me directly please?

I'm happy to update the rsyslog wiki page with it so others can download also.

Michael.

> Rainer
> 
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Michael Mansour
> > Sent: Tuesday, September 23, 2008 11:07 AM
> > To: rsyslog-users
> > Subject: Re: [rsyslog] RPM spec file
> > 
> > Hi,
> > 
> > > I was building a virtual host the other day and noticed only
> > > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > > rather disappointed and immediately whipped up something based on
> the
> > > 2.0.0 specfile.
> > >
> > > Attached is a spec file for 3.21.4, but should be usable for most of
> > > the 3.x series.  YMMV, this has not been tested too terribly much.
> > > I'd appreciate a callback if anyone uses it or has a problem - I've
> > > done plenty of packaging, just not for RPM-based distros.
> > 
> > I'd love to test this so could you attach the spec or make it
> > available?
> > 
> > I published mine in the rsyslog wiki.
> > 
> > Thanks.
> > 
> > Michael.
> > 
> > > RB
> > ------- End of Original Message -------
> > 
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
------- End of Original Message -------



From rgerhards at hq.adiscon.com  Tue Sep 23 12:51:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 12:51:14 +0200
Subject: [rsyslog] RPM spec file
In-Reply-To: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>

[oops, forgotten to hit "send" - now a bit outdated, but still useful...]

Hi RB,

I really appreciate the spec file ... but it also creates a bit of a problem for me ;) Let me elaborate: I have stayed away from doing spec files, mostly because I can not ensure they are kept up to date. For that reason, nothing distro-specific is included in the "official source distribution".

If I now include the spec, it may outdate over time plus people come and ask how to work with it, getting us probably down to distro-specific things. I am not sure we want this (or do we want it - I am open to change if there are folks in the community who can commit to support these things [aka "I can not" ;)].

Or is there any other place where such things could be placed (external RPM repositories come to my mind)? I would be more than happy to link to the relevant places.

Again, I really value the contribution, I just do not know how to handle it best.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of RB
> Sent: Tuesday, September 23, 2008 5:31 AM
> To: rsyslog at lists.adiscon.com
> Subject: [rsyslog] RPM spec file
> 
> I was building a virtual host the other day and noticed only
> rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> rather disappointed and immediately whipped up something based on the
> 2.0.0 specfile.
> 
> Attached is a spec file for 3.21.4, but should be usable for most of
> the 3.x series.  YMMV, this has not been tested too terribly much.
> I'd appreciate a callback if anyone uses it or has a problem - I've
> done plenty of packaging, just not for RPM-based distros.
> 
> 
> RB

From mic at npgx.com.au  Tue Sep 23 13:16:00 2008
From: mic at npgx.com.au (Michael Mansour)
Date: Tue, 23 Sep 2008 22:16:00 +1100
Subject: [rsyslog] [Spam?DateIssue] Re:  RPM spec file
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
Message-ID: <20080923110101.M79951@npgx.com.au>

Hi Rainer,

> [oops, forgotten to hit "send" - now a bit outdated, but still useful...]
> 
> Hi RB,
> 
> I really appreciate the spec file ... but it also creates a bit of a 
> problem for me ;) Let me elaborate: I have stayed away from doing 
> spec files, mostly because I can not ensure they are kept up to 
> date. For that reason, nothing distro-specific is included in the 
> "official source distribution".
> 
> If I now include the spec, it may outdate over time plus people come 
> and ask how to work with it, getting us probably down to distro-
> specific things. I am not sure we want this (or do we want it - I am 
> open to change if there are folks in the community who can commit to 
> support these things [aka "I can not" ;)].
> 
> Or is there any other place where such things could be placed 
> (external RPM repositories come to my mind)? I would be more than 
> happy to link to the relevant places.
> 
> Again, I really value the contribution, I just do not know how to 
> handle it best.

My first introduction to rsyslog was via the Dries repository (now part of
RPMforge):

http://dries.ulyssis.org/rpm/packages/rsyslog/info.html

RPMforge have thousands of packages that are maintained for Red Hat based servers.

The problem is, I've asked both Dag and Dries for updated rsyslog versions for
months and they've never replied. I don't know why and they usually reply, but
sometimes they just don't. 

This is why I build my own RPM's on my (and clients) server and why I made my
spec files available on the rsyslog wiki here:

http://wiki.rsyslog.com/index.php/Here_comes_the_first_story

I also provided them for download on my ftp server.

I have since made spec files for 3.18.0-1 but haven't updated since then,
primarily because of lack of time, and haven't updated the wiki with those
updated specs. However I am happy to do this if BR can give me his one, I'll
see if there's anything that's changed first thing.

The other to note, I rarely install anything from source into production
environments. I try to always leave things packaged or I make the specs and
package them myself. 

rpm/deb/etc are just easier to manage, query, update, remove, verify, etc than
from source.

You're not of the minority when packaging for distributions, many developers
don't do it but at the same time, many developers also do. I know one
developer who uses another software package to take his source tarball and
create packages from it for all distro's (deb's, rpm's, tarp's, etc).

But I understand this isn't an argument of whether you should have packages or
not, after all Red Hat will eventually have rsyslog in RPM (but not for
updated versions from you, only what they release and backport fixes for).

So this really comes down to you not being able to so someone/some people just
have to stand up and take responsibility for packaging it. The user/admin
community definately wants it, a web search for the terms "rsyslog repo" or
"rsyslog rpm" will quickly show you this.

Regards,

Michael.

> Rainer
> 
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of RB
> > Sent: Tuesday, September 23, 2008 5:31 AM
> > To: rsyslog at lists.adiscon.com
> > Subject: [rsyslog] RPM spec file
> > 
> > I was building a virtual host the other day and noticed only
> > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > rather disappointed and immediately whipped up something based on the
> > 2.0.0 specfile.
> > 
> > Attached is a spec file for 3.21.4, but should be usable for most of
> > the 3.x series.  YMMV, this has not been tested too terribly much.
> > I'd appreciate a callback if anyone uses it or has a problem - I've
> > done plenty of packaging, just not for RPM-based distros.
> > 
> > 
> > RB
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
------- End of Original Message -------



From aoz.syn at gmail.com  Tue Sep 23 14:11:38 2008
From: aoz.syn at gmail.com (RB)
Date: Tue, 23 Sep 2008 06:11:38 -0600
Subject: [rsyslog] RPM spec file
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
Message-ID: <4255c2570809230511n3453e09ao8caddc895d8cf925@mail.gmail.com>

> I really appreciate the spec file ... but it also creates a bit of a problem for me ;) Let me elaborate: I have stayed away from doing spec files, mostly because I can not ensure they are kept up to date. For that reason, nothing distro-specific is included in the "official source distribution".

Understood; my posting was more for posterity than expecting you to
include it in your distribution.  People looking for a package can
find it now and do with it as they please.  Well, they could if
attachments were allowed through...  :)  My email to Michael should
help that.

> If I now include the spec, it may outdate over time plus people come and ask how to work with it, getting us probably down to distro-specific things. I am not sure we want this (or do we want it - I am open to change if there are folks in the community who can commit to support these things [aka "I can not" ;)].

As a small-time packager, I have to thank you for trying to remain
distro-agnostic.  Few things are more frustrating than trying to
unravel some developer's flavor-specific compile+install+kitchen_sink
script just to get a piece of software packaged for mine.  Much thanks
for staying with the standard autotools approach and letting the
distros sort out how they want to install your software.


RB


From rgerhards at hq.adiscon.com  Tue Sep 23 14:39:03 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 14:39:03 +0200
Subject: [rsyslog] [Spam?DateIssue] Re:  RPM spec file
In-Reply-To: <20080923110101.M79951@npgx.com.au>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<20080923110101.M79951@npgx.com.au>
Message-ID: <1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>

Hi Michael,

great post. Let us see where we come from here...

I know very well that people like to install from packages - actually, I
am one of them ;) So while I try do keep distro-agnostic (thanks RB for
the good words ;)), I would love to see rsyslog packages for all major
distros and and of course for all versions of rsyslog.

Unfortunately, both my knowledge and time is limited. Knowledge can be
expanded, but that takes time, so we are probably down to the "time
limit" problem - which is hard to overcome. I am not justifying me (why
should I?) nor bashing someone (again, why should I?;)) I am just
stating plain, unfortunate facts.

So I need to do a compromise. That currently is that I stay away from
distro-specific things, even in areas where I could join without making
rsyslog distro-specific. Thankfully, people like you, RB, Michael Biebl,
Infofarmer and some more whom I regrettably have not mentioned now join
in and help create great distro-specific things.

But ... sometimes these things are hard to find. The wiki was the first
approach to permit user-created context in an easy to spot and easy to
edit place. The wiki gets around 100 visitors each day and while this is
obviously not a big number, it is one that is constantly growing. So I
think the wiki was a good thing to have (which is also proven by the
fact that we attracted a number of articles).

The mailing list and forum are also good examples. I often do not need
to reply because someone of you did a much better job offering a
solution than I could have done. Excellent.

What is missing is a place to provide things like the rpm package RB
offered. Specific files and such. A quick solution could be that I
collect such material and place it, without any guarantee and whatsoever
support from me, onto the rsyslog download server and offer that
directory as a free resource to the community. That would at least
ensure that there is a single spot where things can be found by anyone
who searches.

Would this make sense? Any more ideas?

Thanks,
Rainer

On Tue, 2008-09-23 at 22:16 +1100, Michael Mansour wrote:
> Hi Rainer,
> 
> > [oops, forgotten to hit "send" - now a bit outdated, but still useful...]
> > 
> > Hi RB,
> > 
> > I really appreciate the spec file ... but it also creates a bit of a 
> > problem for me ;) Let me elaborate: I have stayed away from doing 
> > spec files, mostly because I can not ensure they are kept up to 
> > date. For that reason, nothing distro-specific is included in the 
> > "official source distribution".
> > 
> > If I now include the spec, it may outdate over time plus people come 
> > and ask how to work with it, getting us probably down to distro-
> > specific things. I am not sure we want this (or do we want it - I am 
> > open to change if there are folks in the community who can commit to 
> > support these things [aka "I can not" ;)].
> > 
> > Or is there any other place where such things could be placed 
> > (external RPM repositories come to my mind)? I would be more than 
> > happy to link to the relevant places.
> > 
> > Again, I really value the contribution, I just do not know how to 
> > handle it best.
> 
> My first introduction to rsyslog was via the Dries repository (now part of
> RPMforge):
> 
> http://dries.ulyssis.org/rpm/packages/rsyslog/info.html
> 
> RPMforge have thousands of packages that are maintained for Red Hat based servers.
> 
> The problem is, I've asked both Dag and Dries for updated rsyslog versions for
> months and they've never replied. I don't know why and they usually reply, but
> sometimes they just don't. 
> 
> This is why I build my own RPM's on my (and clients) server and why I made my
> spec files available on the rsyslog wiki here:
> 
> http://wiki.rsyslog.com/index.php/Here_comes_the_first_story
> 
> I also provided them for download on my ftp server.
> 
> I have since made spec files for 3.18.0-1 but haven't updated since then,
> primarily because of lack of time, and haven't updated the wiki with those
> updated specs. However I am happy to do this if BR can give me his one, I'll
> see if there's anything that's changed first thing.
> 
> The other to note, I rarely install anything from source into production
> environments. I try to always leave things packaged or I make the specs and
> package them myself. 
> 
> rpm/deb/etc are just easier to manage, query, update, remove, verify, etc than
> from source.
> 
> You're not of the minority when packaging for distributions, many developers
> don't do it but at the same time, many developers also do. I know one
> developer who uses another software package to take his source tarball and
> create packages from it for all distro's (deb's, rpm's, tarp's, etc).
> 
> But I understand this isn't an argument of whether you should have packages or
> not, after all Red Hat will eventually have rsyslog in RPM (but not for
> updated versions from you, only what they release and backport fixes for).
> 
> So this really comes down to you not being able to so someone/some people just
> have to stand up and take responsibility for packaging it. The user/admin
> community definately wants it, a web search for the terms "rsyslog repo" or
> "rsyslog rpm" will quickly show you this.
> 
> Regards,
> 
> Michael.
> 
> > Rainer
> > 
> > > -----Original Message-----
> > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > > bounces at lists.adiscon.com] On Behalf Of RB
> > > Sent: Tuesday, September 23, 2008 5:31 AM
> > > To: rsyslog at lists.adiscon.com
> > > Subject: [rsyslog] RPM spec file
> > > 
> > > I was building a virtual host the other day and noticed only
> > > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > > rather disappointed and immediately whipped up something based on the
> > > 2.0.0 specfile.
> > > 
> > > Attached is a spec file for 3.21.4, but should be usable for most of
> > > the 3.x series.  YMMV, this has not been tested too terribly much.
> > > I'd appreciate a callback if anyone uses it or has a problem - I've
> > > done plenty of packaging, just not for RPM-based distros.
> > > 
> > > 
> > > RB
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> ------- End of Original Message -------
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Tue Sep 23 14:44:37 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 14:44:37 +0200
Subject: [rsyslog] abort case
In-Reply-To: <dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com>
References: <dc67eef70809220810s1815ff2evce41b096484eb644@mail.gmail.com>
	<59e975c10809221126o37d8919w674f13aee5acc16f@mail.gmail.com>
	<dc67eef70809230133v696f6145r94044ccb30c9cbdc@mail.gmail.com>
	<alpine.DEB.1.10.0809231355450.18598@sancho.ccd.uniroma2.it>
	<dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com>
Message-ID: <1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>

Lorenzo,

I have done a change to the message handler, it is now using an atomic
memory access operation where it previously did not. I have just pushed
that change as part of the helgrind branch.

I would appreciate if you could give it a try and send me (via private
mail) a helgrind log. 

I don't think that this change is sufficient to resolve the issue. But I
would like to take a granular approach so that I can be sure to find the
real root cause.

Thanks,
Rainer

On Tue, 2008-09-23 at 14:04 +0200, Rainer Gerhards wrote:
> ---------- Forwarded message ----------
> From: Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>
> Date: Tue, Sep 23, 2008 at 2:00 PM
> Subject: Re: Fwd: [Valgrind-users] helgrind points to race in
> pthread_mutex_lock?
> To: Rainer Gerhards <rgerhards at gmail.com>
> 
> RG> Lorenzo,
> RG>
> RG> any chance you could do what is described below? (I guess "no", but I
> RG> thought I ask ;)).
> RG>
> 
> It's running! I didn't recompile, since I didn't find anything new within
> the helgrind branch.
> 
> I'm enclosing the very first "race" message, let me know if this does seem
> better.
> 
> Thank you, and keep on course. Yours,
> 
>        lorenzo




From lorenzo at sancho.ccd.uniroma2.it  Tue Sep 23 15:08:34 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Tue, 23 Sep 2008 15:08:34 +0200 (CEST)
Subject: [rsyslog] abort case
In-Reply-To: <1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>
References: <dc67eef70809220810s1815ff2evce41b096484eb644@mail.gmail.com>
	<59e975c10809221126o37d8919w674f13aee5acc16f@mail.gmail.com>
	<dc67eef70809230133v696f6145r94044ccb30c9cbdc@mail.gmail.com>
	<alpine.DEB.1.10.0809231355450.18598@sancho.ccd.uniroma2.it>
	<dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com>
	<1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809231454200.18598@sancho.ccd.uniroma2.it>

On Tue, 23 Sep 2008, Rainer Gerhards wrote:

RG> Lorenzo,
RG> 
RG> I have done a change to the message handler, it is now using an atomic
RG> memory access operation where it previously did not. I have just pushed
RG> that change as part of the helgrind branch.
RG> 

Recompiled/reinstalled/restarted. make did recompile msg.c, I don't know 
why rsyslogd didn't get relinked, but I forced relink by removing rsyslogd 
from tools. 

This time, the server crashed even though it was being helground...

Find enclosed the full debug log.

Yours,

	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From rgerhards at hq.adiscon.com  Tue Sep 23 15:18:18 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 15:18:18 +0200
Subject: [rsyslog] RPM spec file
In-Reply-To: <4255c2570809230511n3453e09ao8caddc895d8cf925@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<4255c2570809230511n3453e09ao8caddc895d8cf925@mail.gmail.com>
Message-ID: <1222175898.2682.190.camel@rgf9dev.intern.adiscon.com>

> script just to get a piece of software packaged for mine.  Much thanks
> for staying with the standard autotools approach and letting the
> distros sort out how they want to install your software.

Praise should go to Peter Vrabec and Michael Biebl, which convinced me
of autotools and also greatly helped me setting things up in a useful
way ;)

Rainer



From aoz.syn at gmail.com  Tue Sep 23 15:53:42 2008
From: aoz.syn at gmail.com (RB)
Date: Tue, 23 Sep 2008 07:53:42 -0600
Subject: [rsyslog] [Spam?DateIssue] Re: RPM spec file
In-Reply-To: <1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<20080923110101.M79951@npgx.com.au>
	<1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>
Message-ID: <4255c2570809230653x3ec19b68mad9fea2da8ceb5f6@mail.gmail.com>

> What is missing is a place to provide things like the rpm package RB
> offered. Specific files and such. A quick solution could be that I
> collect such material and place it, without any guarantee and whatsoever
> support from me, onto the rsyslog download server and offer that
> directory as a free resource to the community. That would at least
> ensure that there is a single spot where things can be found by anyone
> who searches.

Sounds like you need a contrib/ directory, either on your download
server or included in the releases (or both - releases could include a
snapshot).  Linking them from explanatory pages in the wiki will only
serve to help search ranks and generally make everyone happy.  They
should come with (as you said) a disclaimer that best-effort support
may be had on the lists/forums, but that they are unofficial and
therefore not warranted or supported directly by Adiscon.

An alternative would be to allow specific users to upload attachments
to the wiki and link them from a semi-protected page; not as efficient
or as easy to moderate/aggregate, but it would certainly be more
instantaneous.  The 'maintainer' of the given file should additionally
link to instructions on using the package.

Once a sane package is created, most packaging systems make scripted
updates rather easy - use sed to update version numbers/checksums, and
it's good to go.  Gentoo's so easy, all you have to do is re-name the
package file.  Only when major functionality changes (added binaries,
configuration options, etc.) should one have to non-trivially touch
the package.  On that note, the spec file I provided only covers
limited rsyslog functionality - GSSAPI, rfc3195, RELP, and the
debugging tools were all left off simply because I didn't have the
time to build/package their prerequisites.

One last bit: coming from the Gentoo mentality, I'm less interested in
binary packages and far more in the meta-files used to generate those.
 Others may differ, but that may help the bitrot concern.


From aoz.syn at gmail.com  Tue Sep 23 17:13:59 2008
From: aoz.syn at gmail.com (RB)
Date: Tue, 23 Sep 2008 09:13:59 -0600
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
Message-ID: <4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>

> http://kb.monitorware.com/tcp-syslog-fill-s-up-buffer-and-doesn-t-log-single-events-t8705.html

It would seem they're using some version of IOS 12.3 or 12.4; the
'transport X' predicate was introduced some time in the prior but not
documented until the latter.  It would be good to know precisely what
version they are running for reference anyway.

For all I can tell (not having set up a test env myself), it would
seem that just because one indicates TCP as the transport, the
underlying engine doesn't change its semantics and remains at the
UDP-esque 'one packet per message'.  For that matter, I see references
specifically to RFC3164 as opposed to 3195.  Leave it to Cisco...

> I am not an IOS guy, so I would appreciate if someone could drop me the
> right configuration for the routers. Actually, I wonder that they do not
> seem to do that by default. As far as I remember, this has never been an
> issue. I have limited personal experience with PIX, which terminated
> messages correct by default.
:)  My primary experience is with PIX as well.  Looks like the two
primary options are to use 'transport beep' [1] (Cisco's reference to
RFC3195) or to use an ESM filter [2] to add newlines.

[1] http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a00807883c3.html
[2] http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gt_esm.html


From david at lang.hm  Tue Sep 23 17:43:55 2008
From: david at lang.hm (david at lang.hm)
Date: Tue, 23 Sep 2008 08:43:55 -0700 (PDT)
Subject: [rsyslog] [Spam?DateIssue] Re: RPM spec file
In-Reply-To: <4255c2570809230653x3ec19b68mad9fea2da8ceb5f6@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<20080923110101.M79951@npgx.com.au>
	<1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>
	<4255c2570809230653x3ec19b68mad9fea2da8ceb5f6@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0809230840140.31560@asgard.lang.hm>

On Tue, 23 Sep 2008, RB wrote:

>> What is missing is a place to provide things like the rpm package RB
>> offered. Specific files and such. A quick solution could be that I
>> collect such material and place it, without any guarantee and whatsoever
>> support from me, onto the rsyslog download server and offer that
>> directory as a free resource to the community. That would at least
>> ensure that there is a single spot where things can be found by anyone
>> who searches.
>
> Sounds like you need a contrib/ directory, either on your download
> server or included in the releases (or both - releases could include a
> snapshot).  Linking them from explanatory pages in the wiki will only
> serve to help search ranks and generally make everyone happy.  They
> should come with (as you said) a disclaimer that best-effort support
> may be had on the lists/forums, but that they are unofficial and
> therefore not warranted or supported directly by Adiscon.
>
> An alternative would be to allow specific users to upload attachments
> to the wiki and link them from a semi-protected page; not as efficient
> or as easy to moderate/aggregate, but it would certainly be more
> instantaneous.  The 'maintainer' of the given file should additionally
> link to instructions on using the package.
>
> Once a sane package is created, most packaging systems make scripted
> updates rather easy - use sed to update version numbers/checksums, and
> it's good to go.  Gentoo's so easy, all you have to do is re-name the
> package file.  Only when major functionality changes (added binaries,
> configuration options, etc.) should one have to non-trivially touch
> the package.  On that note, the spec file I provided only covers
> limited rsyslog functionality - GSSAPI, rfc3195, RELP, and the
> debugging tools were all left off simply because I didn't have the
> time to build/package their prerequisites.
>
> One last bit: coming from the Gentoo mentality, I'm less interested in
> binary packages and far more in the meta-files used to generate those.
> Others may differ, but that may help the bitrot concern.

I've been using checkinstall to make the packages as I compile them.

it would be handy if rsyslog could include the spec files that it would 
use to create the appropriate packages, but I can understand the 
reluctance to go there.

but if the dependancies are well documented, then creating the appropriate 
file would be pretty easy.

David Lang


From patrick.shen at net-m.de  Wed Sep 24 10:56:30 2008
From: patrick.shen at net-m.de (Patrick Shen)
Date: Wed, 24 Sep 2008 16:56:30 +0800
Subject: [rsyslog] A question about message size
Message-ID: <48DA00BE.2030705@net-m.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Rainer,

Now I am running latest V3 stable (3.18.4) on my company production
machine. We couldn't upgrade to >=3.21.4 to get the benefit of dynamic
setting MESSAGE size due to company policy.

But we need 4K for message size not 2K by default. So I changed MAXLINE
definition in syslogd.h from 2048 to 4096.

Is it correct? And do we have any other solutions with 3.18.4 ?

Many thanks,

- --
Patrick Shen
Operations Engineer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjaAL4ACgkQkHhYtFevC+PhBgCfVnsQU4Zcn9rVgWZIpS5WXqWz
YxMAn3GWCZ2bPvJFthSCb2HECCfIkF7Y
=Rza/
-----END PGP SIGNATURE-----


From rgerhards at hq.adiscon.com  Wed Sep 24 12:39:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 24 Sep 2008 12:39:14 +0200
Subject: [rsyslog] A question about message size
In-Reply-To: <48DA00BE.2030705@net-m.de>
References: <48DA00BE.2030705@net-m.de>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1D4@grfint2.intern.adiscon.com>

Yes, that's right and that's the only solution for v3-stable.

I haven't merged that change into the stable branch because, among all
of the changes done, this one is among those with the greatest potential
to break things. You do not want to have that in v3-stable (just to note
that backporting it is definitely not a good idea ;)).

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Patrick Shen
> Sent: Wednesday, September 24, 2008 10:57 AM
> To: rsyslog-users
> Subject: [rsyslog] A question about message size
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Rainer,
> 
> Now I am running latest V3 stable (3.18.4) on my company production
> machine. We couldn't upgrade to >=3.21.4 to get the benefit of dynamic
> setting MESSAGE size due to company policy.
> 
> But we need 4K for message size not 2K by default. So I changed
MAXLINE
> definition in syslogd.h from 2048 to 4096.
> 
> Is it correct? And do we have any other solutions with 3.18.4 ?
> 
> Many thanks,
> 
> - --
> Patrick Shen
> Operations Engineer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkjaAL4ACgkQkHhYtFevC+PhBgCfVnsQU4Zcn9rVgWZIpS5WXqWz
> YxMAn3GWCZ2bPvJFthSCb2HECCfIkF7Y
> =Rza/
> -----END PGP SIGNATURE-----
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From patrick.shen at net-m.de  Wed Sep 24 13:48:04 2008
From: patrick.shen at net-m.de (Patrick Shen)
Date: Wed, 24 Sep 2008 19:48:04 +0800
Subject: [rsyslog] A question about message size
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1D4@grfint2.intern.adiscon.com>
References: <48DA00BE.2030705@net-m.de>
	<577465F99B41C842AAFBE9ED71E70ABA44F1D4@grfint2.intern.adiscon.com>
Message-ID: <48DA28F4.2070204@net-m.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for your explanation.

Best regards,
Patrick

Rainer Gerhards wrote:
> Yes, that's right and that's the only solution for v3-stable.
> 
> I haven't merged that change into the stable branch because, among all
> of the changes done, this one is among those with the greatest potential
> to break things. You do not want to have that in v3-stable (just to note
> that backporting it is definitely not a good idea ;)).
> 
> Rainer
> 
>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of Patrick Shen
>> Sent: Wednesday, September 24, 2008 10:57 AM
>> To: rsyslog-users
>> Subject: [rsyslog] A question about message size
>>
> Hi Rainer,
> 
> Now I am running latest V3 stable (3.18.4) on my company production
> machine. We couldn't upgrade to >=3.21.4 to get the benefit of dynamic
> setting MESSAGE size due to company policy.
> 
> But we need 4K for message size not 2K by default. So I changed
>> MAXLINE
> definition in syslogd.h from 2048 to 4096.
> 
> Is it correct? And do we have any other solutions with 3.18.4 ?
> 
> Many thanks,
> 
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

- --
Patrick Shen
Operations Engineer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjaKPQACgkQkHhYtFevC+NsSACgiur1TmRgsFmE7qs8ff1c/xGF
ifUAn2miAH8ILxk6KUiT2geoVRYXee/O
=3pVu
-----END PGP SIGNATURE-----


From rgerhards at hq.adiscon.com  Thu Sep 25 16:04:01 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 25 Sep 2008 16:04:01 +0200
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
	<4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>

> > http://kb.monitorware.com/tcp-syslog-fill-s-up-buffer-and-doesn-t-
> log-single-events-t8705.html
> 
> It would seem they're using some version of IOS 12.3 or 12.4; the
> 'transport X' predicate was introduced some time in the prior but not
> documented until the latter.  It would be good to know precisely what
> version they are running for reference anyway.
> 
> For all I can tell (not having set up a test env myself), it would
> seem that just because one indicates TCP as the transport, the
> underlying engine doesn't change its semantics and remains at the
> UDP-esque 'one packet per message'.  For that matter, I see references
> specifically to RFC3164 as opposed to 3195.  Leave it to Cisco...

Quick follow-up: I am working with them, hope to get some results out of
this conversation. As this bug seems to actually exist in IOS and lots
of IOS are rolled out, I'll try to do a work-around, at least if I can
convince myself that it will work in at least many cases ;)

Rainer


From aoz.syn at gmail.com  Thu Sep 25 17:08:44 2008
From: aoz.syn at gmail.com (RB)
Date: Thu, 25 Sep 2008 09:08:44 -0600
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
	<4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>
Message-ID: <4255c2570809250808g2834d6f4k403af11295cdca2e@mail.gmail.com>

> Quick follow-up: I am working with them, hope to get some results out of
> this conversation. As this bug seems to actually exist in IOS and lots
> of IOS are rolled out, I'll try to do a work-around, at least if I can
> convince myself that it will work in at least many cases ;)

I've been watching the thread.  Seems like some people have adopted a
workaround based on the signature at the beginning of the Cisco log
entries, but that's pretty obviously subpar - their switching gear
doesn't seem to add those, at least on the 12.1 2950 I test against.
Sorry I don't have much else to offer here - like the OP noted, all my
logging has been on the LAN, and trusted segments to boot.  I've seen
setups where remote routers logged over IPSEC or GRE tunnels, but
those were still using UDP.


RB


From rgerhards at hq.adiscon.com  Thu Sep 25 17:11:24 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 25 Sep 2008 17:11:24 +0200
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <4255c2570809250808g2834d6f4k403af11295cdca2e@mail.gmail.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com><4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>
	<4255c2570809250808g2834d6f4k403af11295cdca2e@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F206@grfint2.intern.adiscon.com>

> > Quick follow-up: I am working with them, hope to get some results
out
> of
> > this conversation. As this bug seems to actually exist in IOS and
> lots
> > of IOS are rolled out, I'll try to do a work-around, at least if I
> can
> > convince myself that it will work in at least many cases ;)
> 
> I've been watching the thread.  Seems like some people have adopted a
> workaround based on the signature at the beginning of the Cisco log
> entries, but that's pretty obviously subpar - their switching gear
> doesn't seem to add those, at least on the 12.1 2950 I test against.
> Sorry I don't have much else to offer here 

You offered a lot. You post helped track down the problem source and
made make go the right direction :) I think the best thing now is to
wait for what the Cisco folks come up with. And if that takes too long,
I'll add an $WorkAroundCrazyTCPBug directive and see if it works out ;)

> - like the OP noted, all my
> logging has been on the LAN, and trusted segments to boot.  I've seen
> setups where remote routers logged over IPSEC or GRE tunnels, but
> those were still using UDP.

Rainer


From rgerhards at hq.adiscon.com  Fri Sep 26 17:12:09 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 26 Sep 2008 17:12:09 +0200
Subject: [rsyslog] abort case
In-Reply-To: <alpine.DEB.1.10.0809231454200.18598@sancho.ccd.uniroma2.it>
References: <dc67eef70809220810s1815ff2evce41b096484eb644@mail.gmail.com><59e975c10809221126o37d8919w674f13aee5acc16f@mail.gmail.com><dc67eef70809230133v696f6145r94044ccb30c9cbdc@mail.gmail.com><alpine.DEB.1.10.0809231355450.18598@sancho.ccd.uniroma2.it><dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com><1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809231454200.18598@sancho.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F21A@grfint2.intern.adiscon.com>

Lorenzo,

I have created a new version with one slight change, to be found in the helgrind branch.

There is also a new valgrind tool called drd inside the valgrind development tree. I think you already downloaded that tree. If so, could you please replace

Valgrind --tool=helgrind .. rsyslogd ...

with

Valgrind --tool=drd .. rsyslogd ...

Drd does an even better job than helgrind. I also changed the source to remove some debug-system related warning, which otherwise would clutter up the error message. But unfortunately, in my lab I did not find any more problems, except for the small change I mentioned. But that one affects program termination (and in a very subtle way), so it should not change anything for you. I'd still be interested in a new run, including debug info, from you.

Thanks,
Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Lorenzo M. Catucci
> Sent: Tuesday, September 23, 2008 3:09 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] abort case
> 
> On Tue, 23 Sep 2008, Rainer Gerhards wrote:
> 
> RG> Lorenzo,
> RG>
> RG> I have done a change to the message handler, it is now using an
> atomic
> RG> memory access operation where it previously did not. I have just
> pushed
> RG> that change as part of the helgrind branch.
> RG>
> 
> Recompiled/reinstalled/restarted. make did recompile msg.c, I don't
> know
> why rsyslogd didn't get relinked, but I forced relink by removing
> rsyslogd
> from tools.
> 
> This time, the server crashed even though it was being helground...
> 
> Find enclosed the full debug log.
> 
> Yours,
> 
> 	lorenzo
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From friedl at hq.adiscon.com  Tue Sep 30 12:02:14 2008
From: friedl at hq.adiscon.com (Florian Riedl)
Date: Tue, 30 Sep 2008 12:02:14 +0200
Subject: [rsyslog] rsyslog 3.21.5 released
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>

Hi all,

rsyslog 3.21.5, a member of the development branch, has just been
released. It contains new features, improvements and bug fixes. Most
importantly, a bug has been fixed that can cause a segfault on HUP when
using the UDP input. Also, performance has been greatly enhanced
(special thanks to David Lang for his help). Finally, multi-threaded
handling has been improved. This is a recommended update for all
development branch users.

Changelog:

http://www.rsyslog.com/Article279.phtml

Download:

http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-132.phtml

As always, feedback is appreciated.

Florian Riedl
--
Support
=======

Improving rsyslog is costly, but you can help!  We are looking for
organizations that find rsyslog useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for rsyslog are available, and they help
finance continued maintenance.  Adiscon GmbH, a privately held German
company, is currently funding rsyslog development. We are always looking
for interesting development projects. For details on how to help, please
see http://www.rsyslog.com/doc-how2help.html .




From luigi.perroti at googlemail.com  Tue Sep 30 14:20:11 2008
From: luigi.perroti at googlemail.com (Luigi Perroti)
Date: Tue, 30 Sep 2008 14:20:11 +0200
Subject: [rsyslog] rsyslog 3.21.5 released
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>
Message-ID: <d67280e00809300520s625834am9ecbe4ea3d347a42@mail.gmail.com>

On 9/30/08, Florian Riedl <friedl at hq.adiscon.com> wrote:
> Hi all,
>
> rsyslog 3.21.5, a member of the development branch, has just been
> released.

Hi,

I'm eager to switch from the stable to the development branch but
first I'd like to know if the imfile segmentation fix that was shipped
with 3.18.3 has been merged into the development branch.

The changelogs for 3.21.3 - 3.21.5 don't mention this issue so
probably I'll have to wait but I thought I'd ask just in case.

Thanks!

Regards,
Luigi


From rgerhards at hq.adiscon.com  Tue Sep 30 14:28:20 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 30 Sep 2008 14:28:20 +0200
Subject: [rsyslog] rsyslog 3.21.5 released
In-Reply-To: <d67280e00809300520s625834am9ecbe4ea3d347a42@mail.gmail.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>
	<d67280e00809300520s625834am9ecbe4ea3d347a42@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F23F@grfint2.intern.adiscon.com>

Hi Luigi,

yes, this has been merged. All fixes have been merged, except for some
doc things. I think this is the one in question:

http://git.adiscon.com/?p=rsyslog.git;a=commit;h=7b456ce548030ff362d3a2b
e04b1e5c2c89e0dcb

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Luigi Perroti
> Sent: Tuesday, September 30, 2008 2:20 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog 3.21.5 released
> 
> On 9/30/08, Florian Riedl <friedl at hq.adiscon.com> wrote:
> > Hi all,
> >
> > rsyslog 3.21.5, a member of the development branch, has just been
> > released.
> 
> Hi,
> 
> I'm eager to switch from the stable to the development branch but
> first I'd like to know if the imfile segmentation fix that was shipped
> with 3.18.3 has been merged into the development branch.
> 
> The changelogs for 3.21.3 - 3.21.5 don't mention this issue so
> probably I'll have to wait but I thought I'd ask just in case.
> 
> Thanks!
> 
> Regards,
> Luigi
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com


From luigi.perroti at googlemail.com  Tue Sep 30 19:29:56 2008
From: luigi.perroti at googlemail.com (Luigi Perroti)
Date: Tue, 30 Sep 2008 19:29:56 +0200
Subject: [rsyslog] MainMsgQueueWorkerThreads and devel branch
Message-ID: <d67280e00809301029q4b96d88sdf29d0d26f357a79@mail.gmail.com>

Hi,

I've upgraded from 3.18.3-Test6 to 3.21.5 and I noticed that I can
only use a value of 1 for $MainMsgQueueWorkerThreads. I had it set to
8 on the stable branch.

If I set its value to something greater than 1 rsyslog writes the pid
file but doesn't start.

1 thread should be enough for my needs and I can stick with it.
Still I'd like to know if this behaviour is known to the developers,
maybe it is since the documentation recommends a value of 1.

Regards,
Luigi


From rgerhards at hq.adiscon.com  Mon Sep  1 15:32:27 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 1 Sep 2008 15:32:27 +0200
Subject: [rsyslog] Problems migrating from syslog-ng
In-Reply-To: <c24352ca0808220621s5419322fi3f0820e1dea79da9@mail.gmail.com>
References: <c24352ca0808211033u3e1a810dsb5ad7f11c594bfe6@mail.gmail.com><ac9ded160808211046h4eb276e2t9653c5e7169008f5@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA0108D9@grfint2.intern.adiscon.com><c24352ca0808211344n221aff68ib6e143c287680b48@mail.gmail.com><ac9ded160808211400w2da90ce3k17a307a214aa939f@mail.gmail.com>
	<c24352ca0808220621s5419322fi3f0820e1dea79da9@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F05E@grfint2.intern.adiscon.com>

Being back...

(inline)

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Jeff Schroeder
> Sent: Friday, August 22, 2008 3:21 PM
> To: (private) HKS
> Cc: rsyslog-users
> Subject: Re: [rsyslog] Problems migrating from syslog-ng
> 
> On Thu, Aug 21, 2008 at 2:00 PM, (private) HKS <hks.private at gmail.com>
> wrote:
> > On Thu, Aug 21, 2008 at 4:44 PM, Jeff Schroeder
> <jeffschroed at gmail.com> wrote:
> >> On Thu, Aug 21, 2008 at 10:53 AM, Rainer Gerhards
> >> <rgerhards at hq.adiscon.com> wrote:
> >>> I have only been able to have a brief look, but it looks like the
> message is incorrectly formatted. rsyslog is smart enough to detect
> that the hostname is missing if the tag is followed by a character not
> valid in hostnames. But if the tag even looks like a hostname, it has
> no chance of detecting that it isn't one. As suggested, see RFC 3164
> for what the format should look like. I think the -x option (or some
> other) enables to strip hostname detection, but I am not sure. You can
> "solve" this by misusing some fields. E.g. FROMHOST probably has what
> actually is the tag. HKS suggestion will help you find a suitable
> format.
> 
> You were right Rainer. It looks like the java code which injects the
> message is sending malformed
> syslog requests.

Please provide samples of the raw messages, what syslog-ng does to them
and what rsyslog does (and what you would ideally like to see, if that's
different in any aspect ;)). [I know you have sent most of it - except
the source message, but I'd like to have a consistent set to look at.]

> syslog-ng still sends it through and does the correct
> things. Is there a way to make
> rsyslog a bit less strict about it? 

It depends on the above things. The problem is that when we cannot
detect whether it is a tag or a hostname, there is no way to do it
automatically. I can, of course, add a switch that tells the parser that
there never is a hostname inside the message. I suspect this is what
syslog-ng is doing. This prevents relay chains from properly conveying
the hostname, but I guess it would work in your case. It needs to be a
user option, because obviously most users will never want to use this
handling.

> Running rsyslog with -c0 defeats
> the purpose of using rsyslog.

Well... not really. The -cX switches change some aspects of behavior,
but do not change the core itself. However, I do not think that -c0
would change anything. Does it? If so, my analysis would obviously be
wrong...

> Until our application has been fixed and rolled out accross our
> clusters worldwide, we rolled back to syslog-ng.

Of course, I'd like to support the format as-is (under above
constraints;)).

Rainer
> 
> 
> >>
> >> Is there an equivalent of "-x" with "-c 3" enabled? It doesn't seem
> to
> >> work with -c3 and I'd
> >> rather not run in compatibility mode.
> >
> >
> > I don't think so.
> >
> > -HKS
> >
> 
> 
> 
> --
> Jeff Schroeder
> 
> Don't drink and derive, alcohol and analysis don't mix.
> http://www.digitalprognosis.com
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Mon Sep  1 16:41:45 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 01 Sep 2008 16:41:45 +0200
Subject: [rsyslog] broken size_nbr handling
In-Reply-To: <4255c2570808232301n5bab0c30w549df07c8e5b6c1f@mail.gmail.com>
References: <4255c2570808232301n5bab0c30w549df07c8e5b6c1f@mail.gmail.com>
Message-ID: <1220280105.7184.411.camel@rgf9dev.intern.adiscon.com>

Thanks for spotting this problem and the patch. I have just applied it
to the v3-stable branch, will be moved to all others soon.

Rainer

On Sun, 2008-08-24 at 00:01 -0600, RB wrote:
> In implementing my own 'human-readable' size parser (would be nice to
> have one as a part of one of the usable objects), I noticed there
> seemed to be order-of-magnitude issues on the base-10 size definitions
> in cfsysline.c.  Although the base-2 operations properly increase 2^10
> (1024) for each SI prefix, the base-10 ones only increase by one order
> of magnitude (10) instead of the proper 10^3 per prefix, ending up
> with EB only being 10^8 instead of 10^18.
> 
> Following is a simple patch that should put things right:
> ======================================
> diff --git a/runtime/cfsysline.c b/runtime/cfsysline.c
> index 18643ba..1989247 100644
> --- a/runtime/cfsysline.c
> +++ b/runtime/cfsysline.c
> @@ -215,11 +215,11 @@ static rsRetVal doGetSize(uchar **pp, rsRetVal
> (*pSetHdlr)(void*, uid_t), void *
>                 case 'e': i *= (int64) 1024 * 1024 * 1024 * 1024 *
> 1024 * 1024; ++(*pp); break; /* exa */
>                 /* and now the "new" 1000-based definitions */
>                 case 'K': i *= 1000; ++(*pp); break;
> -               case 'M': i *= 10000; ++(*pp); break;
> -               case 'G': i *= 100000; ++(*pp); break;
> -               case 'T': i *= 1000000; ++(*pp); break; /* tera */
> -               case 'P': i *= 10000000; ++(*pp); break; /* peta */
> -               case 'E': i *= 100000000; ++(*pp); break; /* exa */
> +               case 'M': i *= 1000000; ++(*pp); break;
> +               case 'G': i *= 1000000000; ++(*pp); break;
> +               case 'T': i *= 1000000000000; ++(*pp); break; /* tera */
> +               case 'P': i *= 1000000000000000; ++(*pp); break; /* peta */
> +               case 'E': i *= 1000000000000000000; ++(*pp); break; /* exa */
>         }
> 
>         /* done */
> ======================================
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep  1 16:56:42 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 01 Sep 2008 16:56:42 +0200
Subject: [rsyslog] Running hashes
In-Reply-To: <4255c2570808230045kb625e11u795435a8a6c8d457@mail.gmail.com>
References: <4255c2570808230045kb625e11u795435a8a6c8d457@mail.gmail.com>
Message-ID: <1220281002.7184.426.camel@rgf9dev.intern.adiscon.com>

On Sat, 2008-08-23 at 01:45 -0600, RB wrote:
> Acting on an old comment from a friend, I decided to look into what
> it'd take to get rsyslog to perform running hashes of logs.
> Conceptually, it's pretty simple - every Nth message inject one
> message containing the hash of the previous N messages (including the
> previous hash message).  

Yes - this is the way IETF's upcoming syslog-sign is using hashes. It
may be tempting to use that mode for the logs, too...

> It also gave me an excuse to start digging
> into the rsyslog code.
> 
> At first I thought I could do it with a property replacer, but that
> seems a wash since those are wholly message-based and don't [seem to]
> give the opportunity to store information (even a running hash) of
> prior messages.  

That's right and that's by design. The property replacer is a one-way
road.

> A plugin was my next hope, but there doesn't seem to
> be a good mechanism to pipeline those together - AFAICT they're
> expected to be single ingress/egress points, with no interstitial
> stages. 

That's definitely true for input and output plugins. They, by very
definition, are at either end of the processing flow.

>  I see the code for loading other objects as Rainer mentioned
> in April, but that seems more for central functionality than for
> chaining modules together.

You are absolutely correct. These objects are (mostly) for internal
things, so to save us static binding - and the ability to use different
drivers for different needs, e.g. for different network transport
protocols (and maybe later for different, even-smaller and more
abstracted, database drivers).

> This all brings me back to one of my original questions for rsyslog -
> is module chaining something that is even on your radar?  I'm thinking
> normalization, hashing, encryption, etc.  Almost feels like there
> should be another layer here, maybe a "mangle" plugin interface that
> could stack in after im* and before om*?

You are definitely on the right route. If you look at the plugin
definitions, there is another class, not yet implemented, of plugins:
they are called "filter plugins". They will have the ability to take a
message, modify it (or inject a new one based on previous messages) and
so on - at least this is how it was designed roughly a year ago.

With the arrival of the scripting language (in February, if I correctly
remember), new players have entered the field: library plugins that
expose function calls to the script engine. So far, they do NOT yet
exist, but they are pretty well thought out. They are probably the first
thing I will implement when I start bringing the script engine to its
full power. These functions may also be a good place to provide a
"mangling" interface. I am still a bit undecided, maybe I will not 100%
design this, but let the code evolve (sometimes, I think, it is good to
look at code written and see if that "extra bit" just naturally fits
in...).

A bit problematic is the order of events (and message modification) when
the message object is run asynchronously through multiple action queues.
For each queue, the message is forked, so it requires careful design
when to modify which of the forked messages. This can be very powerful,
but also quite complex to configure (where the scripting language
hopefully comes in handy).

Another, internal, thing is message synchronization. So far, property
creation and modification never requires sync objects (like mutexes),
because the always happen in a single thread (for ONE specific message,
of course). With mangling capabilities, things change considerably,
property set methods than need sync capability. This must be implemented
in a way that does not hurt the (for more frequent) case of message
object creation.

Of course, all of this is doable and the base design is there :) I just
wanted to provide an idea why it may take a little while to implement.
Comments and suggestions are most welcome, especially as this is among
the next things on my todo list (if priorities don't change).

Rainer
> 
> 
> RB
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep  1 17:00:15 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 1 Sep 2008 17:00:15 +0200
Subject: [rsyslog] Running hashes
In-Reply-To: <1220281002.7184.426.camel@rgf9dev.intern.adiscon.com>
References: <4255c2570808230045kb625e11u795435a8a6c8d457@mail.gmail.com>
	<1220281002.7184.426.camel@rgf9dev.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F064@grfint2.intern.adiscon.com>

I forgot one thing. If you did not already find it, have a look at this:

http://www.rsyslog.com/doc-generic_design.html

The filter/function plugins are conceptually on the "PLG Ext" et al
layer in this chart. This is not specifically rsyslog design, but it
comes from the same source and conveys the same basic idea ;) [I
initially did that description for some generic IETF work].

Maybe it is useful.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Monday, September 01, 2008 4:57 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] Running hashes
> 
> On Sat, 2008-08-23 at 01:45 -0600, RB wrote:
> > Acting on an old comment from a friend, I decided to look into what
> > it'd take to get rsyslog to perform running hashes of logs.
> > Conceptually, it's pretty simple - every Nth message inject one
> > message containing the hash of the previous N messages (including
the
> > previous hash message).
> 
> Yes - this is the way IETF's upcoming syslog-sign is using hashes. It
> may be tempting to use that mode for the logs, too...
> 
> > It also gave me an excuse to start digging
> > into the rsyslog code.
> >
> > At first I thought I could do it with a property replacer, but that
> > seems a wash since those are wholly message-based and don't [seem
to]
> > give the opportunity to store information (even a running hash) of
> > prior messages.
> 
> That's right and that's by design. The property replacer is a one-way
> road.
> 
> > A plugin was my next hope, but there doesn't seem to
> > be a good mechanism to pipeline those together - AFAICT they're
> > expected to be single ingress/egress points, with no interstitial
> > stages.
> 
> That's definitely true for input and output plugins. They, by very
> definition, are at either end of the processing flow.
> 
> >  I see the code for loading other objects as Rainer mentioned
> > in April, but that seems more for central functionality than for
> > chaining modules together.
> 
> You are absolutely correct. These objects are (mostly) for internal
> things, so to save us static binding - and the ability to use
different
> drivers for different needs, e.g. for different network transport
> protocols (and maybe later for different, even-smaller and more
> abstracted, database drivers).
> 
> > This all brings me back to one of my original questions for rsyslog
-
> > is module chaining something that is even on your radar?  I'm
> thinking
> > normalization, hashing, encryption, etc.  Almost feels like there
> > should be another layer here, maybe a "mangle" plugin interface that
> > could stack in after im* and before om*?
> 
> You are definitely on the right route. If you look at the plugin
> definitions, there is another class, not yet implemented, of plugins:
> they are called "filter plugins". They will have the ability to take a
> message, modify it (or inject a new one based on previous messages)
and
> so on - at least this is how it was designed roughly a year ago.
> 
> With the arrival of the scripting language (in February, if I
correctly
> remember), new players have entered the field: library plugins that
> expose function calls to the script engine. So far, they do NOT yet
> exist, but they are pretty well thought out. They are probably the
> first
> thing I will implement when I start bringing the script engine to its
> full power. These functions may also be a good place to provide a
> "mangling" interface. I am still a bit undecided, maybe I will not
100%
> design this, but let the code evolve (sometimes, I think, it is good
to
> look at code written and see if that "extra bit" just naturally fits
> in...).
> 
> A bit problematic is the order of events (and message modification)
> when
> the message object is run asynchronously through multiple action
> queues.
> For each queue, the message is forked, so it requires careful design
> when to modify which of the forked messages. This can be very
powerful,
> but also quite complex to configure (where the scripting language
> hopefully comes in handy).
> 
> Another, internal, thing is message synchronization. So far, property
> creation and modification never requires sync objects (like mutexes),
> because the always happen in a single thread (for ONE specific
message,
> of course). With mangling capabilities, things change considerably,
> property set methods than need sync capability. This must be
> implemented
> in a way that does not hurt the (for more frequent) case of message
> object creation.
> 
> Of course, all of this is doable and the base design is there :) I
just
> wanted to provide an idea why it may take a little while to implement.
> Comments and suggestions are most welcome, especially as this is among
> the next things on my todo list (if priorities don't change).
> 
> Rainer
> >
> >
> > RB
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Tue Sep  2 12:47:08 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 2 Sep 2008 12:47:08 +0200
Subject: [rsyslog] preview of 3.21.4 devel
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F073@grfint2.intern.adiscon.com>

Hi all,

I am about to release 3.21.4, BUT it contains one big change and I would
appreciate if some of you could give it a try before I officially
release it. In 3.21.4, I have removed the compile-time hardcoded maximum
message size. So far, a message, by default, could be 2K maximum. This
could be changed by modifying the MAXLINE compile time default (and
recompiling/install). This size limit stems back to plain old BSD
syslogd, RFC 3164 (where it is 1k) and the upcoming syslog RFC series
(where it is variable, but 2k is suggested as a minimum). There have
been a lot of questions about larger sizes. So I have now streamlined
the process and created a simple config directive:

$MaxMessageSize 4k

Where 4k is of your choice. You may also specify any non-k value, like
7341. I do not check for a sensible maximum, so you may also specify 4p
(4 petabyte), but I hardly believe that will get you a working instance
;)

I did not blindly change the message size - I tried to keep performance
as good as with the previous approach (dyn memory alloc takes more
time!). So there is chance for failure all over the code. In my test (up
to now), everything works, but I would really appreciate some feedback
from practice.

Please let me know if you experience any issues with that release.

It is available at

http://download.rsyslog.com/rsyslog/rsyslog-3.21.4-Test1.tar.gz

This version also contains a number of smaller fixes, but not yet the
new doc building system (this is next on my agenda).

Your feedback is appreciated.

Rainer


From r.bhatia at ipax.at  Thu Sep  4 10:21:54 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 04 Sep 2008 10:21:54 +0200
Subject: [rsyslog] Problems with spooling to disk
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44EFC8@grfint2.intern.adiscon.com>
References: <20080807120552.GA16724@darville.vm.bytemark.co.uk><577465F99B41C842AAFBE9ED71E70ABA44EF6B@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44EF80@grfint2.intern.adiscon.com><48A2BFA7.8000408@ipax.at>	<1218630780.7184.368.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44EFC8@grfint2.intern.adiscon.com>
Message-ID: <48BF9AA2.1070904@ipax.at>

hi,

i yesterday deployed 3.18.3 and verified that the fix you told specified
below is in the source.

unfortunatly, this does not help and rsyslog hangs. please follow the
steps below to reproduce the error:

1) setup two servers. A is the rsyslog "client" and B is the rsyslog
   server logging to mysql.

A is configured with the debian default config and:
> $WorkDirectory /var/spool/rsyslog/ # where to place spool files
> $ActionQueueFileName remote # unique name prefix for spool files
> $ActionQueueMaxDiskSpace 100M   # 100mb space limit (use as much as possible)
> $ActionQueueSaveOnShutdown on # save messages to disk on shutdown
> $ActionQueueType LinkedList   # run asynchronously
> $ActionResumeRetryCount -1    # infinite retries if host is down
> # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
> *.* @@b.ipax.at:514

B is configured with the debian default config and:
> # provides UDP syslog reception
> $ModLoad imudp
> $UDPServerRun 514
> 
> # provides TCP syslog reception
> $ModLoad imtcp
> $InputTCPServerRun 514
> ...
> $ModLoad ommysql
> :programname, isequal, "prog1" ~
> :programname, isequal, "prog2" ~
> *.* :ommysql:localhost,Syslog,dbuser,dbpass

2) we start A and B and verify that it works correctly:
messages on A are logged to /var/log/ and sent to B

messages on B (= originating from A and B) are logged to /var/log/ and
are sent to the mysql db.

3) i connect to the mysql db and run some sql statements:
> delete from SystemEvents where SysLogTag like "prog1[%";
> delete from SystemEvents where SysLogTag like "prog2[%";
> delete from SystemEvents where SysLogTag like "pam_limits[%";

4) whilst the statement is running, issue the following command on B:
> logger testt

5) observe that testt is neither logged to the mysql db (thats expected
as delete locks the myisam table) but also not logged to /var/log/

this effectivly blocks something causing server A to not function
properly. e.g. apache2, sshd, bind, etc are not working properly.

please help :)

cheers,
raoul


Rainer Gerhards wrote:
> This is the v3-stable fix:
> 
> http://git.adiscon.com/?p=rsyslog.git;a=blobdiff;f=plugins/imuxsock/imux
> sock.c;h=60ccaffbc526a03011be3ce5869e40bc3e32c319;hp=f8798039c5d53e58fc7
> fa17807547862e08c999e;hb=8eb888d049da12e1294a7688432b6325794ade32;hpb=02
> f768c37dac9dde424bbd31e378482750fc276c
> 
> You can also easily apply it to 3.16 - I just won't do it that version
> has been superseded.
> 
> Rainer
> 
>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
>> Sent: Wednesday, August 13, 2008 2:33 PM
>> To: rsyslog-users
>> Subject: Re: [rsyslog] Problems with spooling to disk
>>
>> On Wed, 2008-08-13 at 13:04 +0200, Raoul Bhatia [IPAX] wrote:
>>> hi,
>>>
>>> Rainer Gerhards wrote:
>>>> Thanks, I now received the log files. And, of course, they made
>>>> immediately clear what is going on ;) What you experience is flow
>>>> control kicking in. Let me first elaborate a bit:
>>>>
>>>> Rsyslog knows inputs which can be delayed a bit (like tcp receiver
>> AND
>>>> the local socket) and those who can not (like UDP). The idea is
>> that we
>>>> can slow down senders where this does not result in loss of
>> messages,
>>>> leaving room inside the queue on busy systems for those where we
>> can not
>>>> do that. We had cases where not delaying caused a lot of grief.
>>>>
>>>> There are also two watermarks, the low and high delay mark. If the
>> low
>>>> delay mark is reached, a delayable source is delayed for one
>> second. It
>>>> is at 70% of the (in-memory) queue capacity. Again, this is all
>> done for
>>>> some very good reasons.
>>>>
>>>> However, when I introduced these features, I did not make them
>>>> configurable. Also, I did classify the local unix socket as one
> who
>> can
>>>> be delayed. In your scenario, this does not stop the system, but
>> once
>>>> the local log socket is filled up, it needs to wait one second for
>> each
>>>> message before it is pulled.
>>>>
>>>> Again, the rate limiting logic is there for good reasons. So what
> I
>> now
>>>> see is that I need to add a few config statements to allow to
>> control it
>>>> according to your needs. I am also unsure if I should re-classify
>>>> imuxsock as an input which cannot be delayed - but that also can
>> have
>>>> some drawbacks. Maybe the best thing to do is make its state
>>>> configurable and use "not to be delayed" as default.
>>> ok, after reading through your explanation, i (almost) understand
> the
>>> delay mechanism and that at present it is not configurable.
>>>
>>> almost, because i do not get the part where you talk about the "70%
>> of
>>> the (in-memory) queue capacity".
>> An example: if the configured queue capacity is 10,000 (the default
>> value for the main message queue), than no flow control at all happens
>> until 7,000 messages are inside the queue. Once they are (and only as
>> long as they are), flow control is applied to those inputs that permit
>> it (imuxsock permits it).
>>
>> It doesn't matter here if the queue is disk-assisted or not. Even with
>> disk-assisted queues, this setting is very important to prevent an
>> input
>> (e.g. imfile!) to send massive amounts of data to the queue when there
>> is no need to (because the input can be flow-controlled).
>>
>>> anyways, how does this relate to the original problem, that the
>>> following code stalls the logging process.
>>>
>>>>>> #! /bin/sh
>>>>>> for ((i=1;i<=10000;i+=1)); do
>>>>>>   logger Log line $i
>>>>>> done
>>> is this a capacity problem? is this another problem?
>> It is going over the flow control watermark, flow control kicks in and
>> delays imuxsock writes by one second each as long as there are more
>> than
>> 7,000 messages. No problem, intended behavior, but obviously
>> questionable. In the imuxsock case, there are also some bad cases.
>>
>>> i really consider this a critical bug, as i yesterday ran out of
>>> diskspace on my remote-rsyslog-and-mysql-on-one-host-testbed and the
>>> rsyslog-client, which logs locally and to the remote destination,
>>> stalled completely.
>> We'll - not completely, one message per second ;) But that's probably
>> complete enough ;)
>>
>> As a quick fix, I think I'll make imuxsock a non-flow-controllable
>> input
>> in the v3-stable (3.18.x). The devel will have a switch to make it
> flow
>> controlled if one desires. I'll also add some other knobs to fine-tune
>> the flow control algo, but that probably needs to wait until after my
>> summer break. These tweaks could easily break things and I don't like
>> the idea of doing them under time pressure ;)
>>
>> HTH
>> Rainer
>>> cheers,
>>> raoul
>>> ps: i am on 3.16.1-1~bpo40+1
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep  4 10:26:19 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 4 Sep 2008 10:26:19 +0200
Subject: [rsyslog] Problems with spooling to disk
In-Reply-To: <48BF9AA2.1070904@ipax.at>
References: <20080807120552.GA16724@darville.vm.bytemark.co.uk><577465F99B41C842AAFBE9ED71E70ABA44EF6B@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44EF80@grfint2.intern.adiscon.com><48A2BFA7.8000408@ipax.at>	<1218630780.7184.368.camel@rgf9dev.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44EFC8@grfint2.intern.adiscon.com>
	<48BF9AA2.1070904@ipax.at>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0A0@grfint2.intern.adiscon.com>

Hi Raoul,

could you quickly mail me a debug log of the client? I know I can set up
the lab per your instructions, but that will need some time. Depending
on what I see in the debug log, we could come much quicker to a solution
[I am currently quite busy after my vacation, so I will probably not be
able to set up the lab this week] ;). You can mail the log to me
privately.

Thanks,
Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX]
> Sent: Thursday, September 04, 2008 10:22 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] Problems with spooling to disk
> 
> hi,
> 
> i yesterday deployed 3.18.3 and verified that the fix you told
> specified
> below is in the source.
> 
> unfortunatly, this does not help and rsyslog hangs. please follow the
> steps below to reproduce the error:
> 
> 1) setup two servers. A is the rsyslog "client" and B is the rsyslog
>    server logging to mysql.
> 
> A is configured with the debian default config and:
> > $WorkDirectory /var/spool/rsyslog/ # where to place spool files
> > $ActionQueueFileName remote # unique name prefix for spool files
> > $ActionQueueMaxDiskSpace 100M   # 100mb space limit (use as much as
> possible)
> > $ActionQueueSaveOnShutdown on # save messages to disk on shutdown
> > $ActionQueueType LinkedList   # run asynchronously
> > $ActionResumeRetryCount -1    # infinite retries if host is down
> > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
> > *.* @@b.ipax.at:514
> 
> B is configured with the debian default config and:
> > # provides UDP syslog reception
> > $ModLoad imudp
> > $UDPServerRun 514
> >
> > # provides TCP syslog reception
> > $ModLoad imtcp
> > $InputTCPServerRun 514
> > ...
> > $ModLoad ommysql
> > :programname, isequal, "prog1" ~
> > :programname, isequal, "prog2" ~
> > *.* :ommysql:localhost,Syslog,dbuser,dbpass
> 
> 2) we start A and B and verify that it works correctly:
> messages on A are logged to /var/log/ and sent to B
> 
> messages on B (= originating from A and B) are logged to /var/log/ and
> are sent to the mysql db.
> 
> 3) i connect to the mysql db and run some sql statements:
> > delete from SystemEvents where SysLogTag like "prog1[%";
> > delete from SystemEvents where SysLogTag like "prog2[%";
> > delete from SystemEvents where SysLogTag like "pam_limits[%";
> 
> 4) whilst the statement is running, issue the following command on B:
> > logger testt
> 
> 5) observe that testt is neither logged to the mysql db (thats
expected
> as delete locks the myisam table) but also not logged to /var/log/
> 
> this effectivly blocks something causing server A to not function
> properly. e.g. apache2, sshd, bind, etc are not working properly.
> 
> please help :)
> 
> cheers,
> raoul
> 
> 
> Rainer Gerhards wrote:
> > This is the v3-stable fix:
> >
> >
>
http://git.adiscon.com/?p=rsyslog.git;a=blobdiff;f=plugins/imuxsock/imu
> x
> >
>
sock.c;h=60ccaffbc526a03011be3ce5869e40bc3e32c319;hp=f8798039c5d53e58fc
> 7
> >
>
fa17807547862e08c999e;hb=8eb888d049da12e1294a7688432b6325794ade32;hpb=0
> 2
> > f768c37dac9dde424bbd31e378482750fc276c
> >
> > You can also easily apply it to 3.16 - I just won't do it that
> version
> > has been superseded.
> >
> > Rainer
> >
> >> -----Original Message-----
> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >> Sent: Wednesday, August 13, 2008 2:33 PM
> >> To: rsyslog-users
> >> Subject: Re: [rsyslog] Problems with spooling to disk
> >>
> >> On Wed, 2008-08-13 at 13:04 +0200, Raoul Bhatia [IPAX] wrote:
> >>> hi,
> >>>
> >>> Rainer Gerhards wrote:
> >>>> Thanks, I now received the log files. And, of course, they made
> >>>> immediately clear what is going on ;) What you experience is flow
> >>>> control kicking in. Let me first elaborate a bit:
> >>>>
> >>>> Rsyslog knows inputs which can be delayed a bit (like tcp
receiver
> >> AND
> >>>> the local socket) and those who can not (like UDP). The idea is
> >> that we
> >>>> can slow down senders where this does not result in loss of
> >> messages,
> >>>> leaving room inside the queue on busy systems for those where we
> >> can not
> >>>> do that. We had cases where not delaying caused a lot of grief.
> >>>>
> >>>> There are also two watermarks, the low and high delay mark. If
the
> >> low
> >>>> delay mark is reached, a delayable source is delayed for one
> >> second. It
> >>>> is at 70% of the (in-memory) queue capacity. Again, this is all
> >> done for
> >>>> some very good reasons.
> >>>>
> >>>> However, when I introduced these features, I did not make them
> >>>> configurable. Also, I did classify the local unix socket as one
> > who
> >> can
> >>>> be delayed. In your scenario, this does not stop the system, but
> >> once
> >>>> the local log socket is filled up, it needs to wait one second
for
> >> each
> >>>> message before it is pulled.
> >>>>
> >>>> Again, the rate limiting logic is there for good reasons. So what
> > I
> >> now
> >>>> see is that I need to add a few config statements to allow to
> >> control it
> >>>> according to your needs. I am also unsure if I should re-classify
> >>>> imuxsock as an input which cannot be delayed - but that also can
> >> have
> >>>> some drawbacks. Maybe the best thing to do is make its state
> >>>> configurable and use "not to be delayed" as default.
> >>> ok, after reading through your explanation, i (almost) understand
> > the
> >>> delay mechanism and that at present it is not configurable.
> >>>
> >>> almost, because i do not get the part where you talk about the
"70%
> >> of
> >>> the (in-memory) queue capacity".
> >> An example: if the configured queue capacity is 10,000 (the default
> >> value for the main message queue), than no flow control at all
> happens
> >> until 7,000 messages are inside the queue. Once they are (and only
> as
> >> long as they are), flow control is applied to those inputs that
> permit
> >> it (imuxsock permits it).
> >>
> >> It doesn't matter here if the queue is disk-assisted or not. Even
> with
> >> disk-assisted queues, this setting is very important to prevent an
> >> input
> >> (e.g. imfile!) to send massive amounts of data to the queue when
> there
> >> is no need to (because the input can be flow-controlled).
> >>
> >>> anyways, how does this relate to the original problem, that the
> >>> following code stalls the logging process.
> >>>
> >>>>>> #! /bin/sh
> >>>>>> for ((i=1;i<=10000;i+=1)); do
> >>>>>>   logger Log line $i
> >>>>>> done
> >>> is this a capacity problem? is this another problem?
> >> It is going over the flow control watermark, flow control kicks in
> and
> >> delays imuxsock writes by one second each as long as there are more
> >> than
> >> 7,000 messages. No problem, intended behavior, but obviously
> >> questionable. In the imuxsock case, there are also some bad cases.
> >>
> >>> i really consider this a critical bug, as i yesterday ran out of
> >>> diskspace on my remote-rsyslog-and-mysql-on-one-host-testbed and
> the
> >>> rsyslog-client, which logs locally and to the remote destination,
> >>> stalled completely.
> >> We'll - not completely, one message per second ;) But that's
> probably
> >> complete enough ;)
> >>
> >> As a quick fix, I think I'll make imuxsock a non-flow-controllable
> >> input
> >> in the v3-stable (3.18.x). The devel will have a switch to make it
> > flow
> >> controlled if one desires. I'll also add some other knobs to fine-
> tune
> >> the flow control algo, but that probably needs to wait until after
> my
> >> summer break. These tweaks could easily break things and I don't
> like
> >> the idea of doing them under time pressure ;)
> >>
> >> HTH
> >> Rainer
> >>> cheers,
> >>> raoul
> >>> ps: i am on 3.16.1-1~bpo40+1
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> 
> 
> --
> ____________________________________________________________________
> DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
> Technischer Leiter
> 
> IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
> Barawitzkagasse 10/2/2/11           email.            office at ipax.at
> 1190 Wien                           tel.               +43 1 3670030
> FN 277995t HG Wien                  fax.            +43 1 3670030 15
> ____________________________________________________________________
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Thu Sep  4 11:52:40 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 04 Sep 2008 11:52:40 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080820170735.GB20932@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
Message-ID: <1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>

Hi,

I was now able to apply the patch series - many thanks. It is currently
in the docbook branch, which is also available on my public git server
(so that others can follow).

I am digging into what the patches actually do and, not surprisingly, I
finally need to learn a bit more about docbook to fully understand it
(looks like this gets my prime activity for the time being ;)).

One thing I already noticed. The man pages are generated via the
--enable-regenerate-man switch, but they are also in git. So when I
regenerate them, this results in a large volume of git changes.

In my POV, the man pages are now output files and as such no longer
something that belongs into git. I understand that this has the
implication that when I remove them from git, everyone who pulls the git
archive needs to have the proper tools in place to generate the doc.
However, is this really a problem? AFAIK other projects have similar
demands. So I would prefer to remove the man pages themselves from git
(but of course not from autotools config files, so that they be still
present in a release tarball).

Does this sound reasonable? Any objections (from anyone)?

I also have not yet fully understood the translation workflow. If
the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
be created with the English source doc, which I maintain)?

Please advise.

Thanks,
Rainer


On Thu, 2008-08-21 at 02:07 +0900, Satoru SATOH wrote:
> Hello,
> 
> 
> I posted the first patch but it seems the patch was too big to post. I
> list them here at once.
> 
> Could you please take some time to review these and merge them?
> 
> 
> I splitted origianl big patch into minimum units. However, to complete
> to man-i18n support, the following patches must be applied in this
> order.
> 
> All of the patches below are available from
> http://www.gnome.gr.jp/~ss/t/rsyslog/.
> 
> 
> 1. 0001-man-i18n-move-man-files-from-tools-to-man-C.patch
> 
> This patch just moves man files from tools/ to man/C/ (new dir to hold
> man related stuff) and update related Makefile.am files.
> 
> 
> 2. 0002-man-i18n-add-man-ja.patch
> 
> This patch creates new dir, man/ja/ and Makefile.am in it.
> 
> There are no man files in it and this should not have harmful effects
> for build process at all, I guess.
> 
> 
> 3. 0003-man-i18n-add-man-ja.patch
> 
> This patch adds man files in man/ja and update Makefile.am in it to
> install these.
> 
> 
> 4. 0004-man-i18n-add-docbook-xml-sources-for-man-files.patch
> 
> This patch adds docbook XML sources for man pages.
> 
> 
> 5. 0005-man-i18n-add-m4-macros-in-m4-and-make-aclocal-look.patch
> 
> This patch adds m4 macros in m4/ and make aclocal look for this dir.
> 
> These m4 files are not evaluated in actual and this should not have
> adverse effect at all, I guess.
> 
> 
> 6. 0006-man-i18n-add-build-process-of-man-pages-in-Makefile.patch
> 
> This patch adds transformation process of man pages and po files in
> Makefile.am.
> 
> Added part are in "if ENABLE_REGENERATE_MAN ... endif" and
> ENABLE_REGENERATE_MAN is not defined at this point, so this also should
> not have side effects.
> 
> 
> 7. 0007-man-i18n-add-enable-regenerate-man-option-for-con.patch
> 
> This is the last one. This patch adds "--enable-regenerate-man"
> configure option to enable man build process.
> 
> This option is disabled by default and should not affect normal build
> process, I think.
> 
> 
> How to build:
> 
> To enable the man build process, configure have to be regenerated:
> 
>   $ (autoreconf -vfi && \
>         ./configure --enable-regenerate-man [...other options] && \
>         make && make install
> 
> 
> Translator's workflow:
> 
>  a. initial translation:
> 
>    0. arrange lang dir, that is, cp man/ja to man/YOUR_LANG/ and edit
>       Makefile.am; s/ja/YOUR_LANG/.
>    1. create POT: make -C man/YOUR_LANG/ create-pot
>    2. copy POT to PO and translate it
>    3. run make
> 
>  b. maintanance:
> 
>    1. update PO: make -C man/YOUR_LANG update-po
>    2. update translations
>    3. just run make
> 
> 
> Requirements for man regeneration / translation:
>  
>    xmllint, xsltproc, xml2po in gnome-doc-utils, DocBook DTD and DocBook
>    xslt stylesheet for man pages are required.
> 
>    If xmlcatalog (e.g. /etc/xml/catalog) is configured appropriately,
>    both xmllint and xsltproc will use local DTD and stylsheet files
>    instead of these from remote site
>    (http://www.oasis-open.org/docbook/...).
> 
> 
> - satoru
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From friedl at hq.adiscon.com  Thu Sep  4 12:45:10 2008
From: friedl at hq.adiscon.com (Florian Riedl)
Date: Thu, 4 Sep 2008 12:45:10 +0200
Subject: [rsyslog] rsyslog 3.21.4 (devel) released
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0AA@grfint2.intern.adiscon.com>

Hi all,

we have just released rsyslog 3.21.4, a devel branch release. The most
important new feature is the ability to dynamically configure the
maximum length of a syslog message. Previously, this was only possible
via a recompile and can now be done via the new $MaxMessageSize config
directive. There are also a number of bugfixes new in this release. It
is a recommended update for all devel branch users.


Download:

http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-130.phtml

Changelog:

http://www.rsyslog.com/Article275.phtml

As always, feedback is appreciated.

Florian Riedl
--
Support
=======

Improving rsyslog is costly, but you can help!  We are looking for
organizations that find rsyslog useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for rsyslog are available, and they help
finance continued maintenance.  Adiscon GmbH, a privately held German
company, is currently funding rsyslog development. We are always looking
for interesting development projects. For details on how to help, please
see http://www.rsyslog.com/doc-how2help.html .



From satoru.satoh at gmail.com  Thu Sep  4 22:31:59 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Fri, 5 Sep 2008 05:31:59 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
Message-ID: <20080904203155.GA6912@localhost.localdomain>

Hi,


On Thu, Sep 04, 2008 at 11:52:40AM +0200, Rainer Gerhards wrote:
> Hi,
> 
> I was now able to apply the patch series - many thanks. It is currently
> in the docbook branch, which is also available on my public git server
> (so that others can follow).

Thanks!

> I am digging into what the patches actually do and, not surprisingly, I
> finally need to learn a bit more about docbook to fully understand it
> (looks like this gets my prime activity for the time being ;)).
> 
> One thing I already noticed. The man pages are generated via the
> --enable-regenerate-man switch, but they are also in git. So when I
> regenerate them, this results in a large volume of git changes.
 
Right.

> In my POV, the man pages are now output files and as such no longer
> something that belongs into git. I understand that this has the
> implication that when I remove them from git, everyone who pulls the git
> archive needs to have the proper tools in place to generate the doc.

Exactly. Addtional requirements are the followings.

 - xslt processor, xsltproc
 - xml validator, xmllint
 - properly configured xml catalog or internet access
 - docbook xml dtd (local or remote)
 - docbook xsl stylesheet for docbook-to-man transformation (local or
   remote)
 - xml2po in gnome-doc-utils (optional; must for translators)

I thought that not all of developers have such system and so that this
should be avoided. This is why I disabled man-regeneration process by
default.

> However, is this really a problem? AFAIK other projects have similar
> demands. So I would prefer to remove the man pages themselves from git
> (but of course not from autotools config files, so that they be still
> present in a release tarball).
> 
> Does this sound reasonable? Any objections (from anyone)?

One thing i have to mention.

Actually, man files generated from docbook xml files are slightly
different from original man files ATM. These need some refactoring.

If it's not a matter, it would be ok.

> I also have not yet fully understood the translation workflow. If
> the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
> version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
> be created with the English source doc, which I maintain)?

It is a little much complicated than that. Here are example steps for
german (de) man pages.


[initial translation]

  1. create mandir and makefile.am in it

     $ mkdir man/de && \
        sed 's/LANG = ja/LANG = de/' man/ja/Makefile.am > \
                man/de/Makefile.am

  2. add man/de/ to SUBDIRS in man/Makefile.am

     $ sed -i 's/^\(SUBDIRS.*\)/\1 de/' man/Makefile.am

  3. add man/de/Makefile.am to AC_CONFIG_FILES in configure.ac

  4. generate man/de/Makefile.am

     $ autoreconf -vfi && ./configure --prefix=$(pwd)/i \
        --enable-regenerate-man

  5. generate POT (PO template; language independent) and rename it 

     $ make -C man/de create-pot
     $ mv man/de/rsyslog.conf.5.pot man/de/rsyslog.conf.5.po
     $ mv man/de/rsyslogd.8.pot man/de/rsyslogd.8.po

  6. edit necessary header fields in PO files

     $ vim man/de/rsyslog.conf.5.po
     $ cat man/de/rsyslog.conf.5.po
     msgid ""
     msgstr ""
     "Project-Id-Version: rsyslog HEAD\n"
     "POT-Creation-Date: 2008-09-05 04:41+0900\n"
     "PO-Revision-Date: 2008-09-05 05:01+0900\n"
     "Last-Translator: XXXXX YYYYY <xxxxyyyyy at example.com>\n"
     "Language-Team: German <LL at li.org>\n"
     "MIME-Version: 1.0\n"
     "Content-Type: text/plain; charset=UTF-8\n"
     "Content-Transfer-Encoding: 8bit\n"

     (snip)

  7. translate PO files

  8. generate man files

     $ ./configure --prefix=$(pwd)/i --enable-regenerate-man && make


[update translations]

  1. update PO to follow changes in original docbook xml files

     $ make -C man/de update-po


Please refer to man/ja/Makefile.am also. 


BTW, "C" (man/C) means C (English) locale. This is the traditional dir
name to keep original English message catalogs, I think.

- satoru

(snip)
> > How to build:
> > 
> > To enable the man build process, configure have to be regenerated:
> > 
> >   $ (autoreconf -vfi && \
> >         ./configure --enable-regenerate-man [...other options] && \
> >         make && make install
> > 
> > 
> > Translator's workflow:
> > 
> >  a. initial translation:
> > 
> >    0. arrange lang dir, that is, cp man/ja to man/YOUR_LANG/ and edit
> >       Makefile.am; s/ja/YOUR_LANG/.
> >    1. create POT: make -C man/YOUR_LANG/ create-pot
> >    2. copy POT to PO and translate it
> >    3. run make
> > 
> >  b. maintanance:
> > 
> >    1. update PO: make -C man/YOUR_LANG update-po
> >    2. update translations
> >    3. just run make
> > 
> > 
> > Requirements for man regeneration / translation:
> >  
> >    xmllint, xsltproc, xml2po in gnome-doc-utils, DocBook DTD and DocBook
> >    xslt stylesheet for man pages are required.
> > 
> >    If xmlcatalog (e.g. /etc/xml/catalog) is configured appropriately,
> >    both xmllint and xsltproc will use local DTD and stylsheet files
> >    instead of these from remote site
> >    (http://www.oasis-open.org/docbook/...).
> > 
> > 
> > - satoru


From mbiebl at gmail.com  Thu Sep  4 22:53:38 2008
From: mbiebl at gmail.com (Michael Biebl)
Date: Thu, 4 Sep 2008 22:53:38 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080904203155.GA6912@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
Message-ID: <aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>

Hi,

just curious: Are you also working on getting the other documentation
in doc/ converted to docbook?
Something like [1] would be awesome for rsyslog and I think with
docbook, pdf would just be another output format, right?

While it is great to have documentation at all, the current one is a
bit inconsistent and hard to navigate.


Cheers,
Michael

[1] http://www.exim.org/exim-pdf-current/doc/spec.pdf
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


From rfujita at redhat.com  Fri Sep  5 03:06:25 2008
From: rfujita at redhat.com (Ryo Fujita)
Date: Fri, 5 Sep 2008 10:06:25 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
	<aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
Message-ID: <745EC623-B3A0-4FC8-B01C-91A9BD8B2892@redhat.com>

Hi,

Yes, I'm converting other documentation in doc/ to DocBook xml.
# About 40 docs out of 90 has been converted.

But there are some issues to convert and restructure them,
I consult with Rainer-san out of the ML.

Best Rio.

On 2008/09/05, at 5:53, Michael Biebl wrote:

> Hi,
>
> just curious: Are you also working on getting the other documentation
> in doc/ converted to docbook?
> Something like [1] would be awesome for rsyslog and I think with
> docbook, pdf would just be another output format, right?
>
> While it is great to have documentation at all, the current one is a
> bit inconsistent and hard to navigate.
>
>
> Cheers,
> Michael
>
> [1] http://www.exim.org/exim-pdf-current/doc/spec.pdf
> -- 
> 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

########################################################################
Ryo Fujita <rfujita at redhat.com>
Senior Solution Architect, RHCE
Red Hat K.K.
TEL +81-3-5798-8500
FAX +81-3-5798-8599
Ebisu Neonato 8F
4-1-18 Ebisu, Shibuya-ku,
Tokyo Japan 1500013
########################################################################



From rgerhards at hq.adiscon.com  Fri Sep  5 08:11:39 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 5 Sep 2008 08:11:39 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
References: <20080820170735.GB20932@localhost.localdomain><1220521960.12304.15.camel@rgf9dev.intern.adiscon.com><20080904203155.GA6912@localhost.localdomain>
	<aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0C5@grfint2.intern.adiscon.com>

Just one additional note:

> While it is great to have documentation at all, the current one is a
> bit inconsistent and hard to navigate.

Suggestions for improvement are welcome ;)

Rainer


From rgerhards at hq.adiscon.com  Fri Sep  5 10:42:03 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 05 Sep 2008 10:42:03 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080904203155.GA6912@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
Message-ID: <1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>

Hi,

first of all, many thanks for your continued help. Please let me say
that I so far have very little experience with i18n/l10n under linux and
so may sometimes misunderstand something ;) Your detailled instructions
help much. The rest inline...

Rainer

On Fri, 2008-09-05 at 05:31 +0900, Satoru SATOH wrote:
> Hi,
> > In my POV, the man pages are now output files and as such no longer
> > something that belongs into git. I understand that this has the
> > implication that when I remove them from git, everyone who pulls the git
> > archive needs to have the proper tools in place to generate the doc.
> 
> Exactly. Addtional requirements are the followings.
> 
>  - xslt processor, xsltproc
>  - xml validator, xmllint
>  - properly configured xml catalog or internet access
>  - docbook xml dtd (local or remote)
>  - docbook xsl stylesheet for docbook-to-man transformation (local or
>    remote)
>  - xml2po in gnome-doc-utils (optional; must for translators)
> 
> I thought that not all of developers have such system and so that this
> should be avoided. This is why I disabled man-regeneration process by
> default.

I agree that this may be a problem. However, I don't think it is a very
serious one. I myself have contributed to some projects where I could
not build the documentation. This did not cause any trouble to me while
working at the program sources. Of course, if I would like to create a
full tarball, I need to have everything in place. But only few actually
needs this (am I right here?).

In contrast, the tarball must include the generated mans, as the average
user can not be expected to have the tools at hand (while we still
expect him to have everything at hand necessary to compile the program
sources).

So I would remove the files from git, but leave them within the
distribution source tarball.

> > However, is this really a problem? AFAIK other projects have similar
> > demands. So I would prefer to remove the man pages themselves from git
> > (but of course not from autotools config files, so that they be still
> > present in a release tarball).
> > 
> > Does this sound reasonable? Any objections (from anyone)?
> 
> One thing i have to mention.
> 
> Actually, man files generated from docbook xml files are slightly
> different from original man files ATM. These need some refactoring.

Could you please elaborate a bit on this? Does that mean that the
generated man files (after doing a "make") can not be immediately be
used and need some kind of (manual?) post-processing?

> 
> If it's not a matter, it would be ok.
> 
> > I also have not yet fully understood the translation workflow. If
> > the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
> > version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
> > be created with the English source doc, which I maintain)?
> 
> It is a little much complicated than that. Here are example steps for
> german (de) man pages.

thanks for the detailed instructions, I'll first do a lab to get some experience first (plus read a bit more in various docs) and post questions when/if they come up.




From rgerhards at hq.adiscon.com  Fri Sep  5 16:01:41 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 05 Sep 2008 16:01:41 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080904203155.GA6912@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
Message-ID: <1220623301.12304.61.camel@rgf9dev.intern.adiscon.com>

Hi,


On Fri, 2008-09-05 at 05:31 +0900, Satoru SATOH wrote:
> [snip]

Thanks again for the good description. I think I now understand the
process, but I would like to make sure I really do.

First of all, there seems to be a minor nit with the current set of
files. Please have a look at what happens here:

--------------------------------
[root at rgf9dev rsyslog]# xml2po -v
0.12.2
[root at rgf9dev rsyslog]# make -C man/ja create-pot
make: Entering directory `/home/rger/proj/rsyslog/man/ja'
/usr/bin/xml2po -e -o rsyslogd.8.pot ../C/rsyslogd.8.xml
Traceback (most recent call last):
  File "/usr/bin/xml2po", line 856, in <module>
    doSerialize(doc)
  File "/usr/bin/xml2po", line 589, in doSerialize
    outtxt += doSerialize(child)
  File "/usr/bin/xml2po", line 583, in doSerialize
    (starttag, content, endtag, translation) = processElementTag(node,
repl, 1)
  File "/usr/bin/xml2po", line 525, in processElementTag
    translation = translation.replace('<placeholder-%d/>' % (i),
replacement)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
4930: ordinal not in range(128)
make: *** [rsyslogd.8.pot] Error 1
make: Leaving directory `/home/rger/proj/rsyslog/man/ja'
----------------------------------

Do you have an idea how I can find out what exactly to fix (I think I
understand that there is in invalid character in rsyslogd.8.xml, but the
error message is not very helpful at pointing me at the actual trouble
source ;)).

>From an upper level view, I now understand the workflow as follows:

When I update the documentation, I update the files in ./man/C. These
are kept in docbook format and these are the only sources for the
English language documentation.

After I have updated these files, every translator needs to run 

$ make -C man/<lang> update-po

to update the PO files. The translators will work on the .po files only.
When they are (sufficiently ;)) finished, the man files need to be
regenerated. Let me elaborate a bit on this process, I'd like to get to
some details.

As far as I understand, this results in the .po files being converted
back to docbook. Then, docbook is used to generate the ultimate
destination, e.g. the man files. The same process is used to generate
the English files, except that the docbook tools are run directly,
because there were no interim .po files.

Is this description correct? I am asking because I think it would make
sense to generate different formats (man, html, pdf at least) from the
same set of source files. So I understand that .po is just an interim
step which makes translation easier, but there will be a translated
version which in turn can be processed into any format that docbook
tools support.

I'd greatly appreciate your feedback. If you know how to do it, I would
also greatly appreciate if you could provide me a patch (or
instructions) on how to generate pdf from the "man files".

Thanks,
Rainer


> > I also have not yet fully understood the translation workflow. If
> > the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
> > version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
> > be created with the English source doc, which I maintain)?
> 
> It is a little much complicated than that. Here are example steps for
> german (de) man pages.
> 
> 
> [initial translation]
> 
>   1. create mandir and makefile.am in it
> 
>      $ mkdir man/de && \
>         sed 's/LANG = ja/LANG = de/' man/ja/Makefile.am > \
>                 man/de/Makefile.am
> 
>   2. add man/de/ to SUBDIRS in man/Makefile.am
> 
>      $ sed -i 's/^\(SUBDIRS.*\)/\1 de/' man/Makefile.am
> 
>   3. add man/de/Makefile.am to AC_CONFIG_FILES in configure.ac
> 
>   4. generate man/de/Makefile.am
> 
>      $ autoreconf -vfi && ./configure --prefix=$(pwd)/i \
>         --enable-regenerate-man
> 
>   5. generate POT (PO template; language independent) and rename it 
> 
>      $ make -C man/de create-pot
>      $ mv man/de/rsyslog.conf.5.pot man/de/rsyslog.conf.5.po
>      $ mv man/de/rsyslogd.8.pot man/de/rsyslogd.8.po
> 
>   6. edit necessary header fields in PO files
> 
>      $ vim man/de/rsyslog.conf.5.po
>      $ cat man/de/rsyslog.conf.5.po
>      msgid ""
>      msgstr ""
>      "Project-Id-Version: rsyslog HEAD\n"
>      "POT-Creation-Date: 2008-09-05 04:41+0900\n"
>      "PO-Revision-Date: 2008-09-05 05:01+0900\n"
>      "Last-Translator: XXXXX YYYYY <xxxxyyyyy at example.com>\n"
>      "Language-Team: German <LL at li.org>\n"
>      "MIME-Version: 1.0\n"
>      "Content-Type: text/plain; charset=UTF-8\n"
>      "Content-Transfer-Encoding: 8bit\n"
> 
>      (snip)
> 
>   7. translate PO files
> 
>   8. generate man files
> 
>      $ ./configure --prefix=$(pwd)/i --enable-regenerate-man && make
> 
> 
> [update translations]
> 
>   1. update PO to follow changes in original docbook xml files
> 
>      $ make -C man/de update-po
> 
> 
> Please refer to man/ja/Makefile.am also. 
> 
> 
> BTW, "C" (man/C) means C (English) locale. This is the traditional dir
> name to keep original English message catalogs, I think.
> 
> - satoru
> 
> (snip)
> > > How to build:
> > > 
> > > To enable the man build process, configure have to be regenerated:
> > > 
> > >   $ (autoreconf -vfi && \
> > >         ./configure --enable-regenerate-man [...other options] && \
> > >         make && make install
> > > 
> > > 
> > > Translator's workflow:
> > > 
> > >  a. initial translation:
> > > 
> > >    0. arrange lang dir, that is, cp man/ja to man/YOUR_LANG/ and edit
> > >       Makefile.am; s/ja/YOUR_LANG/.
> > >    1. create POT: make -C man/YOUR_LANG/ create-pot
> > >    2. copy POT to PO and translate it
> > >    3. run make
> > > 
> > >  b. maintanance:
> > > 
> > >    1. update PO: make -C man/YOUR_LANG update-po
> > >    2. update translations
> > >    3. just run make
> > > 
> > > 
> > > Requirements for man regeneration / translation:
> > >  
> > >    xmllint, xsltproc, xml2po in gnome-doc-utils, DocBook DTD and DocBook
> > >    xslt stylesheet for man pages are required.
> > > 
> > >    If xmlcatalog (e.g. /etc/xml/catalog) is configured appropriately,
> > >    both xmllint and xsltproc will use local DTD and stylsheet files
> > >    instead of these from remote site
> > >    (http://www.oasis-open.org/docbook/...).
> > > 
> > > 
> > > - satoru
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From jorge.fabregas at gmail.com  Fri Sep  5 16:03:03 2008
From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=)
Date: Fri, 5 Sep 2008 10:03:03 -0400
Subject: [rsyslog] Kernel facility & testing with logger command
Message-ID: <200809051003.03373.jorge.fabregas@gmail.com>

Hello everyone,

I'm using rsyslog for the first time and before getting into its features I'm 
doing some basic tests... This is a portion of what I have on my rsyslog.conf:

#KERN FACILITY
kern.=emerg     /var/log/syslog/kern/00-emerg
kern.=alert     /var/log/syslog/kern/01-alert
kern.=crit      /var/log/syslog/kern/02-crit
kern.=err       /var/log/syslog/kern/03-err
kern.=warning   /var/log/syslog/kern/04-warning
kern.=notice    /var/log/syslog/kern/05-notice
kern.=info      /var/log/syslog/kern/06-info
kern.=debug     /var/log/syslog/kern/07-debug

If I do any test with the logger command using the kern facility (and any 
severity) I don't see my message on any of the above files. Example:

logger -p kern.debug "this is a test"

I tried all the other facilities and they all work fine. It's just the kern 
facility. 

What am I missing ?  :)

Thanks in advance,
Jorge


From rgerhards at hq.adiscon.com  Fri Sep  5 16:04:30 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 5 Sep 2008 16:04:30 +0200
Subject: [rsyslog] Kernel facility & testing with logger command
In-Reply-To: <200809051003.03373.jorge.fabregas@gmail.com>
References: <200809051003.03373.jorge.fabregas@gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0DF@grfint2.intern.adiscon.com>

Out of my head, 98% sure: logger (and/or sylsog() call and or imuxsock) does not permit to use the kernel facility. This is to prevent someone from pretending to be the kernel.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Jorge F?bregas
> Sent: Friday, September 05, 2008 4:03 PM
> To: rsyslog at lists.adiscon.com
> Subject: [rsyslog] Kernel facility & testing with logger command
> 
> Hello everyone,
> 
> I'm using rsyslog for the first time and before getting into its
> features I'm
> doing some basic tests... This is a portion of what I have on my
> rsyslog.conf:
> 
> #KERN FACILITY
> kern.=emerg     /var/log/syslog/kern/00-emerg
> kern.=alert     /var/log/syslog/kern/01-alert
> kern.=crit      /var/log/syslog/kern/02-crit
> kern.=err       /var/log/syslog/kern/03-err
> kern.=warning   /var/log/syslog/kern/04-warning
> kern.=notice    /var/log/syslog/kern/05-notice
> kern.=info      /var/log/syslog/kern/06-info
> kern.=debug     /var/log/syslog/kern/07-debug
> 
> If I do any test with the logger command using the kern facility (and
> any
> severity) I don't see my message on any of the above files. Example:
> 
> logger -p kern.debug "this is a test"
> 
> I tried all the other facilities and they all work fine. It's just the
> kern
> facility.
> 
> What am I missing ?  :)
> 
> Thanks in advance,
> Jorge
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From hks.private at gmail.com  Fri Sep  5 16:55:11 2008
From: hks.private at gmail.com ((private) HKS)
Date: Fri, 5 Sep 2008 10:55:11 -0400
Subject: [rsyslog] Kernel facility & testing with logger command
In-Reply-To: <200809051003.03373.jorge.fabregas@gmail.com>
References: <200809051003.03373.jorge.fabregas@gmail.com>
Message-ID: <ac9ded160809050755sb94c292r65a003b22237980b@mail.gmail.com>

Can you paste in your full rsyslog.conf? It's difficult to
troubleshoot without knowing how you're setup.

-HKS

On Fri, Sep 5, 2008 at 10:03 AM, Jorge F?bregas
<jorge.fabregas at gmail.com> wrote:
> Hello everyone,
>
> I'm using rsyslog for the first time and before getting into its features I'm
> doing some basic tests... This is a portion of what I have on my rsyslog.conf:
>
> #KERN FACILITY
> kern.=emerg     /var/log/syslog/kern/00-emerg
> kern.=alert     /var/log/syslog/kern/01-alert
> kern.=crit      /var/log/syslog/kern/02-crit
> kern.=err       /var/log/syslog/kern/03-err
> kern.=warning   /var/log/syslog/kern/04-warning
> kern.=notice    /var/log/syslog/kern/05-notice
> kern.=info      /var/log/syslog/kern/06-info
> kern.=debug     /var/log/syslog/kern/07-debug
>
> If I do any test with the logger command using the kern facility (and any
> severity) I don't see my message on any of the above files. Example:
>
> logger -p kern.debug "this is a test"
>
> I tried all the other facilities and they all work fine. It's just the kern
> facility.
>
> What am I missing ?  :)
>
> Thanks in advance,
> Jorge
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From hks.private at gmail.com  Fri Sep  5 16:57:54 2008
From: hks.private at gmail.com ((private) HKS)
Date: Fri, 5 Sep 2008 10:57:54 -0400
Subject: [rsyslog] Kernel facility & testing with logger command
In-Reply-To: <ac9ded160809050755sb94c292r65a003b22237980b@mail.gmail.com>
References: <200809051003.03373.jorge.fabregas@gmail.com>
	<ac9ded160809050755sb94c292r65a003b22237980b@mail.gmail.com>
Message-ID: <ac9ded160809050757h72d919d5g12e41a54c600c2bf@mail.gmail.com>

Oh, and what your platform is.

-HKS

On Fri, Sep 5, 2008 at 10:55 AM, (private) HKS <hks.private at gmail.com> wrote:
> Can you paste in your full rsyslog.conf? It's difficult to
> troubleshoot without knowing how you're setup.
>
> -HKS
>
> On Fri, Sep 5, 2008 at 10:03 AM, Jorge F?bregas
> <jorge.fabregas at gmail.com> wrote:
>> Hello everyone,
>>
>> I'm using rsyslog for the first time and before getting into its features I'm
>> doing some basic tests... This is a portion of what I have on my rsyslog.conf:
>>
>> #KERN FACILITY
>> kern.=emerg     /var/log/syslog/kern/00-emerg
>> kern.=alert     /var/log/syslog/kern/01-alert
>> kern.=crit      /var/log/syslog/kern/02-crit
>> kern.=err       /var/log/syslog/kern/03-err
>> kern.=warning   /var/log/syslog/kern/04-warning
>> kern.=notice    /var/log/syslog/kern/05-notice
>> kern.=info      /var/log/syslog/kern/06-info
>> kern.=debug     /var/log/syslog/kern/07-debug
>>
>> If I do any test with the logger command using the kern facility (and any
>> severity) I don't see my message on any of the above files. Example:
>>
>> logger -p kern.debug "this is a test"
>>
>> I tried all the other facilities and they all work fine. It's just the kern
>> facility.
>>
>> What am I missing ?  :)
>>
>> Thanks in advance,
>> Jorge
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>
>


From satoru.satoh at gmail.com  Fri Sep  5 17:28:18 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Sat, 6 Sep 2008 00:28:18 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <1220623301.12304.61.camel@rgf9dev.intern.adiscon.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
	<1220623301.12304.61.camel@rgf9dev.intern.adiscon.com>
Message-ID: <20080905152813.GA9242@localhost.localdomain>

Hi,

On Fri, Sep 05, 2008 at 04:01:41PM +0200, Rainer Gerhards wrote:
> First of all, there seems to be a minor nit with the current set of
> files. Please have a look at what happens here:
> 
> --------------------------------
> [root at rgf9dev rsyslog]# xml2po -v
> 0.12.2
> [root at rgf9dev rsyslog]# make -C man/ja create-pot
> make: Entering directory `/home/rger/proj/rsyslog/man/ja'
> /usr/bin/xml2po -e -o rsyslogd.8.pot ../C/rsyslogd.8.xml
(snip)
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
> 4930: ordinal not in range(128)
> make: *** [rsyslogd.8.pot] Error 1
> make: Leaving directory `/home/rger/proj/rsyslog/man/ja'
> ----------------------------------
> Do you have an idea how I can find out what exactly to fix (I think I
> understand that there is in invalid character in rsyslogd.8.xml, but the
> error message is not very helpful at pointing me at the actual trouble
> source ;)).
 
This is an well-known annoying issue of python. 'ascii' is the default
internal encoding so that this happens.

There are many ways to "fix" this but to upgrade the latest
gnome-doc-utils (0.13.1; this problem is solved already), looks the
best.

> >From an upper level view, I now understand the workflow as follows:
> 
> When I update the documentation, I update the files in ./man/C. These
> are kept in docbook format and these are the only sources for the
> English language documentation.
> 
> After I have updated these files, every translator needs to run 
> 
> $ make -C man/<lang> update-po
> 
> to update the PO files. The translators will work on the .po files only.

correct if [s]he or other made the required files (PO) already.

> When they are (sufficiently ;)) finished, the man files need to be
> regenerated. Let me elaborate a bit on this process, I'd like to get to
> some details.
> 
> As far as I understand, this results in the .po files being converted
> back to docbook. Then, docbook is used to generate the ultimate
> destination, e.g. the man files. The same process is used to generate
> the English files, except that the docbook tools are run directly,
> because there were no interim .po files.

exactly. DocBook XML files just play an intermediate format role 
  
  a. to generate man pages (result)
  b. to generate POT (and PO indirectly) to facilitate translation

> Is this description correct? I am asking because I think it would make
> sense to generate different formats (man, html, pdf at least) from the
> same set of source files. So I understand that .po is just an interim
> step which makes translation easier, but there will be a translated
> version which in turn can be processed into any format that docbook
> tools support.

absolutely correct.

> I'd greatly appreciate your feedback. If you know how to do it, I would
> also greatly appreciate if you could provide me a patch (or
> instructions) on how to generate pdf from the "man files".
(snip)

OK, I'll try to make it. wait for a while, please.

Unfortunatelly, xml to pdf transformation process is much complicate
than html/man/other text based formats and it brings another
dependencies - fonts and XSL-FO processor :-P

- satoru


From satoru.satoh at gmail.com  Fri Sep  5 17:59:35 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Sat, 6 Sep 2008 00:59:35 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
	<1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>
Message-ID: <20080905155931.GB9242@localhost.localdomain>

On Fri, Sep 05, 2008 at 10:42:03AM +0200, Rainer Gerhards wrote:
> > I thought that not all of developers have such system and so that this
> > should be avoided. This is why I disabled man-regeneration process by
> > default.
> 
> I agree that this may be a problem. However, I don't think it is a very
> serious one. I myself have contributed to some projects where I could
> not build the documentation. This did not cause any trouble to me while
> working at the program sources. Of course, if I would like to create a
> full tarball, I need to have everything in place. But only few actually
> needs this (am I right here?).

right. Who needs required tools and files are

 a. developers do git-pull *and* modify man sources
 b. translators contribute initial translation or update it
 c. others just want ;-) to switch on '--enable-regenerate-man' option

> In contrast, the tarball must include the generated mans, as the average
> user can not be expected to have the tools at hand (while we still
> expect him to have everything at hand necessary to compile the program
> sources).
(snip)
 
This should be accomplished already, I think.

I made all related stuff (xml, po, man) in EXTRA_DIST so that these will
be in the archive generated by 'make dist'. 

> > Actually, man files generated from docbook xml files are slightly
> > different from original man files ATM. These need some refactoring.
> 
> Could you please elaborate a bit on this? Does that mean that the
> generated man files (after doing a "make") can not be immediately be
> used and need some kind of (manual?) post-processing?
 
No. There should be no any problems to convert xml files to man pages
but the result *looks* may different.

Transition from man (roff) to DocBook XML is similar to the transition
from old HTML to XHTML + CSS. The authors/editors/writers have to
concentrate attention at the *logical* structure of the text instead of
its appearance.

It's typical that many HTML tags to control appearance found in old HTML
sources and it makes impossible to keep complete same look in new XHTML
+ CSS sources.

- satoru


From rgerhards at hq.adiscon.com  Mon Sep  8 10:24:56 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 8 Sep 2008 10:24:56 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080905155931.GB9242@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain><1220521960.12304.15.camel@rgf9dev.intern.adiscon.com><20080904203155.GA6912@localhost.localdomain><1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>
	<20080905155931.GB9242@localhost.localdomain>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0E6@grfint2.intern.adiscon.com>

Hi,

thanks again for your insight. I'll now remove the (generated) man files
from git, but will leave them inside the tarball. I think that is a
workable solution.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Satoru SATOH
> Sent: Friday, September 05, 2008 6:00 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] [PATCH] man-i18n patches summary
> 
> On Fri, Sep 05, 2008 at 10:42:03AM +0200, Rainer Gerhards wrote:
> > > I thought that not all of developers have such system and so that
> this
> > > should be avoided. This is why I disabled man-regeneration process
> by
> > > default.
> >
> > I agree that this may be a problem. However, I don't think it is a
> very
> > serious one. I myself have contributed to some projects where I
could
> > not build the documentation. This did not cause any trouble to me
> while
> > working at the program sources. Of course, if I would like to create
> a
> > full tarball, I need to have everything in place. But only few
> actually
> > needs this (am I right here?).
> 
> right. Who needs required tools and files are
> 
>  a. developers do git-pull *and* modify man sources
>  b. translators contribute initial translation or update it
>  c. others just want ;-) to switch on '--enable-regenerate-man' option
> 
> > In contrast, the tarball must include the generated mans, as the
> average
> > user can not be expected to have the tools at hand (while we still
> > expect him to have everything at hand necessary to compile the
> program
> > sources).
> (snip)
> 
> This should be accomplished already, I think.
> 
> I made all related stuff (xml, po, man) in EXTRA_DIST so that these
> will
> be in the archive generated by 'make dist'.
> 
> > > Actually, man files generated from docbook xml files are slightly
> > > different from original man files ATM. These need some
refactoring.
> >
> > Could you please elaborate a bit on this? Does that mean that the
> > generated man files (after doing a "make") can not be immediately be
> > used and need some kind of (manual?) post-processing?
> 
> No. There should be no any problems to convert xml files to man pages
> but the result *looks* may different.
> 
> Transition from man (roff) to DocBook XML is similar to the transition
> from old HTML to XHTML + CSS. The authors/editors/writers have to
> concentrate attention at the *logical* structure of the text instead
of
> its appearance.
> 
> It's typical that many HTML tags to control appearance found in old
> HTML
> sources and it makes impossible to keep complete same look in new
XHTML
> + CSS sources.
> 
> - satoru
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Thu Sep 11 15:27:49 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 11 Sep 2008 15:27:49 +0200
Subject: [rsyslog] docbook and math
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F12B@grfint2.intern.adiscon.com>

Hi folks,

and especially those that are proficient with docbook ;) I have one
question. I am thinking about a series of design papers. I think,
however, that at least some of them will require a lot of mathematical
formulas. Typically, I'd say that should be done in LaTeX. But with
moving to docbook for the user doc, it may be good to use a single
system.

I have now investigated docbook and maths a bit, but what I found didn't
look very promising. The best I found was MathML, which is far too
verbose for any hand-editing (and I don't want to rely on specialized
formula editors). I also found some references to embedded TeX, but that
looked quite hackish.

Could somebody enlighten me on the current typical approach for such
papers? Do they still usually go the LaTeX way or is there a good way to
do it with docbook?

Many thanks in advance,
Rainer


From david at lang.hm  Mon Sep 15 07:30:15 2008
From: david at lang.hm (david at lang.hm)
Date: Sun, 14 Sep 2008 22:30:15 -0700 (PDT)
Subject: [rsyslog] making a custom input module
Message-ID: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>

my second project is to try and modify rsyslog to recieve logs from an 
application. the application sends the logs over TCP and expects an 
application-level handshake (very similar to relp). at the moment I want 
to try and avoid having to change the application (many different products 
with different release schedules), and instead teach rsyslog to deal with 
the existing log format.

at the moment I am trying to understand the imtcp module, but I am getting 
lost in the callbacks. it looks like rsyslog is calling a routine in 
imtcp, which calls a routine in tcpsrv, which calls a routine somewhere 
else to actually recieve the log.

ideally what I would like to use is to take imtcp and replace the message 
recieving/parsing logic with my own, then have it submit the parsed 
message into the queue (which looks like it would be via the SubmitMsg() 
call).

but at the moment I am lost in the twisty maze of function calls between 
source files, all of which look different.

I'm also not clear on what fields inside of the Msg structure need to be 
populated. looking at Msg.c/h I see a lot of fields there, but it looks 
like many/most of them are optional.

any pointers?

David Lang


From david at lang.hm  Mon Sep 15 07:23:11 2008
From: david at lang.hm (david at lang.hm)
Date: Sun, 14 Sep 2008 22:23:11 -0700 (PDT)
Subject: [rsyslog] optimization questions
Message-ID: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>

I've got a couple projects I'm working on that rsyslog is looking like a 
good answer to. I'm going to send questions about them in seperate 
messages.

the first project is a traditional syslog server. I've been testing 
various syslog implementations to find out what sort of performance they 
can sustain.

I've gotten the (almost) standard sysklogd to sustail almost 30,000 
messages/sec (udp) before it starts loosing significant numbers of logs

rsyslog is able to handle bursts of around 150,000 messages/sec, but it 
doesn't seem to write them out very fast, and over time seems to be 
limited to ~22,000 messages/sec

the hardware I am running this test on is insanely overpowered (four 
dual-core opterons, 16G of ram, battery-backed cache on a raid card with 
high-speed SAS drives). in production I will be working with slower 
hardware, but I'm trying to find the limits of the software before I start 
introducing lower hardware limits.

what can I look at doing to speed up the writing of data from the queues? 
does rsyslog write the messages one at a time, or does it have an option 
for writing them in batches (pulling a bunch off of the queue and sending 
them all at once)?

some sort of batch mode would be critical for writes to a database where 
you can frequently get 1000x speedups if you do the inserts as a single 
transaction as opposed to individual transactions.

David Lang


From david at lang.hm  Mon Sep 15 08:13:43 2008
From: david at lang.hm (david at lang.hm)
Date: Sun, 14 Sep 2008 23:13:43 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
Message-ID: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>

looking through the rsyslog.conf man page I see ways to tell rsyslogd to 
run a command when a file is over a given size, but I see no examples or 
details of what that command can/should do.

what I want to do is to move the file out of the way, kick rsyslogd so 
that it starts writing to a new file, then compress the old file (which 
can take a significant amount of time)

traditionally I have rotated syslogs by doing a mv of the logfile followed 
by a kill -HUP of the syslog process (usually out of crontab)

In my testing of rsyslog I have been doing this, but once in a while 
rsyslog doesn't release the file it's writing and start a new one, instead 
it keeps writing to the old file.

so this means that my command can't spawn a background task that does a mv 
of the file followed by a kill -HUP of rsyslogd.

what should I be doing?

David Lang



From rgerhards at hq.adiscon.com  Mon Sep 15 08:39:24 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 08:39:24 +0200
Subject: [rsyslog] optimization questions
In-Reply-To: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>
Message-ID: <1221460764.2682.9.camel@rgf9dev.intern.adiscon.com>

Hi David,

thanks for your message and interest. This is very welcome as I would
really like to get hold of more insight into rsyslog's performance in
real-world and extreme scenarios. So far, I have unfortunately been
unable to do that, because I had no funding for the required hardware
and time to conduct the testing. I would *really* appreciate if you
could help with that and I would be very willing to tweak the code for
optimum performance (actually, I am always very concerned about high
performance and I was a bit sad about the fact that I could not ensure
it).

Having said that, I'd first of all would like to have a look at your
rsyslog.conf, so that we are on common ground. Also, I think, this can
become quite lengthy and also of interest for others. May it be useful
to discuss this on the web forum, so that we can easier keep track of
things. If you think this is useful, I recommend this one here:

http://kb.monitorware.com/general-f34.html

some more comments inline:

On Mon, 2008-09-15 at 07:23 +0200, david at lang.hm wrote:
> I've got a couple projects I'm working on that rsyslog is looking like
> a
> good answer to. I'm going to send questions about them in seperate
> messages.
> 
> the first project is a traditional syslog server. I've been testing
> various syslog implementations to find out what sort of performance
> they
> can sustain.
> 
> I've gotten the (almost) standard sysklogd to sustail almost 30,000
> messages/sec (udp) before it starts loosing significant numbers of
> logs
> 
> rsyslog is able to handle bursts of around 150,000 messages/sec, but
> it
> doesn't seem to write them out very fast, and over time seems to be
> limited to ~22,000 messages/sec
> 
> the hardware I am running this test on is insanely overpowered (four
> dual-core opterons, 16G of ram, battery-backed cache on a raid card
> with
> high-speed SAS drives). in production I will be working with slower
> hardware, but I'm trying to find the limits of the software before I
> start
> introducing lower hardware limits.
> 
> what can I look at doing to speed up the writing of data from the
> queues?
> does rsyslog write the messages one at a time, or does it have an
> option
> for writing them in batches (pulling a bunch off of the queue and
> sending
> them all at once)?

The design is that each individual message is pushed to the output. The
output than writes the message. There has been discussion about a lazy
write, but nothing in this regard has yet been implemented.

Note that this is a good time to request new things. I am finished with
the last major thing (TLS) support and in front of the next one
(enhanced scripting), but scripting, I think, could be moved to a later
time in favour of something more important (like performance ;)).
> 
> some sort of batch mode would be critical for writes to a database
> where
> you can frequently get 1000x speedups if you do the inserts as a
> single
> transaction as opposed to individual transactions.

I am not (any longer) so much a database guy. Can I really do a batch
insert with them? Can you point me to an API?

Looking forward to your reply!
Rainer




From rgerhards at hq.adiscon.com  Mon Sep 15 08:47:13 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 08:47:13 +0200
Subject: [rsyslog] making a custom input module
In-Reply-To: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
Message-ID: <1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>

On Sun, 2008-09-14 at 22:30 -0700, david at lang.hm wrote:
> my second project is to try and modify rsyslog to recieve logs from an 
> application. the application sends the logs over TCP and expects an 
> application-level handshake (very similar to relp). at the moment I want 
> to try and avoid having to change the application (many different products 
> with different release schedules), and instead teach rsyslog to deal with 
> the existing log format.
> 
> at the moment I am trying to understand the imtcp module, but I am getting 
> lost in the callbacks. it looks like rsyslog is calling a routine in 
> imtcp, which calls a routine in tcpsrv, which calls a routine somewhere 
> else to actually recieve the log.

The imtcp module has a lot of history and too complex code. This all
stems back to various stages of GSSAPI integration. Things have been
simplified with the introduction of the transport stream layer, but the
imtcp module does not yet reflect this simplicity. So far, I am hesitant
to split these things, because we still do not have a clean gssapi
netstream driver.

I can tell you where you need to provide callbacks ... or you could
start from imrelp, which in regard means mostly from scratch, but
actually receiving tcp isn't rocket science, so it may be easier to
start with a proper template without tcp functionality and integrate
your tcp reception code into it. What do you (think ;)) you prefer?

> ideally what I would like to use is to take imtcp and replace the message 
> recieving/parsing logic with my own, then have it submit the parsed 
> message into the queue (which looks like it would be via the SubmitMsg() 
> call).
> 
> but at the moment I am lost in the twisty maze of function calls between 
> source files, all of which look different.
> 
> I'm also not clear on what fields inside of the Msg structure need to be 
> populated. looking at Msg.c/h I see a lot of fields there, but it looks 
> like many/most of them are optional.

look at imfile. This is what you need:

	CHKiRet(msgConstruct(&pMsg));
	MsgSetFlowControlType(pMsg, eFLOWCTL_FULL_DELAY);
	MsgSetInputName(pMsg, "imfile");
	MsgSetUxTradMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
	MsgSetRawMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
	MsgSetMSG(pMsg, (char*)rsCStrGetSzStr(cstrLine));
	MsgSetHOSTNAME(pMsg, (char*)glbl.GetLocalHostName());
	MsgSetTAG(pMsg, (char*)pInfo->pszTag);
	pMsg->iFacility = LOG_FAC(pInfo->iFacility);
	pMsg->iSeverity = LOG_PRI(pInfo->iSeverity);
	pMsg->bParseHOSTNAME = 0;
	datetime.getCurrTime(&(pMsg->tTIMESTAMP)); /* use the current time! */
	CHKiRet(submitMsg(pMsg))

Also look at imtemplate, which is a template input module. Sometimes it
is a bit outdated, if you have a problem during compile, tell me ;)

Rainer
> 
> any pointers?
> 
> David Lang
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep 15 08:54:59 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 08:54:59 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
Message-ID: <1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>

This, too, is quite old, to-be-replaced on demand functionality ...
without any demand for replacement up to now ;)

Do you know this guide:
http://www.rsyslog.com/doc-log_rotation_fix_size.html

The shell script could spawn off an async process, but I have never
tried this...

Also <inline>:
On Sun, 2008-09-14 at 23:13 -0700, david at lang.hm wrote:
> looking through the rsyslog.conf man page I see ways to tell rsyslogd to 
> run a command when a file is over a given size, but I see no examples or 
> details of what that command can/should do.
> 
> what I want to do is to move the file out of the way, kick rsyslogd so 
> that it starts writing to a new file, then compress the old file (which 
> can take a significant amount of time)
> 
> traditionally I have rotated syslogs by doing a mv of the logfile followed 
> by a kill -HUP of the syslog process (usually out of crontab)
> 
> In my testing of rsyslog I have been doing this, but once in a while 
> rsyslog doesn't release the file it's writing and start a new one, instead 
> it keeps writing to the old file.

This very much smells like a bug. Can you elaborate on what you did?

> 
> so this means that my command can't spawn a background task that does a mv 
> of the file followed by a kill -HUP of rsyslogd.
> 
> what should I be doing?
> 
> David Lang
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From david at lang.hm  Mon Sep 15 09:01:40 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:01:40 -0700 (PDT)
Subject: [rsyslog] optimization questions
In-Reply-To: <1221460764.2682.9.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>
	<1221460764.2682.9.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150001160.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> Hi David,
>
> thanks for your message and interest. This is very welcome as I would
> really like to get hold of more insight into rsyslog's performance in
> real-world and extreme scenarios. So far, I have unfortunately been
> unable to do that, because I had no funding for the required hardware
> and time to conduct the testing. I would *really* appreciate if you
> could help with that and I would be very willing to tweak the code for
> optimum performance (actually, I am always very concerned about high
> performance and I was a bit sad about the fact that I could not ensure
> it).
>
> Having said that, I'd first of all would like to have a look at your
> rsyslog.conf, so that we are on common ground. Also, I think, this can
> become quite lengthy and also of interest for others. May it be useful
> to discuss this on the web forum, so that we can easier keep track of
> things. If you think this is useful, I recommend this one here:
>
> http://kb.monitorware.com/general-f34.html

done, I created a topic in the developers corner

David Lang

> some more comments inline:
>
> On Mon, 2008-09-15 at 07:23 +0200, david at lang.hm wrote:
>> I've got a couple projects I'm working on that rsyslog is looking like
>> a
>> good answer to. I'm going to send questions about them in seperate
>> messages.
>>
>> the first project is a traditional syslog server. I've been testing
>> various syslog implementations to find out what sort of performance
>> they
>> can sustain.
>>
>> I've gotten the (almost) standard sysklogd to sustail almost 30,000
>> messages/sec (udp) before it starts loosing significant numbers of
>> logs
>>
>> rsyslog is able to handle bursts of around 150,000 messages/sec, but
>> it
>> doesn't seem to write them out very fast, and over time seems to be
>> limited to ~22,000 messages/sec
>>
>> the hardware I am running this test on is insanely overpowered (four
>> dual-core opterons, 16G of ram, battery-backed cache on a raid card
>> with
>> high-speed SAS drives). in production I will be working with slower
>> hardware, but I'm trying to find the limits of the software before I
>> start
>> introducing lower hardware limits.
>>
>> what can I look at doing to speed up the writing of data from the
>> queues?
>> does rsyslog write the messages one at a time, or does it have an
>> option
>> for writing them in batches (pulling a bunch off of the queue and
>> sending
>> them all at once)?
>
> The design is that each individual message is pushed to the output. The
> output than writes the message. There has been discussion about a lazy
> write, but nothing in this regard has yet been implemented.
>
> Note that this is a good time to request new things. I am finished with
> the last major thing (TLS) support and in front of the next one
> (enhanced scripting), but scripting, I think, could be moved to a later
> time in favour of something more important (like performance ;)).
>>
>> some sort of batch mode would be critical for writes to a database
>> where
>> you can frequently get 1000x speedups if you do the inserts as a
>> single
>> transaction as opposed to individual transactions.
>
> I am not (any longer) so much a database guy. Can I really do a batch
> insert with them? Can you point me to an API?
>
> Looking forward to your reply!
> Rainer
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From david at lang.hm  Mon Sep 15 09:10:42 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:10:42 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> This, too, is quite old, to-be-replaced on demand functionality ...
> without any demand for replacement up to now ;)
>
> Do you know this guide:
> http://www.rsyslog.com/doc-log_rotation_fix_size.html
>
> The shell script could spawn off an async process, but I have never
> tried this...
>
> Also <inline>:
> On Sun, 2008-09-14 at 23:13 -0700, david at lang.hm wrote:
>> looking through the rsyslog.conf man page I see ways to tell rsyslogd to
>> run a command when a file is over a given size, but I see no examples or
>> details of what that command can/should do.
>>
>> what I want to do is to move the file out of the way, kick rsyslogd so
>> that it starts writing to a new file, then compress the old file (which
>> can take a significant amount of time)
>>
>> traditionally I have rotated syslogs by doing a mv of the logfile followed
>> by a kill -HUP of the syslog process (usually out of crontab)
>>
>> In my testing of rsyslog I have been doing this, but once in a while
>> rsyslog doesn't release the file it's writing and start a new one, instead
>> it keeps writing to the old file.
>
> This very much smells like a bug. Can you elaborate on what you did?

rsyslogd 3.18.3 on one machine with the config file

$ModLoad immark
$MarkMessagePeriod 1200
$ModLoad imuxsock
$ModLoad imudp
$ModLoad imklog
$UDPServerRun 514
$AllowedSender UDP, 127.0.0.1, 192.0.0.0/8
$umask 0000
$FileGroup root
$FileOwner root
$template TraditionalFormat,"%timegenerated% %HOSTNAME% 
%syslogtag%%msg:::drop-last-lf%\n"
*.*     /var/log/messages;TraditionalFormat      # log to a file in the 
traditional format

tcpreplay on a second machine spewing log entries at it at a rate of 
~30,000 logs/sec

crontab running the following script every 5 min

#!/bin/sh
#

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

umask 022
year=`date +%Y`
month=`date +%m`
day=`date +%d`
fdate=`date +%Y%m%d.%H%M`
logroot=/var/log
logroll=$logroot/oldlogs

cd $logroot
mkdir -p $logroll/$year/$month/$day >/dev/null 2>/dev/null
mv messages $logroll/$year/$month/$day/messages.$fdate
pkill -HUP rsyslogd
2>/dev/null &
gzip -9 $logroll/$year/$month/$day/messages.$fdate


I get a couple of rotations sucessfully (with ~22,000 logs/sec in the 
files), but then rsyslog seems to hang.
lsof show it with the file open that was moved (and later deleted by 
gzip).
I need to do a kill -9 of rsyslogd to get it to recover.

David Lang

>>
>> so this means that my command can't spawn a background task that does a mv
>> of the file followed by a kill -HUP of rsyslogd.
>>
>> what should I be doing?
>>
>> David Lang
>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Mon Sep 15 09:13:16 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:13:16 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
Message-ID: <1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:10 -0700, david at lang.hm wrote:
> > This very much smells like a bug. Can you elaborate on what you did?
> 
> rsyslogd 3.18.3 on one machine with the config file
> 
> $ModLoad immark
> $MarkMessagePeriod 1200
> $ModLoad imuxsock
> $ModLoad imudp
> $ModLoad imklog
> $UDPServerRun 514
> $AllowedSender UDP, 127.0.0.1, 192.0.0.0/8
> $umask 0000
> $FileGroup root
> $FileOwner root
> $template TraditionalFormat,"%timegenerated% %HOSTNAME% 
> %syslogtag%%msg:::drop-last-lf%\n"
> *.*     /var/log/messages;TraditionalFormat      # log to a file in the 
> traditional format
> 
> tcpreplay on a second machine spewing log entries at it at a rate of 
> ~30,000 logs/sec
> 
> crontab running the following script every 5 min
> 
> #!/bin/sh
> #
> 
> PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
> 
> umask 022
> year=`date +%Y`
> month=`date +%m`
> day=`date +%d`
> fdate=`date +%Y%m%d.%H%M`
> logroot=/var/log
> logroll=$logroot/oldlogs
> 
> cd $logroot
> mkdir -p $logroll/$year/$month/$day >/dev/null 2>/dev/null
> mv messages $logroll/$year/$month/$day/messages.$fdate
> pkill -HUP rsyslogd
> 2>/dev/null &
> gzip -9 $logroll/$year/$month/$day/messages.$fdate
> 
> 
> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the 
> files), but then rsyslog seems to hang.
> lsof show it with the file open that was moved (and later deleted by 
> gzip).
> I need to do a kill -9 of rsyslogd to get it to recover.

Definitely a bug... I now "just" need to find out where. I guess there
is some mutex issue in the queue engine during shutdown. Don't expect a
fix too soon, but I'll do my best. I hope I can find a simpler error
condition (if my conclusion on the problem source is right...)

Rainer



From david at lang.hm  Mon Sep 15 09:16:23 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:16:23 -0700 (PDT)
Subject: [rsyslog] making a custom input module
In-Reply-To: <1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
	<1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Sun, 2008-09-14 at 22:30 -0700, david at lang.hm wrote:
>> my second project is to try and modify rsyslog to recieve logs from an
>> application. the application sends the logs over TCP and expects an
>> application-level handshake (very similar to relp). at the moment I want
>> to try and avoid having to change the application (many different products
>> with different release schedules), and instead teach rsyslog to deal with
>> the existing log format.
>>
>> at the moment I am trying to understand the imtcp module, but I am getting
>> lost in the callbacks. it looks like rsyslog is calling a routine in
>> imtcp, which calls a routine in tcpsrv, which calls a routine somewhere
>> else to actually recieve the log.
>
> The imtcp module has a lot of history and too complex code. This all
> stems back to various stages of GSSAPI integration. Things have been
> simplified with the introduction of the transport stream layer, but the
> imtcp module does not yet reflect this simplicity. So far, I am hesitant
> to split these things, because we still do not have a clean gssapi
> netstream driver.
>
> I can tell you where you need to provide callbacks ... or you could
> start from imrelp, which in regard means mostly from scratch, but
> actually receiving tcp isn't rocket science, so it may be easier to
> start with a proper template without tcp functionality and integrate
> your tcp reception code into it. What do you (think ;)) you prefer?

the simpler the better. I'm pretty rusty with my C and I never did much 
network or threaded programming in the first place, so while I can debug 
programs in any language, I'm currently not much beyond the cut-n-past 
stage here.

it sounds like I should not start from imtcp.

however when I looked at imrelp it looked like everything in in the relp 
libraries, and I was hoping to avoid diving into them for the moment.

are any of the other tcp-based transports in better shape? or should I 
start from scratch with the imtemplate plugin?

David Lang

>> ideally what I would like to use is to take imtcp and replace the message
>> recieving/parsing logic with my own, then have it submit the parsed
>> message into the queue (which looks like it would be via the SubmitMsg()
>> call).
>>
>> but at the moment I am lost in the twisty maze of function calls between
>> source files, all of which look different.
>>
>> I'm also not clear on what fields inside of the Msg structure need to be
>> populated. looking at Msg.c/h I see a lot of fields there, but it looks
>> like many/most of them are optional.
>
> look at imfile. This is what you need:
>
> 	CHKiRet(msgConstruct(&pMsg));
> 	MsgSetFlowControlType(pMsg, eFLOWCTL_FULL_DELAY);
> 	MsgSetInputName(pMsg, "imfile");
> 	MsgSetUxTradMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
> 	MsgSetRawMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
> 	MsgSetMSG(pMsg, (char*)rsCStrGetSzStr(cstrLine));
> 	MsgSetHOSTNAME(pMsg, (char*)glbl.GetLocalHostName());
> 	MsgSetTAG(pMsg, (char*)pInfo->pszTag);
> 	pMsg->iFacility = LOG_FAC(pInfo->iFacility);
> 	pMsg->iSeverity = LOG_PRI(pInfo->iSeverity);
> 	pMsg->bParseHOSTNAME = 0;
> 	datetime.getCurrTime(&(pMsg->tTIMESTAMP)); /* use the current time! */
> 	CHKiRet(submitMsg(pMsg))
>
> Also look at imtemplate, which is a template input module. Sometimes it
> is a bit outdated, if you have a problem during compile, tell me ;)
>
> Rainer
>>
>> any pointers?
>>
>> David Lang
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From david at lang.hm  Mon Sep 15 09:17:47 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:17:47 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

>> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the
>> files), but then rsyslog seems to hang.
>> lsof show it with the file open that was moved (and later deleted by
>> gzip).
>> I need to do a kill -9 of rsyslogd to get it to recover.
>
> Definitely a bug... I now "just" need to find out where. I guess there
> is some mutex issue in the queue engine during shutdown. Don't expect a
> fix too soon, but I'll do my best. I hope I can find a simpler error
> condition (if my conclusion on the problem source is right...)

let me know if you need me to try anything. given the volume of logs I 
don't know if it would be worth trying to do a strace.

David Lang


From rgerhards at hq.adiscon.com  Mon Sep 15 09:19:43 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:19:43 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
Message-ID: <1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:17 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> >> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the
> >> files), but then rsyslog seems to hang.
> >> lsof show it with the file open that was moved (and later deleted by
> >> gzip).
> >> I need to do a kill -9 of rsyslogd to get it to recover.
> >
> > Definitely a bug... I now "just" need to find out where. I guess there
> > is some mutex issue in the queue engine during shutdown. Don't expect a
> > fix too soon, but I'll do my best. I hope I can find a simpler error
> > condition (if my conclusion on the problem source is right...)
> 
> let me know if you need me to try anything. given the volume of logs I 
> don't know if it would be worth trying to do a strace.

I agree, it doesn't make any sense. It may be worth trying to run
rsyslog with runtime instrumentation turned on in debug mode. That will
generate tons of debug output and it will make things awfully slow, but
at least we may be able to get some information out of it.

... well... one thing: could you run an unmodified version of WinSyslog
under valgrind and let me know if there are any valgrind exceptions
before it hangs? This, too, will make it very slow, but I guess/hope
that doesn't affect the outcome.

Rainer



From rgerhards at hq.adiscon.com  Mon Sep 15 09:20:57 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:20:57 +0200
Subject: [rsyslog] making a custom input module
In-Reply-To: <alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
	<1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>
Message-ID: <1221463257.2682.34.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:16 -0700, david at lang.hm wrote:
> the simpler the better. I'm pretty rusty with my C and I never did much 
> network or threaded programming in the first place, so while I can debug 
> programs in any language, I'm currently not much beyond the cut-n-past 
> stage here.
> 
> it sounds like I should not start from imtcp.
> 
> however when I looked at imrelp it looked like everything in in the relp 
> libraries, and I was hoping to avoid diving into them for the moment.
> 
> are any of the other tcp-based transports in better shape? or should I 
> start from scratch with the imtemplate plugin?

Bear a bit with me (but ping me if I don't reply by mid-week). I'll have
a look and recommend the way I think is best given the constraints.

Rainer



From david at lang.hm  Mon Sep 15 09:26:57 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:26:57 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:17 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>
>>>> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the
>>>> files), but then rsyslog seems to hang.
>>>> lsof show it with the file open that was moved (and later deleted by
>>>> gzip).
>>>> I need to do a kill -9 of rsyslogd to get it to recover.
>>>
>>> Definitely a bug... I now "just" need to find out where. I guess there
>>> is some mutex issue in the queue engine during shutdown. Don't expect a
>>> fix too soon, but I'll do my best. I hope I can find a simpler error
>>> condition (if my conclusion on the problem source is right...)
>>
>> let me know if you need me to try anything. given the volume of logs I
>> don't know if it would be worth trying to do a strace.
>
> I agree, it doesn't make any sense. It may be worth trying to run
> rsyslog with runtime instrumentation turned on in debug mode. That will
> generate tons of debug output and it will make things awfully slow, but
> at least we may be able to get some information out of it.

do I need to recompile it, or is it a config/command line option?

> ... well... one thing: could you run an unmodified version of WinSyslog
> under valgrind and let me know if there are any valgrind exceptions
> before it hangs? This, too, will make it very slow, but I guess/hope
> that doesn't affect the outcome.

I'm running on linux machines, so I don't know if WinSyslog can be made to 
work. I would need to be pointed at the source.

David Lang


From david at lang.hm  Mon Sep 15 09:27:47 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:27:47 -0700 (PDT)
Subject: [rsyslog] making a custom input module
In-Reply-To: <1221463257.2682.34.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
	<1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>
	<1221463257.2682.34.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150027110.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:16 -0700, david at lang.hm wrote:
>> the simpler the better. I'm pretty rusty with my C and I never did much
>> network or threaded programming in the first place, so while I can debug
>> programs in any language, I'm currently not much beyond the cut-n-past
>> stage here.
>>
>> it sounds like I should not start from imtcp.
>>
>> however when I looked at imrelp it looked like everything in in the relp
>> libraries, and I was hoping to avoid diving into them for the moment.
>>
>> are any of the other tcp-based transports in better shape? or should I
>> start from scratch with the imtemplate plugin?
>
> Bear a bit with me (but ping me if I don't reply by mid-week). I'll have
> a look and recommend the way I think is best given the constraints.

Ok, in the meantime I'll forget about trying to untangle imtcp and see 
what I can do seperatly.

David Lang


From rgerhards at hq.adiscon.com  Mon Sep 15 09:28:04 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:28:04 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
Message-ID: <1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:26 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> > I agree, it doesn't make any sense. It may be worth trying to run
> > rsyslog with runtime instrumentation turned on in debug mode. That will
> > generate tons of debug output and it will make things awfully slow, but
> > at least we may be able to get some information out of it.
> 
> do I need to recompile it, or is it a config/command line option?

you need to compile it, but let's do the valgrind test first (less
effort required).
> 
> > ... well... one thing: could you run an unmodified version of WinSyslog
> > under valgrind and let me know if there are any valgrind exceptions
> > before it hangs? This, too, will make it very slow, but I guess/hope
> > that doesn't affect the outcome.
> 
> I'm running on linux machines, so I don't know if WinSyslog can be made to 
> work. I would need to be pointed at the source.

lol - that happens if you have two conversations open at one time ;) Actually, I meant rsyslog. Forget about the WinSyslog part ;)

Rainer



From david at lang.hm  Mon Sep 15 09:34:17 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:34:17 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:26 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>
>>> I agree, it doesn't make any sense. It may be worth trying to run
>>> rsyslog with runtime instrumentation turned on in debug mode. That will
>>> generate tons of debug output and it will make things awfully slow, but
>>> at least we may be able to get some information out of it.
>>
>> do I need to recompile it, or is it a config/command line option?
>
> you need to compile it, but let's do the valgrind test first (less
> effort required).
>>
>>> ... well... one thing: could you run an unmodified version of WinSyslog
>>> under valgrind and let me know if there are any valgrind exceptions
>>> before it hangs? This, too, will make it very slow, but I guess/hope
>>> that doesn't affect the outcome.
>>
>> I'm running on linux machines, so I don't know if WinSyslog can be made to
>> work. I would need to be pointed at the source.
>
> lol - that happens if you have two conversations open at one time ;) Actually, I meant rsyslog. Forget about the WinSyslog part ;)

ok, I've never run vagrind, let me see what I can find.

David Lang


From rgerhards at hq.adiscon.com  Mon Sep 15 09:37:20 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:37:20 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
Message-ID: <1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:34 -0700, david at lang.hm wrote:
> ok, I've never run vagrind, let me see what I can find.

It's far easier than I thought when I used valgrind for the first time:
simply install a recent release and start rsyslog as usual, just add
"valgrind" before rsyslog (so valgrind is the command and rsyslog an
arguement". e.g.

$ ./rsyslogd -c3

becomes

$ valgrind ./rsyslogd -c3

That's it! :-)

There are a couple of options for valgrind, but for starters the defaults are fine.

Rainer



From david at lang.hm  Mon Sep 15 09:53:41 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:53:41 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> Date: Mon, 15 Sep 2008 09:37:20 +0200
> From: Rainer Gerhards <rgerhards at hq.adiscon.com>
> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
> To: rsyslog-users <rsyslog at lists.adiscon.com>
> Subject: Re: [rsyslog] how to best rotate files
> 
> On Mon, 2008-09-15 at 00:34 -0700, david at lang.hm wrote:
>> ok, I've never run vagrind, let me see what I can find.
>
> It's far easier than I thought when I used valgrind for the first time:
> simply install a recent release and start rsyslog as usual, just add
> "valgrind" before rsyslog (so valgrind is the command and rsyslog an
> arguement". e.g.
>
> $ ./rsyslogd -c3
>
> becomes
>
> $ valgrind ./rsyslogd -c3
>
> That's it! :-)
>
> There are a couple of options for valgrind, but for starters the defaults are fine.

I did --trace-children=yes (otherwise it wouldn't stay attached) and 
--leak-detail=yes (since it seemed to report memory leaks in the first 
run)

this seemed to run into problems with the first rotation (which given that 
there was no process to do a kill -HUP on, isn't surprising)

David Lang

==10726== Memcheck, a memory error detector.
==10726== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==10726== Using LibVEX rev 1658, a library for dynamic binary translation.
==10726== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==10726== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.
==10726== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==10726== For more details, rerun with: -v
==10726==
==10726== My PID = 10726, parent PID = 13696.  Prog and args are:
==10726==    /usr/local/sbin/rsyslogd
==10726==    -c3
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x40091D5: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x40091DE: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010B04: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010C61: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006E47: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Invalid read of size 8
==10726==    at 0x4010C54: (within /lib/ld-2.3.6.so)
==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10726==    by 0x4007113: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010A70: (within /lib/ld-2.3.6.so)
==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006117: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10726==    by 0x4008B91: (within /lib/ld-2.3.6.so)
==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Invalid read of size 8
==10726==    at 0x4010C20: (within /lib/ld-2.3.6.so)
==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10726==    by 0x4006123: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
==10726== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
==10726== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
==10726== For counts of detected errors, rerun with: -v
==10726== searching for pointers to 437 not-freed blocks.
==10726== checked 172,368 bytes.
==10726==
==10726== LEAK SUMMARY:
==10726==    definitely lost: 0 bytes in 0 blocks.
==10726==      possibly lost: 0 bytes in 0 blocks.
==10726==    still reachable: 24,090 bytes in 437 blocks.
==10726==         suppressed: 0 bytes in 0 blocks.
==10726== Reachable blocks (those to which a pointer was found) are not 
shown.
==10726== To see them, rerun with: --show-reachable=yes




==10730== Memcheck, a memory error detector.
==10730== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==10730== Using LibVEX rev 1658, a library for dynamic binary translation.
==10730== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==10730== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.
==10730== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==10730== For more details, rerun with: -v
==10730==
==10730== My PID = 10730, parent PID = 13696.  Prog and args are:
==10730==    /usr/local/sbin/rsyslogd
==10730==    -c3
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x40091D5: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x40091DE: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010B04: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010C61: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006E47: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Invalid read of size 8
==10730==    at 0x4010C54: (within /lib/ld-2.3.6.so)
==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10730==    by 0x4007113: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010A70: (within /lib/ld-2.3.6.so)
==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006117: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10730==    by 0x4008B91: (within /lib/ld-2.3.6.so)
==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Invalid read of size 8
==10730==    at 0x4010C20: (within /lib/ld-2.3.6.so)
==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10730==    by 0x4006123: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10731== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
hints
==10731==    This could cause spurious value errors to appear.
==10731==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
proper wrapper.
==10731==
==10731== Conditional jump or move depends on uninitialised value(s)
==10731==    at 0x4009442: (within /lib/ld-2.3.6.so)
==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==
==10731== Conditional jump or move depends on uninitialised value(s)
==10731==    at 0x4009339: (within /lib/ld-2.3.6.so)
==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==
==10731== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)
==10731==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
==10731==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
==10731==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
==10731==    by 0x4145F1: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
==10731==    by 0x5295B57: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)
==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
==10731==  Address 0x7FEFFB401 is on thread 1's stack
==10730==
==10730== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
==10730== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
==10730== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
==10730== For counts of detected errors, rerun with: -v
==10730== searching for pointers to 437 not-freed blocks.
==10730== checked 173,712 bytes.
==10730==
==10730== LEAK SUMMARY:
==10730==    definitely lost: 0 bytes in 0 blocks.
==10730==      possibly lost: 0 bytes in 0 blocks.
==10730==    still reachable: 24,090 bytes in 437 blocks.
==10730==         suppressed: 0 bytes in 0 blocks.
==10730== Reachable blocks (those to which a pointer was found) are not 
shown.
==10730== To see them, rerun with: --show-reachable=yes
==10731==
==10731== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from 
1)
==10731== malloc/free: in use at exit: 13,231 bytes in 85 blocks.
==10731== malloc/free: 3,058,176 allocs, 3,058,091 frees, 619,413,167 
bytes allocated.
==10731== For counts of detected errors, rerun with: -v
==10731== searching for pointers to 85 not-freed blocks.
==10731== checked 33,675,000 bytes.
==10731==
==10731==
==10731== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely 
lost in loss record 9 of 25
==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
==10731==    by 0x5295A31: ???
==10731==    by 0x5295C3C: ???
==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
==10731==
==10731==
==10731== 584 (104 direct, 480 indirect) bytes in 2 blocks are definitely 
lost in loss record 13 of 25
==10731==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10731==    by 0x502F63F: (within /lib/libc-2.3.6.so)
==10731==    by 0x502FD95: __nss_database_lookup (in /lib/libc-2.3.6.so)
==10731==    by 0x59B373F: ???
==10731==    by 0x59B4532: ???
==10731==    by 0x4FE5BF4: getgrnam_r (in /lib/libc-2.3.6.so)
==10731==    by 0x4272C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
==10731==
==10731==
==10731== 544 bytes in 4 blocks are possibly lost in loss record 20 of 25
==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
==10731==    by 0x400EA3D: _dl_allocate_tls (in /lib/ld-2.3.6.so)
==10731==    by 0x4C3B500: pthread_create@@GLIBC_2.2.5 (in 
/lib/libpthread-2.3.6.so)
==10731==    by 0x41690E: wtpAdviseMaxWorkers (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x41A4EF: queueStart (in /usr/local/sbin/rsyslogd)
==10731==    by 0x40B5BC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
==10731==
==10731==
==10731== 1,420 (928 direct, 492 indirect) bytes in 2 blocks are 
definitely lost in loss record 23 of 25
==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
==10731==    by 0x41F13F: msgConstruct (in /usr/local/sbin/rsyslogd)
==10731==    by 0x40ABA9: logmsgInternal (in /usr/local/sbin/rsyslogd)
==10731==    by 0x40BEC9: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40C07A: realMain (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
==10731==
==10731== LEAK SUMMARY:
==10731==    definitely lost: 1,064 bytes in 5 blocks.
==10731==    indirectly lost: 1,036 bytes in 34 blocks.
==10731==      possibly lost: 544 bytes in 4 blocks.
==10731==    still reachable: 10,587 bytes in 42 blocks.
==10731==         suppressed: 0 bytes in 0 blocks.
==10731== Reachable blocks (those to which a pointer was found) are not 
shown.
==10731== To see them, rerun with: --show-reachable=yes



From rgerhards at hq.adiscon.com  Mon Sep 15 10:23:51 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 10:23:51 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
Message-ID: <1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:53 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> I did --trace-children=yes (otherwise it wouldn't stay attached) and 
> --leak-detail=yes (since it seemed to report memory leaks in the first 
> run)

Well, I am actually not so much interested in what the forked processes
do. They have "memory leaks", but these "leaks" stem from process
duplication and are cleaned up by the OS when the forked process
terminates. Cleaning them up oneself creates unnecessary CPU, as the OS
does it much more efficient. Also, the hang is related to the parent
process. Thus, I'd actually pefer --trace-children=no ;)

I also notice that it would be of advantage to do a compile with

./configure --enable-debug --enable-valgrind

as this leads to better debug trace information. But the parent trace is most interesting first (if there is anything reported from valgrind).

Rainer

> 
> this seemed to run into problems with the first rotation (which given that 
> there was no process to do a kill -HUP on, isn't surprising)
> 
> David Lang
> 
> ==10726== Memcheck, a memory error detector.
> ==10726== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> ==10726== Using LibVEX rev 1658, a library for dynamic binary translation.
> ==10726== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> ==10726== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
> framework.
> ==10726== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> ==10726== For more details, rerun with: -v
> ==10726==
> ==10726== My PID = 10726, parent PID = 13696.  Prog and args are:
> ==10726==    /usr/local/sbin/rsyslogd
> ==10726==    -c3
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x40091D5: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x40091DE: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010B04: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010C61: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006E47: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Invalid read of size 8
> ==10726==    at 0x4010C54: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10726==    by 0x4007113: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010A70: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006117: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4008B91: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Invalid read of size 8
> ==10726==    at 0x4010C20: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10726==    by 0x4006123: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
> ==10726== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
> ==10726== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
> ==10726== For counts of detected errors, rerun with: -v
> ==10726== searching for pointers to 437 not-freed blocks.
> ==10726== checked 172,368 bytes.
> ==10726==
> ==10726== LEAK SUMMARY:
> ==10726==    definitely lost: 0 bytes in 0 blocks.
> ==10726==      possibly lost: 0 bytes in 0 blocks.
> ==10726==    still reachable: 24,090 bytes in 437 blocks.
> ==10726==         suppressed: 0 bytes in 0 blocks.
> ==10726== Reachable blocks (those to which a pointer was found) are not 
> shown.
> ==10726== To see them, rerun with: --show-reachable=yes
> 
> 
> 
> 
> ==10730== Memcheck, a memory error detector.
> ==10730== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> ==10730== Using LibVEX rev 1658, a library for dynamic binary translation.
> ==10730== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> ==10730== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
> framework.
> ==10730== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> ==10730== For more details, rerun with: -v
> ==10730==
> ==10730== My PID = 10730, parent PID = 13696.  Prog and args are:
> ==10730==    /usr/local/sbin/rsyslogd
> ==10730==    -c3
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x40091D5: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x40091DE: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010B04: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010C61: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006E47: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Invalid read of size 8
> ==10730==    at 0x4010C54: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10730==    by 0x4007113: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010A70: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006117: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4008B91: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Invalid read of size 8
> ==10730==    at 0x4010C20: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10730==    by 0x4006123: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10731== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
> hints
> ==10731==    This could cause spurious value errors to appear.
> ==10731==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
> proper wrapper.
> ==10731==
> ==10731== Conditional jump or move depends on uninitialised value(s)
> ==10731==    at 0x4009442: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==
> ==10731== Conditional jump or move depends on uninitialised value(s)
> ==10731==    at 0x4009339: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==
> ==10731== Syscall param socketcall.sendto(msg) points to uninitialised 
> byte(s)
> ==10731==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
> ==10731==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4145F1: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x5295B57: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==  Address 0x7FEFFB401 is on thread 1's stack
> ==10730==
> ==10730== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
> ==10730== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
> ==10730== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
> ==10730== For counts of detected errors, rerun with: -v
> ==10730== searching for pointers to 437 not-freed blocks.
> ==10730== checked 173,712 bytes.
> ==10730==
> ==10730== LEAK SUMMARY:
> ==10730==    definitely lost: 0 bytes in 0 blocks.
> ==10730==      possibly lost: 0 bytes in 0 blocks.
> ==10730==    still reachable: 24,090 bytes in 437 blocks.
> ==10730==         suppressed: 0 bytes in 0 blocks.
> ==10730== Reachable blocks (those to which a pointer was found) are not 
> shown.
> ==10730== To see them, rerun with: --show-reachable=yes
> ==10731==
> ==10731== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from 
> 1)
> ==10731== malloc/free: in use at exit: 13,231 bytes in 85 blocks.
> ==10731== malloc/free: 3,058,176 allocs, 3,058,091 frees, 619,413,167 
> bytes allocated.
> ==10731== For counts of detected errors, rerun with: -v
> ==10731== searching for pointers to 85 not-freed blocks.
> ==10731== checked 33,675,000 bytes.
> ==10731==
> ==10731==
> ==10731== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely 
> lost in loss record 9 of 25
> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> ==10731==    by 0x5295A31: ???
> ==10731==    by 0x5295C3C: ???
> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> ==10731==
> ==10731==
> ==10731== 584 (104 direct, 480 indirect) bytes in 2 blocks are definitely 
> lost in loss record 13 of 25
> ==10731==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10731==    by 0x502F63F: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x502FD95: __nss_database_lookup (in /lib/libc-2.3.6.so)
> ==10731==    by 0x59B373F: ???
> ==10731==    by 0x59B4532: ???
> ==10731==    by 0x4FE5BF4: getgrnam_r (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4272C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
> ==10731==
> ==10731==
> ==10731== 544 bytes in 4 blocks are possibly lost in loss record 20 of 25
> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> ==10731==    by 0x400EA3D: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==10731==    by 0x4C3B500: pthread_create@@GLIBC_2.2.5 (in 
> /lib/libpthread-2.3.6.so)
> ==10731==    by 0x41690E: wtpAdviseMaxWorkers (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x41A4EF: queueStart (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B5BC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> ==10731==
> ==10731==
> ==10731== 1,420 (928 direct, 492 indirect) bytes in 2 blocks are 
> definitely lost in loss record 23 of 25
> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> ==10731==    by 0x41F13F: msgConstruct (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40ABA9: logmsgInternal (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40BEC9: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40C07A: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> ==10731==
> ==10731== LEAK SUMMARY:
> ==10731==    definitely lost: 1,064 bytes in 5 blocks.
> ==10731==    indirectly lost: 1,036 bytes in 34 blocks.
> ==10731==      possibly lost: 544 bytes in 4 blocks.
> ==10731==    still reachable: 10,587 bytes in 42 blocks.
> ==10731==         suppressed: 0 bytes in 0 blocks.
> ==10731== Reachable blocks (those to which a pointer was found) are not 
> shown.
> ==10731== To see them, rerun with: --show-reachable=yes
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From david at lang.hm  Mon Sep 15 10:31:47 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 01:31:47 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:53 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>> I did --trace-children=yes (otherwise it wouldn't stay attached) and
>> --leak-detail=yes (since it seemed to report memory leaks in the first
>> run)
>
> Well, I am actually not so much interested in what the forked processes
> do. They have "memory leaks", but these "leaks" stem from process
> duplication and are cleaned up by the OS when the forked process
> terminates. Cleaning them up oneself creates unnecessary CPU, as the OS
> does it much more efficient. Also, the hang is related to the parent
> process. Thus, I'd actually pefer --trace-children=no ;)
>
> I also notice that it would be of advantage to do a compile with
>
> ./configure --enable-debug --enable-valgrind
>
> as this leads to better debug trace information. But the parent trace is most interesting first (if there is anything reported from valgrind).

Ok, I will do this in the morning.

one other item that occured to me, should I even be doing the kill -HUP? 
or does rsyslog open the file for writing each time (so that I just have 
to mv the file away and it will create a new one)?

David Lang

> Rainer
>
>>
>> this seemed to run into problems with the first rotation (which given that
>> there was no process to do a kill -HUP on, isn't surprising)
>>
>> David Lang
>>
>> ==10726== Memcheck, a memory error detector.
>> ==10726== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10726== Using LibVEX rev 1658, a library for dynamic binary translation.
>> ==10726== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
>> ==10726== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
>> framework.
>> ==10726== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10726== For more details, rerun with: -v
>> ==10726==
>> ==10726== My PID = 10726, parent PID = 13696.  Prog and args are:
>> ==10726==    /usr/local/sbin/rsyslogd
>> ==10726==    -c3
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x40091D5: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x40091DE: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010B04: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010C61: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006E47: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Invalid read of size 8
>> ==10726==    at 0x4010C54: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
>> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10726==    by 0x4007113: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010A70: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006117: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4008B91: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Invalid read of size 8
>> ==10726==    at 0x4010C20: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
>> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10726==    by 0x4006123: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
>> ==10726== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
>> ==10726== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
>> ==10726== For counts of detected errors, rerun with: -v
>> ==10726== searching for pointers to 437 not-freed blocks.
>> ==10726== checked 172,368 bytes.
>> ==10726==
>> ==10726== LEAK SUMMARY:
>> ==10726==    definitely lost: 0 bytes in 0 blocks.
>> ==10726==      possibly lost: 0 bytes in 0 blocks.
>> ==10726==    still reachable: 24,090 bytes in 437 blocks.
>> ==10726==         suppressed: 0 bytes in 0 blocks.
>> ==10726== Reachable blocks (those to which a pointer was found) are not
>> shown.
>> ==10726== To see them, rerun with: --show-reachable=yes
>>
>>
>>
>>
>> ==10730== Memcheck, a memory error detector.
>> ==10730== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10730== Using LibVEX rev 1658, a library for dynamic binary translation.
>> ==10730== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
>> ==10730== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
>> framework.
>> ==10730== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10730== For more details, rerun with: -v
>> ==10730==
>> ==10730== My PID = 10730, parent PID = 13696.  Prog and args are:
>> ==10730==    /usr/local/sbin/rsyslogd
>> ==10730==    -c3
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x40091D5: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x40091DE: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010B04: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010C61: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006E47: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Invalid read of size 8
>> ==10730==    at 0x4010C54: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
>> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10730==    by 0x4007113: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010A70: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006117: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4008B91: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Invalid read of size 8
>> ==10730==    at 0x4010C20: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
>> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10730==    by 0x4006123: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10731== Warning: noted but unhandled ioctl 0x5422 with no size/direction
>> hints
>> ==10731==    This could cause spurious value errors to appear.
>> ==10731==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
>> proper wrapper.
>> ==10731==
>> ==10731== Conditional jump or move depends on uninitialised value(s)
>> ==10731==    at 0x4009442: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==
>> ==10731== Conditional jump or move depends on uninitialised value(s)
>> ==10731==    at 0x4009339: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==
>> ==10731== Syscall param socketcall.sendto(msg) points to uninitialised
>> byte(s)
>> ==10731==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4145F1: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x5295B57: addAllowedSenderLine (in
>> /usr/local/lib/rsyslog/lmnet.so)
>> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==  Address 0x7FEFFB401 is on thread 1's stack
>> ==10730==
>> ==10730== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
>> ==10730== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
>> ==10730== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
>> ==10730== For counts of detected errors, rerun with: -v
>> ==10730== searching for pointers to 437 not-freed blocks.
>> ==10730== checked 173,712 bytes.
>> ==10730==
>> ==10730== LEAK SUMMARY:
>> ==10730==    definitely lost: 0 bytes in 0 blocks.
>> ==10730==      possibly lost: 0 bytes in 0 blocks.
>> ==10730==    still reachable: 24,090 bytes in 437 blocks.
>> ==10730==         suppressed: 0 bytes in 0 blocks.
>> ==10730== Reachable blocks (those to which a pointer was found) are not
>> shown.
>> ==10730== To see them, rerun with: --show-reachable=yes
>> ==10731==
>> ==10731== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from
>> 1)
>> ==10731== malloc/free: in use at exit: 13,231 bytes in 85 blocks.
>> ==10731== malloc/free: 3,058,176 allocs, 3,058,091 frees, 619,413,167
>> bytes allocated.
>> ==10731== For counts of detected errors, rerun with: -v
>> ==10731== searching for pointers to 85 not-freed blocks.
>> ==10731== checked 33,675,000 bytes.
>> ==10731==
>> ==10731==
>> ==10731== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely
>> lost in loss record 9 of 25
>> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
>> ==10731==    by 0x5295A31: ???
>> ==10731==    by 0x5295C3C: ???
>> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
>> ==10731==
>> ==10731==
>> ==10731== 584 (104 direct, 480 indirect) bytes in 2 blocks are definitely
>> lost in loss record 13 of 25
>> ==10731==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10731==    by 0x502F63F: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x502FD95: __nss_database_lookup (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x59B373F: ???
>> ==10731==    by 0x59B4532: ???
>> ==10731==    by 0x4FE5BF4: getgrnam_r (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4272C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
>> ==10731==
>> ==10731==
>> ==10731== 544 bytes in 4 blocks are possibly lost in loss record 20 of 25
>> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
>> ==10731==    by 0x400EA3D: _dl_allocate_tls (in /lib/ld-2.3.6.so)
>> ==10731==    by 0x4C3B500: pthread_create@@GLIBC_2.2.5 (in
>> /lib/libpthread-2.3.6.so)
>> ==10731==    by 0x41690E: wtpAdviseMaxWorkers (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x41A4EF: queueStart (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B5BC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
>> ==10731==
>> ==10731==
>> ==10731== 1,420 (928 direct, 492 indirect) bytes in 2 blocks are
>> definitely lost in loss record 23 of 25
>> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
>> ==10731==    by 0x41F13F: msgConstruct (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40ABA9: logmsgInternal (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40BEC9: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40C07A: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
>> ==10731==
>> ==10731== LEAK SUMMARY:
>> ==10731==    definitely lost: 1,064 bytes in 5 blocks.
>> ==10731==    indirectly lost: 1,036 bytes in 34 blocks.
>> ==10731==      possibly lost: 544 bytes in 4 blocks.
>> ==10731==    still reachable: 10,587 bytes in 42 blocks.
>> ==10731==         suppressed: 0 bytes in 0 blocks.
>> ==10731== Reachable blocks (those to which a pointer was found) are not
>> shown.
>> ==10731== To see them, rerun with: --show-reachable=yes
>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Mon Sep 15 10:57:26 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 10:57:26 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
Message-ID: <1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> one other item that occured to me, should I even be doing the kill -HUP? 
> or does rsyslog open the file for writing each time (so that I just have 
> to mv the file away and it will create a new one)?

no, you need the HUP. Otherwise the file is kept open (so this is no
easy way to improve performance ;))

Rainer



From david at lang.hm  Mon Sep 15 11:07:22 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 02:07:22 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>
>> one other item that occured to me, should I even be doing the kill -HUP?
>> or does rsyslog open the file for writing each time (so that I just have
>> to mv the file away and it will create a new one)?
>
> no, you need the HUP. Otherwise the file is kept open (so this is no
> easy way to improve performance ;))

here is a run with the debug and valgrind options

==11835== Memcheck, a memory error detector.

==11835== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.

==11835== Using LibVEX rev 1658, a library for dynamic binary translation.

==11835== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.

==11835== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.

==11835== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.

==11835== For more details, rerun with: -v

==11835==

==11835== My PID = 11835, parent PID = 11702.  Prog and args are:

==11835==    /usr/local/sbin/rsyslogd

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x40091D5: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==11835==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x40091DE: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==11835==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010AEE: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010AF9: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010B04: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010C61: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006E47: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Invalid read of size 8

==11835==    at 0x4010C54: (within /lib/ld-2.3.6.so)

==11835==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==11835==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==  Address 0x5198EB0 is 16 bytes inside a block of size 23 alloc'd

==11835==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==11835==    by 0x4007113: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010A70: (within /lib/ld-2.3.6.so)

==11835==    by 0x400610A: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010A7F: (within /lib/ld-2.3.6.so)

==11835==    by 0x400610A: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010A8E: (within /lib/ld-2.3.6.so)

==11835==    by 0x400610A: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006117: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==11835==    by 0x4008B91: (within /lib/ld-2.3.6.so)

==11835==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Invalid read of size 8

==11835==    at 0x4010C20: (within /lib/ld-2.3.6.so)

==11835==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==11835==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==  Address 0x519B1C0 is 32 bytes inside a block of size 35 alloc'd

==11835==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==11835==    by 0x4006123: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11836== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
hints

==11836==    This could cause spurious value errors to appear.

==11836==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
proper wrapper.

==11836==

==11836== Conditional jump or move depends on uninitialised value(s)

==11836==    at 0x4009442: (within /lib/ld-2.3.6.so)

==11836==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11836==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11836==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11836==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==11836==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==11836==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==11836==

==11836== Conditional jump or move depends on uninitialised value(s)

==11836==    at 0x4009339: (within /lib/ld-2.3.6.so)

==11836==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11836==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11836==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11836==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==11836==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==11836==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==11836==

==11836== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)

==11836==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)

==11836==    by 0x503E8C9: (within /lib/libc-2.3.6.so)

==11836==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)

==11836==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)

==11836==    by 0x5295D97: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==11836==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==11836==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==11836==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==11836==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x40D3D1: realMain (in /usr/local/sbin/rsyslogd)
==11836==  Address 0x7FEFFB371 is on thread 1's stack

==11835==

==11835== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)

==11835== malloc/free: in use at exit: 25,332 bytes in 459 blocks.

==11835== malloc/free: 606 allocs, 147 frees, 36,928 bytes allocated.

==11835== For counts of detected errors, rerun with: -v

==11835== searching for pointers to 459 not-freed blocks.

==11835== checked 175,080 bytes.

==11835==

==11835== LEAK SUMMARY:

==11835==    definitely lost: 0 bytes in 0 blocks.

==11835==      possibly lost: 0 bytes in 0 blocks.

==11835==    still reachable: 25,332 bytes in 459 blocks.

==11835==         suppressed: 0 bytes in 0 blocks.

==11835== Reachable blocks (those to which a pointer was found) are not 
shown.

==11835== To see them, rerun with: --show-reachable=yes

==11836==

==11836== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from 
1)

==11836== malloc/free: in use at exit: 20,815 bytes in 114 blocks.

==11836== malloc/free: 1,738 allocs, 1,624 frees, 255,036 bytes allocated.

==11836== For counts of detected errors, rerun with: -v

==11836== searching for pointers to 114 not-freed blocks.

==11836== checked 33,711,344 bytes.

==11836==

==11836== LEAK SUMMARY:

==11836==    definitely lost: 2,020 bytes in 35 blocks.

==11836==      possibly lost: 544 bytes in 4 blocks.

==11836==    still reachable: 18,251 bytes in 75 blocks.

==11836==         suppressed: 0 bytes in 0 blocks.

==11836== Use --leak-check=full to see details of leaked memory.




From rgerhards at hq.adiscon.com  Mon Sep 15 11:28:19 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 11:28:19 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
Message-ID: <1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 02:07 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> > On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
> >> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> >
> >> one other item that occured to me, should I even be doing the kill -HUP?
> >> or does rsyslog open the file for writing each time (so that I just have
> >> to mv the file away and it will create a new one)?
> >
> > no, you need the HUP. Otherwise the file is kept open (so this is no
> > easy way to improve performance ;))
> 
> here is a run with the debug and valgrind options

mmhhh... it still is missing lots of information. Did "make install"
install to incorrect locations? This happens quite often, especially on
x64 systems (I've fallen myself more than once into this trap).

Rainer



From david at lang.hm  Mon Sep 15 11:51:30 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 02:51:30 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 02:07 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>
>>> On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
>>>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>>
>>>> one other item that occured to me, should I even be doing the kill -HUP?
>>>> or does rsyslog open the file for writing each time (so that I just have
>>>> to mv the file away and it will create a new one)?
>>>
>>> no, you need the HUP. Otherwise the file is kept open (so this is no
>>> easy way to improve performance ;))
>>
>> here is a run with the debug and valgrind options
>
> mmhhh... it still is missing lots of information. Did "make install"
> install to incorrect locations? This happens quite often, especially on
> x64 systems (I've fallen myself more than once into this trap).

trying again (this time remembering to add -c3 to the command line)

==12351== Memcheck, a memory error detector.

==12351== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.

==12351== Using LibVEX rev 1658, a library for dynamic binary translation.

==12351== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.

==12351== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.

==12351== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.

==12351== For more details, rerun with: -v

==12351==

==12351== My PID = 12351, parent PID = 11702.  Prog and args are:

==12351==    /usr/local/sbin/rsyslogd

==12351==    -c3

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x40091D5: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x40091DE: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010AEE: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010AF9: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010B04: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010C61: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006E47: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Invalid read of size 8

==12351==    at 0x4010C54: (within /lib/ld-2.3.6.so)

==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==  Address 0x5198EB0 is 16 bytes inside a block of size 23 alloc'd

==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12351==    by 0x4007113: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010A70: (within /lib/ld-2.3.6.so)

==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010A7F: (within /lib/ld-2.3.6.so)

==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010A8E: (within /lib/ld-2.3.6.so)

==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006117: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==12351==    by 0x4008B91: (within /lib/ld-2.3.6.so)

==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Invalid read of size 8

==12351==    at 0x4010C20: (within /lib/ld-2.3.6.so)

==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==  Address 0x519B1C0 is 32 bytes inside a block of size 35 alloc'd

==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12351==    by 0x4006123: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12352== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
hints

==12352==    This could cause spurious value errors to appear.

==12352==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
proper wrapper.

==12352==

==12352== Conditional jump or move depends on uninitialised value(s)

==12352==    at 0x4009442: (within /lib/ld-2.3.6.so)

==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==

==12352== Conditional jump or move depends on uninitialised value(s)

==12352==    at 0x4009339: (within /lib/ld-2.3.6.so)

==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==

==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)

==12352==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)

==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)

==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)

==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)

==12352==    by 0x5295D97: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D3D1: realMain (in /usr/local/sbin/rsyslogd)

==12352==  Address 0x7FEFFB361 is on thread 1's stack

==12351==

==12351== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)

==12351== malloc/free: in use at exit: 24,243 bytes in 445 blocks.

==12351== malloc/free: 585 allocs, 140 frees, 33,424 bytes allocated.

==12351== For counts of detected errors, rerun with: -v

==12351== searching for pointers to 445 not-freed blocks.

==12351== checked 174,016 bytes.

==12351==

==12351== LEAK SUMMARY:

==12351==    definitely lost: 0 bytes in 0 blocks.

==12351==      possibly lost: 0 bytes in 0 blocks.

==12351==    still reachable: 24,243 bytes in 445 blocks.

==12351==         suppressed: 0 bytes in 0 blocks.

==12351== Reachable blocks (those to which a pointer was found) are not 
shown.

==12351== To see them, rerun with: --show-reachable=yes

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAEDD: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF02: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF10: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E44 is 4 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF1E: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid write of size 4

==12352==    at 0x57AAF14: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid write of size 4

==12352==    at 0x57AAF38: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF4A: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid free() / delete / delete[]

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAF62: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)

==12352==    at 0x50202D0: sendto (in /lib/libc-2.3.6.so)

==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)

==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)

==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)

==12352==    by 0x5295D97: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==  Address 0x7FEFFB361 is on thread 1's stack

==12352==

==12352== Thread 5:

==12352== Invalid read of size 4

==12352==    at 0x57AB092: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)

==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AB063: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)

==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Thread 1:

==12352== Invalid read of size 4

==12352==    at 0x5295196: closeUDPListenSockets (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF20: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)



valgrind: m_mallocfree.c:194 (get_bszB_as_is): Assertion 'bszB_lo == 
bszB_hi' failed.

valgrind: Heap block lo/hi size mismatch: lo = 2, hi = 562949953486848.

Probably caused by overrunning/underrunning a heap block's bounds.



==12352==    at 0x3801770A: report_and_quit (m_libcassert.c:136)

==12352==    by 0x38017A6D: vgPlain_assert_fail (m_libcassert.c:200)

==12352==    by 0x380208D8: vgPlain_arena_malloc (m_mallocfree.c:191)

==12352==    by 0x3803523B: vgPlain_cli_malloc (replacemalloc_core.c:101)

==12352==    by 0x38002487: vgMemCheck_calloc (mc_malloc_wrappers.c:182)

==12352==    by 0x3803592F: do_client_request (scheduler.c:1166)

==12352==    by 0x38036FAD: vgPlain_scheduler (scheduler.c:869)

==12352==    by 0x38051849: run_a_thread_NORETURN (syswrap-linux.c:87)



sched status:

   running_tid=1



Thread 1: status = VgTs_Runnable

==12352==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)

==12352==    by 0x414B72: rsCStrConstruct (in /usr/local/sbin/rsyslogd)

==12352==    by 0x414D0C: rsCStrConstructFromszStr (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4162FB: rsParsConstructFromSz (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x5295D52: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)




From satoru.satoh at gmail.com  Mon Sep 15 11:56:29 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Mon, 15 Sep 2008 18:56:29 +0900
Subject: [rsyslog] docbook and math
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F12B@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F12B@grfint2.intern.adiscon.com>
Message-ID: <20080915095627.GA14056@localhost.localdomain>

Hi,


I don't have enough experience with docbook and math formulas but LaTeX
might be better for now unfortunatelly, I guess.

If you go with docbook, current dtd-based docbook (4.x) does not well
with MathML natively and you might have to convert math formula to some
formats of image somehow. There may be two choices.

 1) write math formulas in LaTex and convert to images (EPS, PNG, ...)
 2) write math formulas in MathML and convert to images (SVG, ...)

Here are some related links.

 * http://www.sagehill.net/docbookxsl/MathML.html
 * http://www.grigoriev.ru/svgmath/
 * http://www.sagehill.net/docbookxsl/SVGimages.html

IIWM, I would choose 2) (mathml -> svg) and try svgmath.

Other random notes about MathML:

 * OpenOffice.org-Math supports MathML output.

 * Gecho based browsers (e.g. firefox) can display MathML docs.
   * http://www.mozilla.org/projects/mathml/authoring.html
   * http://www.mozilla.org/projects/mathml/fonts/ (MathML fonts)

 * MathML has two ways to markup; contents markup and presentation
   markup. MathMLc2p
   (http://www.lri.fr/~pietriga/mathmlc2p/mathmlc2p.html) might 
   help if you have to transform from the former into the later.


- satoru

On Thu, Sep 11, 2008 at 03:27:49PM +0200, Rainer Gerhards wrote:
> Hi folks,
> 
> and especially those that are proficient with docbook ;) I have one
> question. I am thinking about a series of design papers. I think,
> however, that at least some of them will require a lot of mathematical
> formulas. Typically, I'd say that should be done in LaTeX. But with
> moving to docbook for the user doc, it may be good to use a single
> system.
> 
> I have now investigated docbook and maths a bit, but what I found didn't
> look very promising. The best I found was MathML, which is far too
> verbose for any hand-editing (and I don't want to rely on specialized
> formula editors). I also found some references to embedded TeX, but that
> looked quite hackish.
> 
> Could somebody enlighten me on the current typical approach for such
> papers? Do they still usually go the LaTeX way or is there a good way to
> do it with docbook?
> 
> Many thanks in advance,
> Rainer


From rgerhards at hq.adiscon.com  Mon Sep 15 11:57:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 11:57:14 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
Message-ID: <1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>

mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
still has no source line information. Without that, it has very little
value. OK, I'll look at some other ways.

Rainer

On Mon, 2008-09-15 at 02:51 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> > On Mon, 2008-09-15 at 02:07 -0700, david at lang.hm wrote:
> >> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> >>
> >>> On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
> >>>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> >>>
> >>>> one other item that occured to me, should I even be doing the kill -HUP?
> >>>> or does rsyslog open the file for writing each time (so that I just have
> >>>> to mv the file away and it will create a new one)?
> >>>
> >>> no, you need the HUP. Otherwise the file is kept open (so this is no
> >>> easy way to improve performance ;))
> >>
> >> here is a run with the debug and valgrind options
> >
> > mmhhh... it still is missing lots of information. Did "make install"
> > install to incorrect locations? This happens quite often, especially on
> > x64 systems (I've fallen myself more than once into this trap).
> 
> trying again (this time remembering to add -c3 to the command line)
> 
> ==12351== Memcheck, a memory error detector.
> 
> ==12351== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> 
> ==12351== Using LibVEX rev 1658, a library for dynamic binary translation.
> 
> ==12351== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> 
> ==12351== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
> framework.
> 
> ==12351== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> 
> ==12351== For more details, rerun with: -v
> 
> ==12351==
> 
> ==12351== My PID = 12351, parent PID = 11702.  Prog and args are:
> 
> ==12351==    /usr/local/sbin/rsyslogd
> 
> ==12351==    -c3
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x40091D5: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x40091DE: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010B04: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010C61: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006E47: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Invalid read of size 8
> 
> ==12351==    at 0x4010C54: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==  Address 0x5198EB0 is 16 bytes inside a block of size 23 alloc'd
> 
> ==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12351==    by 0x4007113: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010A70: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006117: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4008B91: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Invalid read of size 8
> 
> ==12351==    at 0x4010C20: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==  Address 0x519B1C0 is 32 bytes inside a block of size 35 alloc'd
> 
> ==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12351==    by 0x4006123: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12352== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
> hints
> 
> ==12352==    This could cause spurious value errors to appear.
> 
> ==12352==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
> proper wrapper.
> 
> ==12352==
> 
> ==12352== Conditional jump or move depends on uninitialised value(s)
> 
> ==12352==    at 0x4009442: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==
> 
> ==12352== Conditional jump or move depends on uninitialised value(s)
> 
> ==12352==    at 0x4009339: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==
> 
> ==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
> byte(s)
> 
> ==12352==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x5295D97: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D3D1: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==  Address 0x7FEFFB361 is on thread 1's stack
> 
> ==12351==
> 
> ==12351== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
> 
> ==12351== malloc/free: in use at exit: 24,243 bytes in 445 blocks.
> 
> ==12351== malloc/free: 585 allocs, 140 frees, 33,424 bytes allocated.
> 
> ==12351== For counts of detected errors, rerun with: -v
> 
> ==12351== searching for pointers to 445 not-freed blocks.
> 
> ==12351== checked 174,016 bytes.
> 
> ==12351==
> 
> ==12351== LEAK SUMMARY:
> 
> ==12351==    definitely lost: 0 bytes in 0 blocks.
> 
> ==12351==      possibly lost: 0 bytes in 0 blocks.
> 
> ==12351==    still reachable: 24,243 bytes in 445 blocks.
> 
> ==12351==         suppressed: 0 bytes in 0 blocks.
> 
> ==12351== Reachable blocks (those to which a pointer was found) are not 
> shown.
> 
> ==12351== To see them, rerun with: --show-reachable=yes
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAEDD: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF02: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF10: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E44 is 4 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF1E: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid write of size 4
> 
> ==12352==    at 0x57AAF14: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid write of size 4
> 
> ==12352==    at 0x57AAF38: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF4A: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid free() / delete / delete[]
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAF62: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
> byte(s)
> 
> ==12352==    at 0x50202D0: sendto (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x5295D97: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==  Address 0x7FEFFB361 is on thread 1's stack
> 
> ==12352==
> 
> ==12352== Thread 5:
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AB092: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)
> 
> ==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AB063: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)
> 
> ==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Thread 1:
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x5295196: closeUDPListenSockets (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF20: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> 
> 
> valgrind: m_mallocfree.c:194 (get_bszB_as_is): Assertion 'bszB_lo == 
> bszB_hi' failed.
> 
> valgrind: Heap block lo/hi size mismatch: lo = 2, hi = 562949953486848.
> 
> Probably caused by overrunning/underrunning a heap block's bounds.
> 
> 
> 
> ==12352==    at 0x3801770A: report_and_quit (m_libcassert.c:136)
> 
> ==12352==    by 0x38017A6D: vgPlain_assert_fail (m_libcassert.c:200)
> 
> ==12352==    by 0x380208D8: vgPlain_arena_malloc (m_mallocfree.c:191)
> 
> ==12352==    by 0x3803523B: vgPlain_cli_malloc (replacemalloc_core.c:101)
> 
> ==12352==    by 0x38002487: vgMemCheck_calloc (mc_malloc_wrappers.c:182)
> 
> ==12352==    by 0x3803592F: do_client_request (scheduler.c:1166)
> 
> ==12352==    by 0x38036FAD: vgPlain_scheduler (scheduler.c:869)
> 
> ==12352==    by 0x38051849: run_a_thread_NORETURN (syswrap-linux.c:87)
> 
> 
> 
> sched status:
> 
>    running_tid=1
> 
> 
> 
> Thread 1: status = VgTs_Runnable
> 
> ==12352==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> 
> ==12352==    by 0x414B72: rsCStrConstruct (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x414D0C: rsCStrConstructFromszStr (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4162FB: rsParsConstructFromSz (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x5295D52: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep 15 12:13:45 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 12:13:45 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
	<1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
Message-ID: <1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>

side-note: do you mind if we concentrate on the performance issue first
and keep an eye on this here (as a secondary goal) while we do it? I
think that would enable me to address both most quickly (I can add
instrumentation code/checks while I modify the file output). There may
come a time when reversing priorities makes sense, but for now I think
this would be the best way...

Rainer
On Mon, 2008-09-15 at 11:57 +0200, Rainer Gerhards wrote:
> mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
> still has no source line information. Without that, it has very little
> value. OK, I'll look at some other ways.




From david at lang.hm  Mon Sep 15 13:14:42 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 04:14:42 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
	<1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
	<1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> side-note: do you mind if we concentrate on the performance issue first
> and keep an eye on this here (as a secondary goal) while we do it? I
> think that would enable me to address both most quickly (I can add
> instrumentation code/checks while I modify the file output). There may
> come a time when reversing priorities makes sense, but for now I think
> this would be the best way...

no problem.

> Rainer
> On Mon, 2008-09-15 at 11:57 +0200, Rainer Gerhards wrote:
>> mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
>> still has no source line information. Without that, it has very little
>> value. OK, I'll look at some other ways.
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From lorenzo at sancho.ccd.uniroma2.it  Fri Sep 12 12:40:20 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Fri, 12 Sep 2008 12:40:20 +0200 (CEST)
Subject: [rsyslog] rsyslog frequent crashes
Message-ID: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>

The system is a dual processor / quad core Xeon E5335 running a 64 bit 
debian lenny distribution; I've enabled both debug and rtinst configure,
and installed an unstripped binary; I'm attaching the full backtrace here.

the system should act as a client to a remote syslog server; I'm enclosing 
the conf files too.

In the previous attempts (before enabling rtinst and debug), I got lines 
like "rsyslogd: double free or corruption (!prev): 0x0000000000674c50"
in the failover log (corresponding to the _nodebug backtrace); this last 
time, the line I've got is

"msg.c:273: msgDestruct: Assertion `(unsigned) ((obj_t*)
            (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed."

and the double free detector didn't fire.

I'm really at a loss now: I've been lured into experimenting rsyslog from 
the high level architectural description being this clean and seemingly 
powerful, but now I fear I still cannot rely on this logger in production.

Eager to help in debugging, sincerely yours

 	lorenzo



+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Core was generated by `/usr/sbin/rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 16283]
[New process 16285]
[New process 16284]
[New process 16282]
[New process 16281]
#0  0x00002b44aa374ef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 16281):
#0  0x00002b44aa40bf12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x000000000040efb9 in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:2563
	dbgCALLStaCK_POP_POINT = 0
	iRet = <value optimized out>
	i = <value optimized out>
	p = <value optimized out>
	num_fds = <value optimized out>
	ch = <value optimized out>
	hent = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0x1, 
    sa_sigaction = 0x1}, sa_mask = {__val = {0 <repeats 16 times>}}, 
  sa_flags = 0, sa_restorer = 0}
	bIsFirstOption = <value optimized out>
	bEOptionWasGiven = <value optimized out>
	bImUxSockLoaded = <value optimized out>
	arg = <value optimized out>
	legacyConfLine = '\0' <repeats 79 times>
	pdbgFuncDB = (dbgFuncDB_t *) 0x66e320
	__func__ = "realMain"
#2  0x00002b44aa3611a6 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#3  0x00000000004096b9 in _start ()
No locals.

Thread 4 (process 16282):
#0  0x00002b44a9d23fad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x0000000000416333 in dbgCondTimedWait (cond=0x686fe0, 
    pmut=0xffffffffffffff92, abstime=0x407fffd0, pFuncDB=0x6a6bc0, ln=403, 
    iStackPtr=<value optimized out>) at debug.c:555
	ret = <value optimized out>
#2  0x0000000000421f59 in wtiWorker (pThis=0x688160) at wti.c:403
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130748, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727512550297697851, 1727653793608105531}, __mask_was_saved = 0}}, 
  __pad = {0x408000d0, 0x0, 0x68a740, 0x19f}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 1
	iCancelStateSave = 0
	t = {tv_sec = 1221174340, tv_nsec = 609910833}
	pWtp = (wtp_t *) 0x687b50
	bInactivityTOOccured = 0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6a6bc0
	__func__ = "wtiWorker"
	__PRETTY_FUNCTION__ = "wtiWorker"
#3  0x00000000004209c2 in wtpWorker (arg=0x688160) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130512, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727511424978517563, 1727653794260319803}, __mask_was_saved = 0}}, 
  __pad = {0x408001e0, 0x0, 0x40800950, 0x40800950}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 0
	iCancelStateSave = 0
	pWti = (wti_t *) 0x688160
	pThis = (wtp_t *) 0x687b50
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x68a740
	__func__ = "wtpWorker"
	__PRETTY_FUNCTION__ = "wtpWorker"
#4  0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 3 (process 16284):
#0  0x00002b44aa40bf12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b44aacb4773 in runInput (pThrd=<value optimized out>)
    at imuxsock.c:235
	maxfds = 0
	nfds = <value optimized out>
	i = <value optimized out>
	fd = <value optimized out>
	readfds = {fds_bits = {1, 0 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x6aa6f0
	__func__ = "runInput"
#2  0x000000000041be2d in thrdStarter (arg=0x6a8a40) at threads.c:139
	dbgCALLStaCK_POP_POINT = 0
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x6aa620
	__func__ = "thrdStarter"
	__PRETTY_FUNCTION__ = "thrdStarter"
#3  0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 2 (process 16285):
#0  0x00002b44a9d267eb in read () from /lib/libpthread.so.0
No symbol table info available.
#1  0x00002b44aaeb91c7 in klogLogKMsg () at linux.c:454
	dbgCALLStaCK_POP_POINT = 2
	pdbgFuncDB = (dbgFuncDB_t *) 0x6af730
	__func__ = "klogLogKMsg"
#2  0x00002b44aaeb84a4 in runInput (pThrd=0x6abae0) at imklog.c:208
	dbgCALLStaCK_POP_POINT = 1
	iRet = RS_RET_OK
	pdbgFuncDB = (dbgFuncDB_t *) 0x6af660
	__func__ = "runInput"
#3  0x000000000041be2d in thrdStarter (arg=0x6abae0) at threads.c:139
	dbgCALLStaCK_POP_POINT = 0
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x6aa620
	__func__ = "thrdStarter"
	__PRETTY_FUNCTION__ = "thrdStarter"
#4  0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 1 (process 16283):
#0  0x00002b44aa374ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b44aa376413 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x0000000000415a5f in sigsegvHdlr (signum=6) at debug.c:741
	signame = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
  sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0}
#3  <signal handler called>
No symbol table info available.
#4  0x00002b44aa374ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#5  0x00002b44aa376413 in abort () from /lib/libc.so.6
No symbol table info available.
#6  0x00002b44aa36ddc9 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#7  0x000000000042e550 in msgDestruct (ppThis=0x692a20) at msg.c:273
	dbgCALLStaCK_POP_POINT = 8
	iCancelStateSave = <value optimized out>
	pThis = (msg_t *) 0x2aaaac0008c0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6addf0
	__func__ = "msgDestruct"
	__PRETTY_FUNCTION__ = "msgDestruct"
#8  0x000000000043d346 in actionCallAction (pAction=0x6929c0, 
    pMsg=0x2aaaac000ac0) at action.c:661
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {6891968, 
        1727510324980350523, 6, 4240656, 1090522784, 1090522696, 
        1727510325009710651, 1727653804676349499}, __mask_was_saved = 0}}, 
  __pad = {0x41000f60, 0x0, 0x692820, 0x40b510}}
	__cancel_arg = (void *) 0x692a70
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 7
	iRet = <value optimized out>
	iCancelStateSave = 0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ad2b0
	__func__ = "actionCallAction"
	__PRETTY_FUNCTION__ = "actionCallAction"
#9  0x000000000040b567 in processMsgDoActions (pData=0x6929c0, 
    pParam=0x41000ea0) at syslogd.c:1094
	dbgCALLStaCK_POP_POINT = 6
	iRet = <value optimized out>
	iRetMod = <value optimized out>
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ad180
	__func__ = "processMsgDoActions"
	__PRETTY_FUNCTION__ = "processMsgDoActions"
#10 0x000000000043c0ce in llExecFunc (pThis=0x692820, 
    pFunc=0x40b510 <processMsgDoActions>, pParam=0x41000ea0)
    at linkedlist.c:390
	dbgCALLStaCK_POP_POINT = 5
	iRet = RS_RET_OK
	iRetLL = RS_RET_OK
	pData = (void *) 0x6929c0
	llCookie = (linkedListCookie_t) 0x6920c0
	llCookiePrev = (linkedListCookie_t) 0x0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ad050
	__func__ = "llExecFunc"
	__PRETTY_FUNCTION__ = "llExecFunc"
#11 0x000000000040b0c9 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x2aaaac000ac0) at syslogd.c:1137
	dbgCALLStaCK_POP_POINT = 3
	pMsg = (msg_t *) 0x2aaaac000ac0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6accb0
	__func__ = "msgConsumer"
	__PRETTY_FUNCTION__ = "msgConsumer"
#12 0x000000000042521f in queueConsumerReg (pThis=0x692db0, pWti=0x6a6900, 
    iCancelStateSave=<value optimized out>) at queue.c:1570
	dbgCALLStaCK_POP_POINT = 2
	iRet = RS_RET_OK
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ac8d0
	__func__ = "queueConsumerReg"
	__PRETTY_FUNCTION__ = "queueConsumerReg"
#13 0x0000000000421eb0 in wtiWorker (pThis=0x6a6900) at wti.c:413
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523452, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727510324967767611, 1727653793608105531}, __mask_was_saved = 0}}, 
  __pad = {0x410010d0, 0x0, 0x68a740, 0x19f}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 1
	iCancelStateSave = 0
	t = {tv_sec = 1221174340, tv_nsec = 478220993}
	pWtp = (wtp_t *) 0x680d90
	bInactivityTOOccured = 0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6a6bc0
	__func__ = "wtiWorker"
	__PRETTY_FUNCTION__ = "wtiWorker"
#14 0x00000000004209c2 in wtpWorker (arg=0x6a6900) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523216, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727510324930018875, 1727653794260319803}, __mask_was_saved = 0}}, 
  __pad = {0x410011e0, 0x0, 0x0, 0x0}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 0
	iCancelStateSave = 0
	pWti = (wti_t *) 0x6a6900
	pThis = (wtp_t *) 0x680d90
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x68a740
	__func__ = "wtpWorker"
	__PRETTY_FUNCTION__ = "wtpWorker"
#15 0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#16 0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#17 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) 
-------------- next part --------------
#  /etc/rsyslog.conf	Configuration file for rsyslog v3.
#
#			For more information see 
#			/usr/share/doc/rsyslog-doc/html/rsyslog_conf.html


#################
#### MODULES ####
#################

$ModLoad imuxsock # provides support for local system logging
$ModLoad imklog   # provides kernel logging support (previously done by rklogd) 
#$ModLoad immark  # provides --MARK-- message capability

# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514


###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use default timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf


###############
#### RULES ####
###############

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*			/var/log/auth.log
*.*;auth,authpriv.none		-/var/log/syslog
#cron.*				/var/log/cron.log
daemon.*			-/var/log/daemon.log
kern.*				-/var/log/kern.log
lpr.*				-/var/log/lpr.log
#mail.*				-/var/log/mail.log
user.*				-/var/log/user.log

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info			-/var/log/mail.info
mail.warn			-/var/log/mail.warn
mail.err			/var/log/mail.err

#
# Logging for INN news system.
#
news.crit			/var/log/news/news.crit
news.err			/var/log/news/news.err
news.notice			-/var/log/news/news.notice

#
# Some "catch-all" log files.
#
*.=debug;\
	auth,authpriv.none;\
	news.none;mail.none	-/var/log/debug
*.=info;*.=notice;*.=warn;\
	auth,authpriv.none;\
	cron,daemon.none;\
	mail,news.none		-/var/log/messages

#
# Emergencies are sent to everybody logged in.
#
*.emerg				*

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;\
#	news.=crit;news.=err;news.=notice;\
#	*.=debug;*.=info;\
#	*.=notice;*.=warn	/dev/tty8

# The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
# you must invoke `xconsole' with the `-file' option:
# 
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
#      busy site..
#
daemon.*;mail.*;\
	news.err;\
	*.=debug;*.=info;\
	*.=notice;*.=warn	|/dev/xconsole
-------------- next part --------------
#$ModLoad omrelp 
$WorkDirectory /var/log/rsyslog 
$ActionQueueType LinkedList   # use asynchronous processing
$ActionQueueFileName srvrfwd  # set file name, also enables disk mode
$ActionResumeRetryCount -1    # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
mail.* @@<remote_addr>:514

$ActionExecOnlyIfPreviousIsSuspended on
& /var/log/rsyslog/failover.log
$ActionExecOnlyIfPreviousIsSuspended off

-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Core was generated by `/usr/sbin/rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 23847]
[New process 23849]
[New process 23848]
[New process 23846]
[New process 23845]
#0  0x00002b479d1c3ef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 23845):
#0  0x00002b479d25af12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x000000000040e0c9 in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:2563
	iRet = <value optimized out>
	i = <value optimized out>
	p = <value optimized out>
	num_fds = <value optimized out>
	ch = <value optimized out>
	hent = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0x1, 
    sa_sigaction = 0x1}, sa_mask = {__val = {0 <repeats 16 times>}}, 
  sa_flags = 0, sa_restorer = 0}
	bIsFirstOption = <value optimized out>
	bEOptionWasGiven = <value optimized out>
	bImUxSockLoaded = <value optimized out>
	arg = <value optimized out>
	legacyConfLine = '\0' <repeats 79 times>
#2  0x00002b479d1b01a6 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#3  0x0000000000409609 in _start ()
No locals.

Thread 4 (process 23846):
#0  0x00002b479cb72fad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x0000000000418e00 in wtiWorker (pThis=0x64f4a0) at wti.c:403
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130748, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094035857682333242, 9093894727638318650}, __mask_was_saved = 0}}, 
  __pad = {0x408000d0, 0x0, 0x40800950, 0x40800950}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	t = {tv_sec = 1221135378, tv_nsec = 723151645}
	pWtp = (wtp_t *) 0x64f360
	bInactivityTOOccured = 0
#2  0x0000000000418032 in wtpWorker (arg=<value optimized out>) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130512, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094034911474613818, 9093894729333866042}, __mask_was_saved = 0}}, 
  __pad = {0x408001e0, 0x0, 0x40800950, 0x40800950}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	pWti = (wti_t *) 0x64f4a0
	pThis = (wtp_t *) 0x64f360
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#3  0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 3 (process 23848):
#0  0x00002b479d25af12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b479db01413 in runInput (pThrd=<value optimized out>)
    at imuxsock.c:235
	maxfds = 0
	nfds = <value optimized out>
	i = <value optimized out>
	fd = <value optimized out>
	readfds = {fds_bits = {1, 0 <repeats 15 times>}}
#2  0x0000000000416420 in thrdStarter (arg=0x66bd70) at threads.c:139
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#3  0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 2 (process 23849):
#0  0x00002b479cb757eb in read () from /lib/libpthread.so.0
No symbol table info available.
#1  0x00002b479dd05c5f in klogLogKMsg () at linux.c:454
No locals.
#2  0x00002b479dd0517c in runInput (pThrd=0x66c1f0) at imklog.c:208
	iRet = <value optimized out>
#3  0x0000000000416420 in thrdStarter (arg=0x66c1f0) at threads.c:139
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#4  0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 1 (process 23847):
#0  0x00002b479d1c3ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b479d1c5413 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x0000000000411abf in sigsegvHdlr (signum=6) at debug.c:741
	signame = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
  sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0}
#3  <signal handler called>
No symbol table info available.
#4  0x00002b479d1c3ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#5  0x00002b479d1c5413 in abort () from /lib/libc.so.6
No symbol table info available.
#6  0x00002b479d2003e8 in __libc_message () from /lib/libc.so.6
No symbol table info available.
#7  0x00002b479d205968 in malloc_printerr () from /lib/libc.so.6
No symbol table info available.
#8  0x00002b479d207a76 in free () from /lib/libc.so.6
No symbol table info available.
#9  0x0000000000420f2d in msgDestruct (ppThis=0x6532a0) at msg.c:284
	iCancelStateSave = 0
	pThis = (msg_t *) 0x2aaab401e480
#10 0x000000000042a797 in actionCallAction (pAction=0x653240, 
    pMsg=0x2aaab0020620) at action.c:661
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090522832, 
        9093895273491594810, 6631600, 1090522832, 4238944, 1090522856, 
        9094038209632009786, 9093894735514959418}, __mask_was_saved = 0}}, 
  __pad = {0x41000f70, 0x0, 0xbf11, 0x0}}
	__cancel_arg = (void *) 0x6532f0
	not_first_call = <value optimized out>
	iRet = <value optimized out>
	iCancelStateSave = 0
#11 0x000000000040ae79 in processMsgDoActions (pData=0x5d25, pParam=0x41000ed0)
    at syslogd.c:1094
	iRet = <value optimized out>
	iRetMod = <value optimized out>
#12 0x0000000000429b97 in llExecFunc (pThis=0x6530b0, 
    pFunc=0x40ae60 <processMsgDoActions>, pParam=0x41000ed0)
    at linkedlist.c:390
	iRet = RS_RET_OK
	llCookie = (linkedListCookie_t) 0x652c60
	llCookiePrev = (linkedListCookie_t) 0x0
#13 0x000000000040aab0 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=<value optimized out>) at syslogd.c:1137
	pMsg = (msg_t *) 0x2aaab0020620
#14 0x000000000041aa31 in queueConsumerReg (pThis=0x656980, pWti=0x64bcf0, 
    iCancelStateSave=<value optimized out>) at queue.c:1570
	iRet = RS_RET_OK
#15 0x0000000000418e6f in wtiWorker (pThis=0x64bcf0) at wti.c:413
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523452, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094038209713798714, 9093894727638318650}, __mask_was_saved = 0}}, 
  __pad = {0x410010d0, 0x0, 0x0, 0x0}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	t = {tv_sec = 1221135378, tv_nsec = 595602238}
	pWtp = (wtp_t *) 0x64bbb0
	bInactivityTOOccured = 0
#16 0x0000000000418032 in wtpWorker (arg=<value optimized out>) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523216, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094038210546368058, 9093894729333866042}, __mask_was_saved = 0}}, 
  __pad = {0x410011e0, 0x0, 0x0, 0x0}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	pWti = (wti_t *) 0x64bcf0
	pThis = (wtp_t *) 0x64bbb0
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#17 0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#18 0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#19 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) quit

From hks.private at gmail.com  Mon Sep 15 19:06:23 2008
From: hks.private at gmail.com ((private) HKS)
Date: Mon, 15 Sep 2008 13:06:23 -0400
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
Message-ID: <ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>

What version of rsyslog is this?

-HKS

On Fri, Sep 12, 2008 at 6:40 AM, Lorenzo M. Catucci
<lorenzo at sancho.ccd.uniroma2.it> wrote:
> The system is a dual processor / quad core Xeon E5335 running a 64 bit
> debian lenny distribution; I've enabled both debug and rtinst configure,
> and installed an unstripped binary; I'm attaching the full backtrace here.
>
> the system should act as a client to a remote syslog server; I'm enclosing
> the conf files too.
>
> In the previous attempts (before enabling rtinst and debug), I got lines
> like "rsyslogd: double free or corruption (!prev): 0x0000000000674c50"
> in the failover log (corresponding to the _nodebug backtrace); this last
> time, the line I've got is
>
> "msg.c:273: msgDestruct: Assertion `(unsigned) ((obj_t*)
>           (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed."
>
> and the double free detector didn't fire.
>
> I'm really at a loss now: I've been lured into experimenting rsyslog from
> the high level architectural description being this clean and seemingly
> powerful, but now I fear I still cannot rely on this logger in production.
>
> Eager to help in debugging, sincerely yours
>
>        lorenzo
>
>
>
> +-------------------------+----------------------------------------------+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
> +-------------------------+----------------------------------------------+
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
>


From david at lang.hm  Tue Sep 16 06:44:30 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 21:44:30 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
	<1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
	<1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>
Message-ID: <alpine.DEB.1.10.0809152143060.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, david at lang.hm wrote:

> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>
>> side-note: do you mind if we concentrate on the performance issue first
>> and keep an eye on this here (as a secondary goal) while we do it? I
>> think that would enable me to address both most quickly (I can add
>> instrumentation code/checks while I modify the file output). There may
>> come a time when reversing priorities makes sense, but for now I think
>> this would be the best way...
>
> no problem.

an interesting tidbit, once I started the performance testing with name 
lookups turned off I haven't had a failure of the rotation.

I left it running overnight under heavy load, so I'll see how far it got 
in the morning.

David Lang

>> Rainer
>> On Mon, 2008-09-15 at 11:57 +0200, Rainer Gerhards wrote:
>>> mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
>>> still has no source line information. Without that, it has very little
>>> value. OK, I'll look at some other ways.
>>
>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Tue Sep 16 07:17:02 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 16 Sep 2008 07:17:02 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809152143060.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm><1221462796.2682.28.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm><1221463183.2682.32.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm><1221463684.2682.37.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm><1221464240.2682.41.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm><1221467031.2682.48.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm><1221469046.2682.50.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm><1221470899.2682.60.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm><1221472634.2682.62.camel@rgf9dev.intern.adiscon.com><1221473625.2682.65.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>
	<alpine.DEB.1.10.0809152143060.17326@asg ard.lang.hm>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F147@grfint2.intern.adiscon.com>

> an interesting tidbit, once I started the performance testing with
name
> lookups turned off I haven't had a failure of the rotation.
> 
> I left it running overnight under heavy load, so I'll see how far it
> got
> in the morning.

Oh, that's very interesting.

Looking forward to the results.

Rainer


From lorenzo at sancho.ccd.uniroma2.it  Tue Sep 16 09:50:11 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Tue, 16 Sep 2008 09:50:11 +0200 (CEST)
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
	<ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>

On Mon, 15 Sep 2008, (private) HKS wrote:

> What version of rsyslog is this?
>
> -HKS
>

At first it was with pristine debian's 3.18.2; I later tried upgrading to 
3.18.3 but the problem persisted.

Sorry for confusion.

Thank you,

 	lorenzo


From hks.private at gmail.com  Tue Sep 16 15:52:49 2008
From: hks.private at gmail.com ((private) HKS)
Date: Tue, 16 Sep 2008 09:52:49 -0400
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
	<ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>
	<alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>
Message-ID: <ac9ded160809160652v7a6e0598q37a17452523d270a@mail.gmail.com>

This looks similar to the issue I reported at
http://kb.monitorware.com/random-daemon-stops-t8626.html

I haven't been able to reproduce it with any frequency, so hopefully
your data will be what Rainer needs to track this down.

-HKS


On Tue, Sep 16, 2008 at 3:50 AM, Lorenzo M. Catucci
<lorenzo at sancho.ccd.uniroma2.it> wrote:
> On Mon, 15 Sep 2008, (private) HKS wrote:
>
>> What version of rsyslog is this?
>>
>> -HKS
>>
>
> At first it was with pristine debian's 3.18.2; I later tried upgrading to
> 3.18.3 but the problem persisted.
>
> Sorry for confusion.
>
> Thank you,
>
>        lorenzo
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Tue Sep 16 15:54:00 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 16 Sep 2008 15:54:00 +0200
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <ac9ded160809160652v7a6e0598q37a17452523d270a@mail.gmail.com>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it><ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com><alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>
	<ac9ded160809160652v7a6e0598q37a17452523d270a@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F155@grfint2.intern.adiscon.com>

Sorry for not replying yet. I am currently very busy with another
activity. Though not a crash, I'd like to finish that first, before I
lose the context that was so costly to achive ;)

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of (private) HKS
> Sent: Tuesday, September 16, 2008 3:53 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog frequent crashes
> 
> This looks similar to the issue I reported at
> http://kb.monitorware.com/random-daemon-stops-t8626.html
> 
> I haven't been able to reproduce it with any frequency, so hopefully
> your data will be what Rainer needs to track this down.
> 
> -HKS
> 
> 
> On Tue, Sep 16, 2008 at 3:50 AM, Lorenzo M. Catucci
> <lorenzo at sancho.ccd.uniroma2.it> wrote:
> > On Mon, 15 Sep 2008, (private) HKS wrote:
> >
> >> What version of rsyslog is this?
> >>
> >> -HKS
> >>
> >
> > At first it was with pristine debian's 3.18.2; I later tried
> upgrading to
> > 3.18.3 but the problem persisted.
> >
> > Sorry for confusion.
> >
> > Thank you,
> >
> >        lorenzo
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> >
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From david at lang.hm  Tue Sep 16 19:03:54 2008
From: david at lang.hm (david at lang.hm)
Date: Tue, 16 Sep 2008 10:03:54 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F147@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F147@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809161002240.21981@asgard.lang.hm>

On Tue, 16 Sep 2008, Rainer Gerhards wrote:

>> an interesting tidbit, once I started the performance testing with
> name
>> lookups turned off I haven't had a failure of the rotation.
>>
>> I left it running overnight under heavy load, so I'll see how far it
>> got
>> in the morning.
>
> Oh, that's very interesting.
>
> Looking forward to the results.

a little more detail.

if I do an strace of a thread when I do the HUP, that thread does not 
close properly and never releases the file (I think the same thing was 
happening when I tried to run it under valgrind)

with name lookups disabled it ran overnight rotating once a min 
(processing 40,000 requests/sec)

David Lang


From rgerhards at hq.adiscon.com  Wed Sep 17 15:42:16 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 17 Sep 2008 15:42:16 +0200
Subject: [rsyslog] Change to mark message algo
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F16A@grfint2.intern.adiscon.com>

Hi,

initially driven by a performance discussion, the question has come up
when mark messages should be processed.

The current implementation is (by design) close to what sysklogd does:
marks are generated in intervals for all outputs (files and such) and
are send to each of the outputs. The outputs process the mark message if
the output was idle for at least half the past interval (otherwise, the
mark is simply ignored).

So, looking from an individual output's point of view, mark messages do
not happen at precise intervals after the last message was processed by
the output, but seem to be rather random from that POV.

In rsyslog, I use the time the message was handed over to the output as
the time of last processing. Some (namely David Lang in the link below)
can argue that this is incorrect, or at least not the only way to handle
it valid. The argument is that the time of message reception is the one
to look at when processing marks. After some hesitation, I see some
logic in this definition and I am very tempted to change rsyslog to use
that definition. Obviously, this can result in different mark handling
than to what we have today. Usually, though, things are not really
different, but they may become quite different if a messages was stuck
in a queue for some time.

I invite you to have a look at the relevant forum discussion. This is a
good entry point:

http://kb.monitorware.com/rsyslog-performance-t8691-30.html#p13825

Please let me know if you have any concerns. If I do not hear anything,
I'll change rsyslog to use the reception timestamp. This also has
performance benefit.

Thanks,
Rainer


From hks.private at gmail.com  Wed Sep 17 16:41:22 2008
From: hks.private at gmail.com ((private) HKS)
Date: Wed, 17 Sep 2008 10:41:22 -0400
Subject: [rsyslog] Change to mark message algo
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F16A@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16A@grfint2.intern.adiscon.com>
Message-ID: <ac9ded160809170741t29870421g9f68c5b0e176cbee@mail.gmail.com>

No concerns here - that makes significantly more sense to an
undereducated sysadmin.

-HKS

On Wed, Sep 17, 2008 at 9:42 AM, Rainer Gerhards
<rgerhards at hq.adiscon.com> wrote:
> Hi,
>
> initially driven by a performance discussion, the question has come up
> when mark messages should be processed.
>
> The current implementation is (by design) close to what sysklogd does:
> marks are generated in intervals for all outputs (files and such) and
> are send to each of the outputs. The outputs process the mark message if
> the output was idle for at least half the past interval (otherwise, the
> mark is simply ignored).
>
> So, looking from an individual output's point of view, mark messages do
> not happen at precise intervals after the last message was processed by
> the output, but seem to be rather random from that POV.
>
> In rsyslog, I use the time the message was handed over to the output as
> the time of last processing. Some (namely David Lang in the link below)
> can argue that this is incorrect, or at least not the only way to handle
> it valid. The argument is that the time of message reception is the one
> to look at when processing marks. After some hesitation, I see some
> logic in this definition and I am very tempted to change rsyslog to use
> that definition. Obviously, this can result in different mark handling
> than to what we have today. Usually, though, things are not really
> different, but they may become quite different if a messages was stuck
> in a queue for some time.
>
> I invite you to have a look at the relevant forum discussion. This is a
> good entry point:
>
> http://kb.monitorware.com/rsyslog-performance-t8691-30.html#p13825
>
> Please let me know if you have any concerns. If I do not hear anything,
> I'll change rsyslog to use the reception timestamp. This also has
> performance benefit.
>
> Thanks,
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Wed Sep 17 17:57:25 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 17 Sep 2008 17:57:25 +0200
Subject: [rsyslog] abort cases
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>

Hi,

just an update. While I have been silent, I am looking at the aborts
that were recently reported. I think they are related to threading
issues. I am reviewing some code and conducting some tests. This
unfortunately takes some time. I just wanted to let you know that
something is happening ;)

Interestingly, this seems to play nicely with the performance
optimization effort. It may even be that removing the cause could
improve performance, but it is too early to be sure it will... I have
not yet identified a sure cause.

I will keep you updated and post questions when I have them.

Thanks,
Rainer


From lorenzo at sancho.ccd.uniroma2.it  Wed Sep 17 18:46:22 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Wed, 17 Sep 2008 18:46:22 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>

On Wed, 17 Sep 2008, Rainer Gerhards wrote:

> Hi,
>
> just an update. While I have been silent, I am looking at the aborts
> that were recently reported. I think they are related to threading
> issues. I am reviewing some code and conducting some tests. This
> unfortunately takes some time. I just wanted to let you know that
> something is happening ;)
>

In the meanwhile, I've compiled once more with --enable-valgrind and I'm 
running the daemon under valgrind. Since with no other change the daemon 
is still running, while it usually didn't last more than 12 hours, it 
seems the timing variation does somewhat cure the symptoms.

>
> Interestingly, this seems to play nicely with the performance
> optimization effort. It may even be that removing the cause could
> improve performance, but it is too early to be sure it will... I have
> not yet identified a sure cause.
>
> I will keep you updated and post questions when I have them.
>

We are all waiting for you questions... in the hope we can be of any help!

Thank you, yours

 	lorenzo


From rgerhards at hq.adiscon.com  Wed Sep 17 18:49:01 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 17 Sep 2008 18:49:01 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>

> > just an update. While I have been silent, I am looking at the aborts
> > that were recently reported. I think they are related to threading
> > issues. I am reviewing some code and conducting some tests. This
> > unfortunately takes some time. I just wanted to let you know that
> > something is happening ;)
> >
> 
> In the meanwhile, I've compiled once more with --enable-valgrind and
> I'm
> running the daemon under valgrind. Since with no other change the
> daemon
> is still running, while it usually didn't last more than 12 hours, it
> seems the timing variation does somewhat cure the symptoms.

This is what I am thinking, too. I am running it under helgrind. If you
do that, you'll see a couple of warnings, most have been found to be
harmless by previous analysis. Anyhow, I am re-doing the analysis now
(what takes quite a bit of time). I am just telling you so that you
don't wonder when you see so many warnings. I think there is even a
discussion thread somewhere telling why this is. Mostly it is cases
where we do not really need sync... or so I thought ;)

Rainer


From lorenzo at sancho.ccd.uniroma2.it  Wed Sep 17 19:36:42 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Wed, 17 Sep 2008 19:36:42 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>

>> is still running, while it usually didn't last more than 12 hours, it
>> seems the timing variation does somewhat cure the symptoms.
>
> This is what I am thinking, too. I am running it under helgrind. If you
> do that, you'll see a couple of warnings, most have been found to be
> harmless by previous analysis. Anyhow, I am re-doing the analysis now
> (what takes quite a bit of time). I am just telling you so that you
> don't wonder when you see so many warnings. I think there is even a
> discussion thread somewhere telling why this is. Mostly it is cases
> where we do not really need sync... or so I thought ;)
>

Just to help me understand, do you think val-grinding this time is 
near-to-useless, and I'd better restart the daemon under helgrind, or you 
prefer I continue valgrinding while you helgrind?

I feared uttering the words "race condition" would have been doing just 
like the patient telling the doctor what he does want to hear as a 
dyagnosis... now that I see you are looking for missing syncs I think we 
share this gut feeling... Please let me know if I can help more, since 
I'm somewhat in the hope this dreaded shared memory 8 way system could 
very well shake the races... As a matter of fact, the destination server 
is a twin-brother of the source one, and is running (and logging to 
postgresql) without any hiccup since started-up.

Thank you very much, yours,

 	lorenzo


From rgerhards at hq.adiscon.com  Thu Sep 18 09:23:11 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 09:23:11 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
Message-ID: <1221722591.2682.137.camel@rgf9dev.intern.adiscon.com>

On Wed, 2008-09-17 at 19:36 +0200, Lorenzo M. Catucci wrote:
> >> is still running, while it usually didn't last more than 12 hours, it
> >> seems the timing variation does somewhat cure the symptoms.
> >
> > This is what I am thinking, too. I am running it under helgrind. If you
> > do that, you'll see a couple of warnings, most have been found to be
> > harmless by previous analysis. Anyhow, I am re-doing the analysis now
> > (what takes quite a bit of time). I am just telling you so that you
> > don't wonder when you see so many warnings. I think there is even a
> > discussion thread somewhere telling why this is. Mostly it is cases
> > where we do not really need sync... or so I thought ;)
> >
> 
> Just to help me understand, do you think val-grinding this time is 
> near-to-useless, and I'd better restart the daemon under helgrind, or you 
> prefer I continue valgrinding while you helgrind?

>From a pragmatical POV: if running it under valgrind helps ease the
immediate problem, please do that. I suspect valgrind will not report
anything, but if it does, that would probably be very interesting.

Using valgrind's helgrind tool does not make sense to you, because it
emits lots of message, which need to be interpreted by someone with deep
knowledge of the code. This is what I am looking at.

> I feared uttering the words "race condition" would have been doing just 
> like the patient telling the doctor what he does want to hear as a 
> dyagnosis... now that I see you are looking for missing syncs I think we 
> share this gut feeling... 

Yes, definitely. There is also one not directly technical reason that
makes me believe this: we had almost no serious issue with rsyslog since
the highly parallel multi-threading engine was introduced. I was a bit
astonished, because doing such a complex beast absolutely correctly in
the first place - even with the lots of testing it received in my
environment - is something I only very seldomly hear about. Now, out of
the sudden, multiple bug reports, all pointing into the same direction
come in. I now conclude that many folks were hesitant to actually use
the new version and now that time has passed, deployments into high
demand environments begin. Unfortunately, I do not have funding for the
high end machines and the amount of time required to do all these high
end testing after the release was finished (and even if I had, I'd
probably still not seen one issue or the other). So it sounds somewhat
logical to me that we have now begun to actually do the firedrill for
the new highly parallel processing part. And that, of course, points
into issues with thread execution order, aka race conditions ;) This
direction would also explain why the issues did not come up earlier
(with reasoning given above).

> Please let me know if I can help more, since 
> I'm somewhat in the hope this dreaded shared memory 8 way system could 
> very well shake the races... As a matter of fact, the destination server 
> is a twin-brother of the source one, and is running (and logging to 
> postgresql) without any hiccup since started-up.

All you can do at this time is being patient. I am reviewing the code.
The worker thread pools and all this logic is highly complex. I must
make sure that I have again a very tight grip on it, review all the
subtle cases I came along and then look at the helgrind output and other
diagnostic sources to see where the issue is. Probably then it would be
useful to have a gdb backtrace of an aborted process (or the more the
better), but my experience with these kinds of problems is that good
analysis is more likely to solve them than any captured real-time data.

As soon as I have a question, I'll post. Should you notice something
that you find interesting, please post. Ignoring something is easy, not
knowing something that may potentially help would be bad ;)

Rainer



From rgerhards at hq.adiscon.com  Thu Sep 18 09:35:17 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 09:35:17 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
Message-ID: <1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>

> Please let me know if I can help more, since 
> I'm somewhat in the hope this dreaded shared memory 8 way system could 
> very well shake the races... As a matter of fact, the destination server 
> is a twin-brother of the source one, and is running (and logging to 
> postgresql) without any hiccup since started-up.

Oh, I forgot, there is one thing you could actually do: I do not intend
to do any threading changes to the current stable. This may sound silly,
because it looks like a bug, but I expect that a lot of changes need to
be done, especially to make helgrind happy (so that it can be used). The
amount of changes I expect are far too intrusive for the stable. After
all, the majority of folks do not experience the bug. So the "fix" will
become part of the current devel.

As such, it would be very useful for me if you could try out the latest
devel versions as I modify them. It would be really great if you could
pull them from my git archive at git.adiscon.com/git/rsyslog.git

The same to everyone else interested in this work ;)

Rainer



From rgerhards at hq.adiscon.com  Thu Sep 18 09:59:15 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 09:59:15 +0200
Subject: [rsyslog] rsyslog 3.18.4 released
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F170@grfint2.intern.adiscon.com>

Hi all,

I have just released rsyslog 3.18.4, a member of the v3-stable branch.
This is a bugfixing release. It contains a number of fixes, most
importantly one that could cause undesired message discarding when the
queue is nearly full. This was caused by an invalid default enabling
discard-on-queue-full when this was not explicitly configured. There are
also other fixes. All users of the v3-stable branch are advised to
update to this release.

Changelog with full details:
http://www.rsyslog.com/Article277.phtml

Download:
http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-131.phtml

I hope this release is useful. As always, feedback is greatly
appreciated.
Rainer


From rgerhards at hq.adiscon.com  Thu Sep 18 10:14:35 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 10:14:35 +0200
Subject: [rsyslog] autoconf support for atomic operations
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>

Hi all,

in my effort to get a clean helgrind output (and to solve the stability
problems that recently showed up, I am going to re-enable support for
atomic operations). Unfortunately, the following post is still correct
and I do not know how to use autotools to check for the ability of
atomic operations:

http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html

While the post contains a potentially good pointer to a solution, I do
not know how to apply it to rsyslog ;) If anyone could lend me a helping
hand, that would be great. In the meantime, I'll simply go and make a
--enable-atomic ./configure switch - that's IMHO the best solution given
the current state of affairs.

Rainer


From rgerhards at hq.adiscon.com  Thu Sep 18 10:35:27 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 10:35:27 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>

Hold on... I should have searched first, then asked. Looks like I found
a solution. Will post more later.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Thursday, September 18, 2008 10:15 AM
> To: rsyslog-users
> Subject: [rsyslog] autoconf support for atomic operations
> 
> Hi all,
> 
> in my effort to get a clean helgrind output (and to solve the
stability
> problems that recently showed up, I am going to re-enable support for
> atomic operations). Unfortunately, the following post is still correct
> and I do not know how to use autotools to check for the ability of
> atomic operations:
> 
> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> 
> While the post contains a potentially good pointer to a solution, I do
> not know how to apply it to rsyslog ;) If anyone could lend me a
> helping
> hand, that would be great. In the meantime, I'll simply go and make a
> --enable-atomic ./configure switch - that's IMHO the best solution
> given
> the current state of affairs.
> 
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Thu Sep 18 10:50:38 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 10:50:38 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>

Yes, looks like it works. This is what I did:

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123c
83383ba256c4e67679c8d

Comments are appreciated.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Thursday, September 18, 2008 10:35 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] autoconf support for atomic operations
> 
> Hold on... I should have searched first, then asked. Looks like I
found
> a solution. Will post more later.
> 
> Rainer
> 
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> > Sent: Thursday, September 18, 2008 10:15 AM
> > To: rsyslog-users
> > Subject: [rsyslog] autoconf support for atomic operations
> >
> > Hi all,
> >
> > in my effort to get a clean helgrind output (and to solve the
> stability
> > problems that recently showed up, I am going to re-enable support
for
> > atomic operations). Unfortunately, the following post is still
> correct
> > and I do not know how to use autotools to check for the ability of
> > atomic operations:
> >
> > http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> >
> > While the post contains a potentially good pointer to a solution, I
> do
> > not know how to apply it to rsyslog ;) If anyone could lend me a
> > helping
> > hand, that would be great. In the meantime, I'll simply go and make
a
> > --enable-atomic ./configure switch - that's IMHO the best solution
> > given
> > the current state of affairs.
> >
> > Rainer
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From lorenzo at sancho.ccd.uniroma2.it  Thu Sep 18 11:08:29 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Thu, 18 Sep 2008 11:08:29 +0200 (CEST)
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>

Rainer,
 	I cloned your repo with

$ git clone http://git.adiscon.com/git/rsyslog.git rsyslog.git

now, I'm completely clueless about git, but I'm unable to find the 
helgrind branch with

$ git branch -r

I tried doing a git pull, but all I got was an "Already up-to-date." 
reply...

Should I simply wait for the helgrind branch to get merged into master, or 
there is some way to pull the new branch here?

Thank you very much, yours

 	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

On Thu, 18 Sep 2008, Rainer Gerhards wrote:

> Yes, looks like it works. This is what I did:
>
> http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123c
> 83383ba256c4e67679c8d
>
> Comments are appreciated.
>
> Rainer
>
>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
>> Sent: Thursday, September 18, 2008 10:35 AM
>> To: rsyslog-users
>> Subject: Re: [rsyslog] autoconf support for atomic operations
>>
>> Hold on... I should have searched first, then asked. Looks like I
> found
>> a solution. Will post more later.
>>
>> Rainer
>>
>>> -----Original Message-----
>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
>>> Sent: Thursday, September 18, 2008 10:15 AM
>>> To: rsyslog-users
>>> Subject: [rsyslog] autoconf support for atomic operations
>>>
>>> Hi all,
>>>
>>> in my effort to get a clean helgrind output (and to solve the
>> stability
>>> problems that recently showed up, I am going to re-enable support
> for
>>> atomic operations). Unfortunately, the following post is still
>> correct
>>> and I do not know how to use autotools to check for the ability of
>>> atomic operations:
>>>
>>> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
>>>
>>> While the post contains a potentially good pointer to a solution, I
>> do
>>> not know how to apply it to rsyslog ;) If anyone could lend me a
>>> helping
>>> hand, that would be great. In the meantime, I'll simply go and make
> a
>>> --enable-atomic ./configure switch - that's IMHO the best solution
>>> given
>>> the current state of affairs.
>>>
>>> Rainer
>>> _______________________________________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>

From rgerhards at hq.adiscon.com  Thu Sep 18 11:10:13 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 11:10:13 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F175@grfint2.intern.adiscon.com>

Hi Lorenzo,

I pushed the helgrind branch only a few minutes ago. It may be worth retrying

$ git pull
$ git branch -r

In any case, I expect that I merge the helgrind branch into master as soon as possible (which may mean quite a while, though).

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Lorenzo M. Catucci
> Sent: Thursday, September 18, 2008 11:08 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] autoconf support for atomic operations
> 
> Rainer,
>  	I cloned your repo with
> 
> $ git clone http://git.adiscon.com/git/rsyslog.git rsyslog.git
> 
> now, I'm completely clueless about git, but I'm unable to find the
> helgrind branch with
> 
> $ git branch -r
> 
> I tried doing a git pull, but all I got was an "Already up-to-date."
> reply...
> 
> Should I simply wait for the helgrind branch to get merged into master,
> or
> there is some way to pull the new branch here?
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+
> 
> On Thu, 18 Sep 2008, Rainer Gerhards wrote:
> 
> > Yes, looks like it works. This is what I did:
> >
> >
> http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123
> c
> > 83383ba256c4e67679c8d
> >
> > Comments are appreciated.
> >
> > Rainer
> >
> >> -----Original Message-----
> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >> Sent: Thursday, September 18, 2008 10:35 AM
> >> To: rsyslog-users
> >> Subject: Re: [rsyslog] autoconf support for atomic operations
> >>
> >> Hold on... I should have searched first, then asked. Looks like I
> > found
> >> a solution. Will post more later.
> >>
> >> Rainer
> >>
> >>> -----Original Message-----
> >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >>> Sent: Thursday, September 18, 2008 10:15 AM
> >>> To: rsyslog-users
> >>> Subject: [rsyslog] autoconf support for atomic operations
> >>>
> >>> Hi all,
> >>>
> >>> in my effort to get a clean helgrind output (and to solve the
> >> stability
> >>> problems that recently showed up, I am going to re-enable support
> > for
> >>> atomic operations). Unfortunately, the following post is still
> >> correct
> >>> and I do not know how to use autotools to check for the ability of
> >>> atomic operations:
> >>>
> >>> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> >>>
> >>> While the post contains a potentially good pointer to a solution, I
> >> do
> >>> not know how to apply it to rsyslog ;) If anyone could lend me a
> >>> helping
> >>> hand, that would be great. In the meantime, I'll simply go and make
> > a
> >>> --enable-atomic ./configure switch - that's IMHO the best solution
> >>> given
> >>> the current state of affairs.
> >>>
> >>> Rainer
> >>> _______________________________________________
> >>> rsyslog mailing list
> >>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> >


From rgerhards at hq.adiscon.com  Thu Sep 18 12:24:29 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 12:24:29 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
Message-ID: <1221733469.2682.146.camel@rgf9dev.intern.adiscon.com>

Lorenzo and all,

much quicker than I expected, I found one quirk that could - though very
unlikely - be at the root of all these problems. I have done a first
fix, which can be found here:

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=4c96ebdcfe075e80810b01257cf21ea1c9b3ec0e

I'd appreciate if you could pull the helgrind branch and see if
something changes. If you can't pull it for whatever reason, a snapshot
is available via the gitweb:

http://git.adiscon.com/?p=rsyslog.git;a=snapshot;h=4c96ebdcfe075e80810b01257cf21ea1c9b3ec0e;sf=tgz

Rainer

On Thu, 2008-09-18 at 11:08 +0200, Lorenzo M. Catucci wrote:
> Rainer,
>  	I cloned your repo with
> 
> $ git clone http://git.adiscon.com/git/rsyslog.git rsyslog.git
> 
> now, I'm completely clueless about git, but I'm unable to find the 
> helgrind branch with
> 
> $ git branch -r
> 
> I tried doing a git pull, but all I got was an "Already up-to-date." 
> reply...
> 
> Should I simply wait for the helgrind branch to get merged into master, or 
> there is some way to pull the new branch here?
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> 
> +-------------------------+----------------------------------------------+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
> +-------------------------+----------------------------------------------+
> 
> On Thu, 18 Sep 2008, Rainer Gerhards wrote:
> 
> > Yes, looks like it works. This is what I did:
> >
> > http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123c
> > 83383ba256c4e67679c8d
> >
> > Comments are appreciated.
> >
> > Rainer
> >
> >> -----Original Message-----
> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >> Sent: Thursday, September 18, 2008 10:35 AM
> >> To: rsyslog-users
> >> Subject: Re: [rsyslog] autoconf support for atomic operations
> >>
> >> Hold on... I should have searched first, then asked. Looks like I
> > found
> >> a solution. Will post more later.
> >>
> >> Rainer
> >>
> >>> -----Original Message-----
> >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >>> Sent: Thursday, September 18, 2008 10:15 AM
> >>> To: rsyslog-users
> >>> Subject: [rsyslog] autoconf support for atomic operations
> >>>
> >>> Hi all,
> >>>
> >>> in my effort to get a clean helgrind output (and to solve the
> >> stability
> >>> problems that recently showed up, I am going to re-enable support
> > for
> >>> atomic operations). Unfortunately, the following post is still
> >> correct
> >>> and I do not know how to use autotools to check for the ability of
> >>> atomic operations:
> >>>
> >>> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> >>>
> >>> While the post contains a potentially good pointer to a solution, I
> >> do
> >>> not know how to apply it to rsyslog ;) If anyone could lend me a
> >>> helping
> >>> hand, that would be great. In the meantime, I'll simply go and make
> > a
> >>> --enable-atomic ./configure switch - that's IMHO the best solution
> >>> given
> >>> the current state of affairs.
> >>>
> >>> Rainer
> >>> _______________________________________________
> >>> rsyslog mailing list
> >>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> >
> _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Thu Sep 18 12:55:23 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 12:55:23 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>

Please also read this:

http://kb.monitorware.com/post13847.html#p13847

It has some other interesting findings which leads me to believe I have
really found the culprit (or at least one of them ;)).

Feedback appreciated.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Thursday, September 18, 2008 9:35 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] abort cases
> 
> > Please let me know if I can help more, since
> > I'm somewhat in the hope this dreaded shared memory 8 way system
> could
> > very well shake the races... As a matter of fact, the destination
> server
> > is a twin-brother of the source one, and is running (and logging to
> > postgresql) without any hiccup since started-up.
> 
> Oh, I forgot, there is one thing you could actually do: I do not
intend
> to do any threading changes to the current stable. This may sound
> silly,
> because it looks like a bug, but I expect that a lot of changes need
to
> be done, especially to make helgrind happy (so that it can be used).
> The
> amount of changes I expect are far too intrusive for the stable. After
> all, the majority of folks do not experience the bug. So the "fix"
will
> become part of the current devel.
> 
> As such, it would be very useful for me if you could try out the
latest
> devel versions as I modify them. It would be really great if you could
> pull them from my git archive at git.adiscon.com/git/rsyslog.git
> 
> The same to everyone else interested in this work ;)
> 
> Rainer
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From r.bhatia at ipax.at  Thu Sep 18 13:46:28 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 18 Sep 2008 13:46:28 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
Message-ID: <48D23F94.9060904@ipax.at>

hi,

as i am quite frequently using gossamer-threads to search mailinglists
such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
could too move to gossamer-threads.

from the bottom of [1] i take:
> 
> Interested in having your list archived? Contact lists at gossamer-threads.com 
> 

rainer, any objections to sign up there?

cheers,
raoul

[1] http://www.gossamer-threads.com/lists
-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep 18 13:52:10 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 13:52:10 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <48D23F94.9060904@ipax.at>
References: <48D23F94.9060904@ipax.at>
Message-ID: <1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>

On Thu, 2008-09-18 at 13:46 +0200, Raoul Bhatia [IPAX] wrote:
> hi,
> 
> as i am quite frequently using gossamer-threads to search mailinglists
> such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
> could too move to gossamer-threads.

"move" implies that the current solution goes away... I hope that's
wrong understanding. I guess it is more like www.mail-archive.com, which
simply subscribes to the list, archives posts and indexes them.
> 
> from the bottom of [1] i take:
> > 
> > Interested in having your list archived? Contact lists at gossamer-threads.com 
> > 
> 
> rainer, any objections to sign up there?

If it is like mail-archive and I do not need to do anything than to say
"OK", that's fine with me. If it is more work, I quite honestly do not
see why I should want that ;)

Rainer
> 
> cheers,
> raoul
> 
> [1] http://www.gossamer-threads.com/lists



From r.bhatia at ipax.at  Thu Sep 18 13:54:40 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 18 Sep 2008 13:54:40 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>
References: <48D23F94.9060904@ipax.at>
	<1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>
Message-ID: <48D24180.7030409@ipax.at>

Rainer Gerhards wrote:
> On Thu, 2008-09-18 at 13:46 +0200, Raoul Bhatia [IPAX] wrote:
>> hi,
>>
>> as i am quite frequently using gossamer-threads to search mailinglists
>> such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
>> could too move to gossamer-threads.
> 
> "move" implies that the current solution goes away... I hope that's
> wrong understanding. I guess it is more like www.mail-archive.com, which
> simply subscribes to the list, archives posts and indexes them.
>> from the bottom of [1] i take:
>>> Interested in having your list archived? Contact lists at gossamer-threads.com 
>>>
>> rainer, any objections to sign up there?
> 
> If it is like mail-archive and I do not need to do anything than to say
> "OK", that's fine with me. If it is more work, I quite honestly do not
> see why I should want that ;)

to my understanding, it indeed is archiving only. and thats the sole
reason i suggested that. so let me rephrase it without the wrong term
"move":

i was wondering whether rsyslog could also be archived via
gossamer-threads.

;)

cheers,
raoul
-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep 18 13:58:05 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 13:58:05 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <48D24180.7030409@ipax.at>
References: <48D23F94.9060904@ipax.at><1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>
	<48D24180.7030409@ipax.at>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F177@grfint2.intern.adiscon.com>

Hi there,

it was suggested from users of the rsyslog project, that we have the
rsyslog mailing list added to Gossamer threads (see below). It is a
mailman mailing list hosted at 

http://lists.adiscon.net/mailman/listinfo/rsyslog

I was pointed to this mail address. Please let us know what needs to be
done or whatever information you may need.

Many thanks for looking into this.

Rainer Gerhards
rsyslog project admin

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX]
> Sent: Thursday, September 18, 2008 1:55 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] archiving rsyslog list via gossamer-threads
> 
> Rainer Gerhards wrote:
> > On Thu, 2008-09-18 at 13:46 +0200, Raoul Bhatia [IPAX] wrote:
> >> hi,
> >>
> >> as i am quite frequently using gossamer-threads to search
> mailinglists
> >> such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
> >> could too move to gossamer-threads.
> >
> > "move" implies that the current solution goes away... I hope that's
> > wrong understanding. I guess it is more like www.mail-archive.com,
> which
> > simply subscribes to the list, archives posts and indexes them.
> >> from the bottom of [1] i take:
> >>> Interested in having your list archived? Contact lists at gossamer-
> threads.com
> >>>
> >> rainer, any objections to sign up there?
> >
> > If it is like mail-archive and I do not need to do anything than to
> say
> > "OK", that's fine with me. If it is more work, I quite honestly do
> not
> > see why I should want that ;)
> 
> to my understanding, it indeed is archiving only. and thats the sole
> reason i suggested that. so let me rephrase it without the wrong term
> "move":
> 
> i was wondering whether rsyslog could also be archived via
> gossamer-threads.


From r.bhatia at ipax.at  Thu Sep 18 14:43:17 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 18 Sep 2008 14:43:17 +0200
Subject: [rsyslog] news and download link for 3.18.4
Message-ID: <48D24CE5.6030605@ipax.at>

hi,

somehow, i think that either something is messed up with the website
cms or that the news/download has not been altered yet.

	http://www.rsyslog.com/Downloads-index-req-viewdownload-cid-1-orderby-dateD.phtml
-> no download link

http://www.rsyslog.com/index.php?name=News -> no news.

cheers,
raoul
-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep 18 14:44:55 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 14:44:55 +0200
Subject: [rsyslog] news and download link for 3.18.4
In-Reply-To: <48D24CE5.6030605@ipax.at>
References: <48D24CE5.6030605@ipax.at>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F178@grfint2.intern.adiscon.com>

> somehow, i think that either something is messed up with the website
> cms or that the news/download has not been altered yet.
> 
> 	http://www.rsyslog.com/Downloads-index-req-viewdownload-cid-1-
> orderby-dateD.phtml
> -> no download link

This is the instable branch. I have to admit this is not well visible,
but there is a link to the stable releases on the top of that page, this
one:

http://www.rsyslog.com/Downloads-req-viewsdownload-sid-1.phtml

> http://www.rsyslog.com/index.php?name=News -> no news.

This, indeed, I have forgotten :) -- thx

Rainer


From lorenzo at sancho.ccd.uniroma2.it  Thu Sep 18 19:13:01 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Thu, 18 Sep 2008 19:13:01 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>

I just tried compiling and running the helgrind branch. To let configure 
finish its work, I've had to delete the PKG_CHECK_MODULES lines for RELP 
and LIBLOGGING.

Worst thing is that the daemon crashed once more; I'm enclosing the whole 
backtrace, that I've got via:

$ gdb /usr/sbin/rsyslogd /var/core-dumps/rsyslogd.core. > rsyslog_helgrind.bt << __eoc__
thread apply all bt
__eoc__

I don't know if the last line of failover.log could be of any help:

syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*) 
(pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.

Time for helgrind or valgrind?

Thank you, yours

 	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /usr/lib/rsyslog/lmnetstrms.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnetstrms.so
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/lmnsd_ptcp.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnsd_ptcp.so
Core was generated by `rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 2747]
[New process 2749]
[New process 2748]
[New process 2746]
[New process 2745]
#0  0x00002ad35493eef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 2745):
#0  0x00002ad3549d5f12 in select () from /lib/libc.so.6
#1  0x000000000040db33 in mainThread () at syslogd.c:2585
#2  0x000000000040ed0c in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:3483
#3  0x00002ad35492b1a6 in __libc_start_main () from /lib/libc.so.6
#4  0x0000000000409f79 in _start ()

Thread 4 (process 2746):
#0  0x00002ad3549c4d17 in sched_yield () from /lib/libc.so.6
#1  0x0000000000431844 in wtiWorker (pThis=0x685200) at wti.c:371
#2  0x00000000004301da in wtpWorker (arg=0x685200) at wtp.c:419
#3  0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 3 (process 2748):
#0  0x00002ad3549d5f12 in select () from /lib/libc.so.6
#1  0x00002ad35507b9dd in runInput (pThrd=<value optimized out>)
    at imuxsock.c:278
#2  0x0000000000441eef in thrdStarter (arg=0x6a6700) at ../threads.c:139
#3  0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 2 (process 2749):
#0  0x00002ad3542f07eb in read () from /lib/libpthread.so.0
#1  0x00002ad3552801bf in klogLogKMsg () at linux.c:449
#2  0x00002ad35527f554 in runInput (pThrd=0x6a7b90) at imklog.c:214
#3  0x0000000000441eef in thrdStarter (arg=0x6a7b90) at ../threads.c:139
#4  0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#5  0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (process 2747):
#0  0x00002ad35493eef5 in raise () from /lib/libc.so.6
#1  0x00002ad354940413 in abort () from /lib/libc.so.6
#2  0x0000000000422019 in sigsegvHdlr (signum=6) at debug.c:758
#3  <signal handler called>
#4  0x00002ad35493eef5 in raise () from /lib/libc.so.6
#5  0x00002ad354940413 in abort () from /lib/libc.so.6
#6  0x00002ad354937dc9 in __assert_fail () from /lib/libc.so.6
#7  0x000000000041bad6 in msgDestruct (ppThis=0x6905f8) at msg.c:274
#8  0x0000000000441824 in actionCallAction (pAction=0x690580, pMsg=0x6aeb70)
    at ../action.c:741
#9  0x000000000040afb7 in processMsgDoActions (pData=0x690580, 
    pParam=0x41000e90) at syslogd.c:1117
#10 0x000000000041c938 in llExecFunc (pThis=0x6903e0, 
    pFunc=0x40af60 <processMsgDoActions>, pParam=0x41000e90)
    at linkedlist.c:391
#11 0x000000000040ab19 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x6aeb70) at syslogd.c:1160
#12 0x000000000043ae97 in queueConsumerReg (pThis=0x690980, pWti=0x6a4600, 
    iCancelStateSave=<value optimized out>) at queue.c:1574
#13 0x0000000000431970 in wtiWorker (pThis=0x6a4600) at wti.c:413
#14 0x00000000004301da in wtpWorker (arg=0x6a4600) at wtp.c:419
#15 0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#16 0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#17 0x0000000000000000 in ?? ()
(gdb) quit

From rgerhards at hq.adiscon.com  Thu Sep 18 21:12:05 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 21:12:05 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <20080918114004.A0E4.80590B96@gossamer-threads.com>
References: <48D24180.7030409@ipax.at>
	<577465F99B41C842AAFBE9ED71E70ABA44F177@grfint2.intern.adiscon.com>
	<20080918114004.A0E4.80590B96@gossamer-threads.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F182@grfint2.intern.adiscon.com>

Hi Alex,

Thanks a lot for your fast and efficient help. Much appreciated.

Rainer 

> -----Original Message-----
> From: Alex Krohn [mailto:alex at gossamer-threads.com] 
> Sent: Thursday, September 18, 2008 8:42 PM
> To: Rainer Gerhards
> Subject: Re: [rsyslog] archiving rsyslog list via gossamer-threads
> 
> Hi Rainer,
> 
> > it was suggested from users of the rsyslog project, that we have the
> > rsyslog mailing list added to Gossamer threads (see below). It is a
> > mailman mailing list hosted at 
> > 
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > 
> > I was pointed to this mail address. Please let us know what 
> needs to be
> > done or whatever information you may need.
> 
> Sure, I've added it in:
> 
>     http://www.gossamer-threads.com/lists/rsyslog/users/
> 
> Please feel free to pass this on to the rsyslog list as I'm not
> subscribed. 
> 
> Cheers,
> 
> Alex
> 
> --
> Alex Krohn <alex at gossamer-threads.com>
> Gossamer Threads Inc. http://www.gossamer-threads.com/
> Tel: (604) 687-5804 Fax: (604) 687-5806
> 
> 


From rgerhards at hq.adiscon.com  Fri Sep 19 08:50:16 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 19 Sep 2008 08:50:16 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F186@grfint2.intern.adiscon.com>

> I don't know if the last line of failover.log could be of any help:
> 
> syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*)
> (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.
> 
Interesting...

> Time for helgrind or valgrind?

Could you run it in debug mode (-dn) and send me the log file? Maybe it
has some interesting findings in it.

On valgrind and helgrind: both is fine. If the problem is reproducible,
first run it under the memory checker and then the thread checker.
Helgrind will report a couple (20 or so) exceptions at the END of
program run, that is fine. Any other exception - in either of both - is
interesting and probably helpful.

Rainer


From rgerhards at hq.adiscon.com  Fri Sep 19 15:59:42 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 19 Sep 2008 15:59:42 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>

OK, I (thankfully) was able to see a potential race in my test environment that actually fits very well to the assert message you see. In my environment, it happens very (very!) seldom, even helgrind didn't notice until now. Please wait until I create a patch for it, I do NOT need any further info in the meantime.

Rainer

> -----Original Message-----
> From: Lorenzo M. Catucci [mailto:lorenzo at sancho.ccd.uniroma2.it]
> Sent: Thursday, September 18, 2008 7:13 PM
> To: Rainer Gerhards
> Cc: rsyslog-users
> Subject: Re: [rsyslog] abort cases
> 
> I just tried compiling and running the helgrind branch. To let
> configure
> finish its work, I've had to delete the PKG_CHECK_MODULES lines for
> RELP
> and LIBLOGGING.
> 
> Worst thing is that the daemon crashed once more; I'm enclosing the
> whole
> backtrace, that I've got via:
> 
> $ gdb /usr/sbin/rsyslogd /var/core-dumps/rsyslogd.core. >
> rsyslog_helgrind.bt << __eoc__
> thread apply all bt
> __eoc__
> 
> I don't know if the last line of failover.log could be of any help:
> 
> syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*)
> (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.
> 
> Time for helgrind or valgrind?
> 
> Thank you, yours
> 
>  	lorenzo
> 
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From rgerhards at hq.adiscon.com  Fri Sep 19 17:55:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 19 Sep 2008 17:55:14 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it><1221723317.2682.142.camel@rgf9dev.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F199@grfint2.intern.adiscon.com>

Lorenzo,

I would appreciate if you could run the latest code from "helgrind" branch. I have created one patch. It is probably not a 100% solution, but I won't manage to do much more today. And so it would be very helpful for me to know if something changes in your environment.

Thanks,
Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Friday, September 19, 2008 4:00 PM
> To: Lorenzo M. Catucci
> Cc: rsyslog-users
> Subject: Re: [rsyslog] abort cases
> 
> OK, I (thankfully) was able to see a potential race in my test
> environment that actually fits very well to the assert message you see.
> In my environment, it happens very (very!) seldom, even helgrind didn't
> notice until now. Please wait until I create a patch for it, I do NOT
> need any further info in the meantime.
> 
> Rainer
> 
> > -----Original Message-----
> > From: Lorenzo M. Catucci [mailto:lorenzo at sancho.ccd.uniroma2.it]
> > Sent: Thursday, September 18, 2008 7:13 PM
> > To: Rainer Gerhards
> > Cc: rsyslog-users
> > Subject: Re: [rsyslog] abort cases
> >
> > I just tried compiling and running the helgrind branch. To let
> > configure
> > finish its work, I've had to delete the PKG_CHECK_MODULES lines for
> > RELP
> > and LIBLOGGING.
> >
> > Worst thing is that the daemon crashed once more; I'm enclosing the
> > whole
> > backtrace, that I've got via:
> >
> > $ gdb /usr/sbin/rsyslogd /var/core-dumps/rsyslogd.core. >
> > rsyslog_helgrind.bt << __eoc__
> > thread apply all bt
> > __eoc__
> >
> > I don't know if the last line of failover.log could be of any help:
> >
> > syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*)
> > (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.
> >
> > Time for helgrind or valgrind?
> >
> > Thank you, yours
> >
> >  	lorenzo
> >
> >
> > +-------------------------+------------------------------------------
> --
> > --+
> > |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> > |
> > | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> > Vergata" |
> > |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> > ITALY |
> > |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> > |
> > +-------------------------+------------------------------------------
> --
> > --+
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From lorenzo at sancho.ccd.uniroma2.it  Fri Sep 19 23:37:31 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Fri, 19 Sep 2008 23:37:31 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F199@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it><1221723317.2682.142.camel@rgf9dev.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F199@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809192331410.19819@sancho.ccd.uniroma2.it>

As promised, I've just logged in to the server, to check if the daemon was 
still on. I found a 33M core dump; I'm enclosing the backtrace here.

Have a nice week-end,

 	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /usr/lib/rsyslog/lmnetstrms.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnetstrms.so
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/lmnsd_ptcp.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnsd_ptcp.so
Core was generated by `rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 31084]
[New process 31086]
[New process 31085]
[New process 31083]
[New process 31082]
#0  0x00002b67305cdef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 31082):
#0  0x00002b6730664f12 in select () from /lib/libc.so.6
#1  0x000000000040db33 in mainThread () at syslogd.c:2585
#2  0x000000000040ed0c in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:3483
#3  0x00002b67305ba1a6 in __libc_start_main () from /lib/libc.so.6
#4  0x0000000000409f79 in _start ()

Thread 4 (process 31083):
#0  0x00002b672ff7cfad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#1  0x0000000000431a13 in wtiWorker (pThis=0x685200) at wti.c:403
#2  0x00000000004301da in wtpWorker (arg=0x685200) at wtp.c:419
#3  0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b673066b7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 3 (process 31085):
#0  0x00002b6730664f12 in select () from /lib/libc.so.6
#1  0x00002b6730d0a9dd in runInput (pThrd=<value optimized out>)
    at imuxsock.c:278
#2  0x0000000000441eef in thrdStarter (arg=0x6a4830) at ../threads.c:139
#3  0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b673066b7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 2 (process 31086):
#0  0x00002b672ff7f7eb in read () from /lib/libpthread.so.0
#1  0x00002b6730f0f1bf in klogLogKMsg () at linux.c:449
#2  0x00002b6730f0e554 in runInput (pThrd=0x6a8340) at imklog.c:214
#3  0x0000000000441eef in thrdStarter (arg=0x6a8340) at ../threads.c:139
#4  0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#5  0x00002b673066b7cd in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (process 31084):
#0  0x00002b67305cdef5 in raise () from /lib/libc.so.6
#1  0x00002b67305cf413 in abort () from /lib/libc.so.6
#2  0x0000000000422019 in sigsegvHdlr (signum=6) at debug.c:758
#3  <signal handler called>
#4  0x00002b67305cdef5 in raise () from /lib/libc.so.6
#5  0x00002b67305cf413 in abort () from /lib/libc.so.6
#6  0x00002b67305c6dc9 in __assert_fail () from /lib/libc.so.6
#7  0x000000000041bad6 in msgDestruct (ppThis=0x68e728) at msg.c:274
#8  0x0000000000441824 in actionCallAction (pAction=0x68e6b0, 
    pMsg=0x2aaaac0014c0) at ../action.c:741
#9  0x000000000040afb7 in processMsgDoActions (pData=0x68e6b0, 
    pParam=0x41000e90) at syslogd.c:1117
#10 0x000000000041c938 in llExecFunc (pThis=0x68e510, 
    pFunc=0x40af60 <processMsgDoActions>, pParam=0x41000e90)
    at linkedlist.c:391
#11 0x000000000040ab19 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x2aaaac0014c0) at syslogd.c:1160
#12 0x000000000043ae97 in queueConsumerReg (pThis=0x68eab0, pWti=0x6a2730, 
    iCancelStateSave=<value optimized out>) at queue.c:1574
#13 0x0000000000431970 in wtiWorker (pThis=0x6a2730) at wti.c:413
#14 0x00000000004301da in wtpWorker (arg=0x6a2730) at wtp.c:419
#15 0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#16 0x00002b673066b7cd in clone () from /lib/libc.so.6
#17 0x0000000000000000 in ?? ()
(gdb) quit

From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 14:48:55 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 14:48:55 +0200 (CEST)
Subject: [rsyslog] problems with autoconf and configuration examples
Message-ID: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>

Last week, I referred in a very terse way to configure problems; to have 
configure finish its job, I have to remove both PKG_CHECK_MODULES from 
configure.ac:

  ./configure: line 26534: syntax error near unexpected token `RELP,'
  ./configure: line 26534: `      PKG_CHECK_MODULES(RELP, relp >= 0.1.1)'

and, after removing the RELP line group:

  ./configure: line 26560: syntax error near unexpected token `LIBLOGGING,'
  ./configure: line 26560: `      PKG_CHECK_MODULES(LIBLOGGING, liblogging >= 0.7.1)'

As for the configuration examples, I still find references to
$ActionExecOnlyIfPreviousIsSuspended both on-line and in the sample
section of ./doc/rsconf1_actionexeconlywhenpreviousissuspended.html.

If there is no way to keep the previous syntax running and spewing a
deprecation warning, please do correct all the google reachable
pages showing the wrong syntax... and add a note like
"in the past, rsyslogd supported the now removed syntax 
$ActionExecOnlyIfPreviousIsSuspended"

Thank you very much, yours

 	lorenzo


From rgerhards at hq.adiscon.com  Mon Sep 22 14:52:01 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 14:52:01 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
Message-ID: <1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>

Hi all,

On Mon, 2008-09-22 at 14:48 +0200, Lorenzo M. Catucci wrote:
> Last week, I referred in a very terse way to configure problems; to have 
> configure finish its job, I have to remove both PKG_CHECK_MODULES from 
> configure.ac:
> 
>   ./configure: line 26534: syntax error near unexpected token `RELP,'
>   ./configure: line 26534: `      PKG_CHECK_MODULES(RELP, relp >= 0.1.1)'
> 
> and, after removing the RELP line group:
> 
>   ./configure: line 26560: syntax error near unexpected token `LIBLOGGING,'
>   ./configure: line 26560: `      PKG_CHECK_MODULES(LIBLOGGING, liblogging >= 0.7.1)'
> 

I unfortunately have no idea what this problem may be caused by. Can
someone with a better understanding of autotools help out?

> As for the configuration examples, I still find references to
> $ActionExecOnlyIfPreviousIsSuspended both on-line and in the sample
> section of ./doc/rsconf1_actionexeconlywhenpreviousissuspended.html.
> 
> If there is no way to keep the previous syntax running and spewing a
> deprecation warning, please do correct all the google reachable
> pages showing the wrong syntax... and add a note like
> "in the past, rsyslogd supported the now removed syntax 
> $ActionExecOnlyIfPreviousIsSuspended"
> 

Sorry if I am missing the obvious here (I am probably ;)), but I do not
get what exactly you are refering to. Please elaborate a bit.

Thanks,
Rainer

> Thank you very much, yours
> 
>  	lorenzo
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From mbiebl at gmail.com  Mon Sep 22 14:55:00 2008
From: mbiebl at gmail.com (Michael Biebl)
Date: Mon, 22 Sep 2008 14:55:00 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
Message-ID: <aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>

2008/9/22 Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:
> Last week, I referred in a very terse way to configure problems; to have
> configure finish its job, I have to remove both PKG_CHECK_MODULES from
> configure.ac:
>
>  ./configure: line 26534: syntax error near unexpected token `RELP,'
>  ./configure: line 26534: `      PKG_CHECK_MODULES(RELP, relp >= 0.1.1)'
>
> and, after removing the RELP line group:
>
>  ./configure: line 26560: syntax error near unexpected token `LIBLOGGING,'
>  ./configure: line 26560: `      PKG_CHECK_MODULES(LIBLOGGING, liblogging >= 0.7.1)'

Please install the pkg-config package and re-run
autoreconf -vfi


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


From rgerhards at hq.adiscon.com  Mon Sep 22 15:02:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 15:02:14 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1A4@grfint2.intern.adiscon.com>

Me again ;)

I have done some further testing today. I begin to think that the issue
left is only related to HUPing rsyslogd. Can you confirm this? Do
problems happen before the first HUP is sent?

Thanks,
Rainer


From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 16:03:46 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 16:03:46 +0200 (CEST)
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0809221550120.1580@sancho.ccd.uniroma2.it>

On Mon, 22 Sep 2008, Michael Biebl wrote:

MB> 
MB> Please install the pkg-config package and re-run
MB> autoreconf -vfi
MB> 

Did do the trick; still, I'm unsure if the requirement for pkg-config is 
really justified just for two non-mandatory libraries.

Thank you very much, yours

	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 16:18:14 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 16:18:14 +0200 (CEST)
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809221607540.1580@sancho.ccd.uniroma2.it>

RG> 
RG> Sorry if I am missing the obvious here (I am probably ;)), but I do not
RG> get what exactly you are refering to. Please elaborate a bit.
RG> 
RG> 

The misleading documentation is available, both online at
  http://kb.monitorware.com/problem-in-failover-syslogserver-t8465.html
  http://wiki.rsyslog.com/index.php/FailoverSyslogServer 

There is a talk-back item for the wiki page at
  http://wiki.rsyslog.com/index.php/Talk:FailoverSyslogServer

Whats strange is that the same error is repeated at 
./doc/rsconf1_actionexeconlywhenpreviousissuspended.html  

and that the $ActionExecOnlyWhenPreviousIsSuspended is undocumented.


Thank you very much, yours,

	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From rgerhards at hq.adiscon.com  Mon Sep 22 16:32:45 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 16:32:45 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221607540.1580@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809221607540.1580@sancho.ccd.uniroma2.it>
Message-ID: <1222093965.2682.165.camel@rgf9dev.intern.adiscon.com>

Thanks for letting me know. It's fixed now.

Rainer

On Mon, 2008-09-22 at 16:18 +0200, Lorenzo M. Catucci wrote:
> RG> 
> RG> Sorry if I am missing the obvious here (I am probably ;)), but I do not
> RG> get what exactly you are refering to. Please elaborate a bit.
> RG> 
> RG> 
> 
> The misleading documentation is available, both online at
>   http://kb.monitorware.com/problem-in-failover-syslogserver-t8465.html
>   http://wiki.rsyslog.com/index.php/FailoverSyslogServer 
> 
> There is a talk-back item for the wiki page at
>   http://wiki.rsyslog.com/index.php/Talk:FailoverSyslogServer
> 
> Whats strange is that the same error is repeated at 
> ./doc/rsconf1_actionexeconlywhenpreviousissuspended.html  
> 
> and that the $ActionExecOnlyWhenPreviousIsSuspended is undocumented.
> 
> 
> Thank you very much, yours,
> 
> 	lorenzo
> 
> +-------------------------+----------------------------------------------+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
> +-------------------------+----------------------------------------------+
> _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep 22 16:42:51 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 16:42:51 +0200
Subject: [rsyslog] someone with experience in DejaGNU on this list?
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1A7@grfint2.intern.adiscon.com>

Hi,

I am looking for ways to improve the rsyslog test suites. I have written
a handful few via custom programs, but turning them into a full blow (or
at least somewhat sufficiently full blow ;)) test suite is far from
being trivial. I am looking for a suite that can be executed as part of
make distcheck and look at all the important things.

I know that there is DejaGNU out, which promises to ease creating
testsuites, but I have never used it. So before I invest any time in
looking at it, is there some wisdom about it, or another open source
testing tool, available on this list?

If you know something, please comment.

Thanks,
Rainer


From mbiebl at gmail.com  Mon Sep 22 17:00:02 2008
From: mbiebl at gmail.com (Michael Biebl)
Date: Mon, 22 Sep 2008 17:00:02 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221550120.1580@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>
	<alpine.DEB.1.10.0809221550120.1580@sancho.ccd.uniroma2.it>
Message-ID: <aa76cdac0809220800w18aab7fs4d9f7c3db819a303@mail.gmail.com>

2008/9/22 Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:
> On Mon, 22 Sep 2008, Michael Biebl wrote:
>
> MB>
> MB> Please install the pkg-config package and re-run
> MB> autoreconf -vfi
> MB>
>
> Did do the trick; still, I'm unsure if the requirement for pkg-config is
> really justified just for two non-mandatory libraries.
>
> Thank you very much, yours

pkg-config is *so* widely used nowadays, I was actually pretty
surprised you hadn't installed it by default.

Cheers,
Michael


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


From rgerhards at hq.adiscon.com  Mon Sep 22 17:23:41 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 17:23:41 +0200
Subject: [rsyslog] Another helgrind log
In-Reply-To: <alpine.DEB.1.10.0809221653340.2559@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221653340.2559@sancho.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1AE@grfint2.intern.adiscon.com>

Hi all,

just a quick wrap-up. Lorenzo sent me a couple of traces privately (on my request to keep the list free of the big attachments). I have reviewed them and I have to admit I am a bit puzzled by the traces. This just made me post a question on the valgrind mailing list. I hope to get some feedback from there soon.

Other than that, I have run a number of new tests today, during one I detected a problem inside imuxsock, but this one is probably unrelated as it isn't loaded. I will continue testing. Any more feedback is welcome. As soon as I have new news, I'll post.

Rainer

> This time I'm sure no HUP has been delivered to the daemon before
> helgrind
> did terminate it.
> 
> I'm restarting the "free-running" daemon and will wait till a SEGV
> comes
> to it.
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 17:30:18 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 17:30:18 +0200 (CEST)
Subject: [rsyslog] Another gdb backtrace
Message-ID: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>

Now I'm sure no HUP could have been deilivered to the daemon while 
running. This is a backtrace from a standard

$ rsyslogd -c3

run inside a screen session...

Thank you very much, yours

 	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /usr/lib/rsyslog/lmnetstrms.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnetstrms.so
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/lmnsd_ptcp.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnsd_ptcp.so
Core was generated by `rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 27165]
[New process 27167]
[New process 27166]
[New process 27164]
[New process 27163]
#0  0x00002b6f58c7fef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 27163):
#0  0x00002b6f58d16f12 in select () from /lib/libc.so.6
#1  0x000000000040db33 in mainThread () at syslogd.c:2585
#2  0x000000000040ed0c in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:3483
#3  0x00002b6f58c6c1a6 in __libc_start_main () from /lib/libc.so.6
#4  0x0000000000409f79 in _start ()

Thread 4 (process 27164):
#0  0x00002b6f5862efad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#1  0x0000000000431a13 in wtiWorker (pThis=0x685200) at wti.c:403
#2  0x00000000004301da in wtpWorker (arg=0x685200) at wtp.c:419
#3  0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 3 (process 27166):
#0  0x00002b6f58d16f12 in select () from /lib/libc.so.6
#1  0x00002b6f593bc9dd in runInput (pThrd=<value optimized out>)
    at imuxsock.c:278
#2  0x0000000000441eef in thrdStarter (arg=0x6a5b30) at ../threads.c:139
#3  0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 2 (process 27167):
#0  0x00002b6f586317eb in read () from /lib/libpthread.so.0
#1  0x00002b6f595c11bf in klogLogKMsg () at linux.c:449
#2  0x00002b6f595c0554 in runInput (pThrd=0x6a8c60) at imklog.c:214
#3  0x0000000000441eef in thrdStarter (arg=0x6a8c60) at ../threads.c:139
#4  0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#5  0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (process 27165):
#0  0x00002b6f58c7fef5 in raise () from /lib/libc.so.6
#1  0x00002b6f58c81413 in abort () from /lib/libc.so.6
#2  0x0000000000422019 in sigsegvHdlr (signum=6) at debug.c:758
#3  <signal handler called>
#4  0x00002b6f58c7fef5 in raise () from /lib/libc.so.6
#5  0x00002b6f58c81413 in abort () from /lib/libc.so.6
#6  0x00002b6f58c78dc9 in __assert_fail () from /lib/libc.so.6
#7  0x000000000041bad6 in msgDestruct (ppThis=0x68fa28) at msg.c:274
#8  0x0000000000441824 in actionCallAction (pAction=0x68f9b0, pMsg=0x6b1ce0)
    at ../action.c:741
#9  0x000000000040afb7 in processMsgDoActions (pData=0x68f9b0, 
    pParam=0x41000e90) at syslogd.c:1117
#10 0x000000000041c938 in llExecFunc (pThis=0x68e510, 
    pFunc=0x40af60 <processMsgDoActions>, pParam=0x41000e90)
    at linkedlist.c:391
#11 0x000000000040ab19 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x6b1ce0) at syslogd.c:1160
#12 0x000000000043ae97 in queueConsumerReg (pThis=0x68fdb0, pWti=0x6a3a30, 
    iCancelStateSave=<value optimized out>) at queue.c:1574
#13 0x0000000000431970 in wtiWorker (pThis=0x6a3a30) at wti.c:413
#14 0x00000000004301da in wtpWorker (arg=0x6a3a30) at wtp.c:419
#15 0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#16 0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#17 0x0000000000000000 in ?? ()
(gdb) quit

From rgerhards at hq.adiscon.com  Mon Sep 22 17:33:54 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 17:33:54 +0200
Subject: [rsyslog] Another gdb backtrace
In-Reply-To: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1B0@grfint2.intern.adiscon.com>

Just to double-check: does the abort happen

a) immediately
b) relatively soon after start
c) some time after start, probably late

I think it is b). Reason for question: I would eventually like to add some instrumentation, but that makes sense only if we do not need to wade through several GB of debug log...

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Lorenzo M. Catucci
> Sent: Monday, September 22, 2008 5:30 PM
> To: rsyslog-users
> Subject: [rsyslog] Another gdb backtrace
> 
> Now I'm sure no HUP could have been deilivered to the daemon while
> running. This is a backtrace from a standard
> 
> $ rsyslogd -c3
> 
> run inside a screen session...
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 17:52:43 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 17:52:43 +0200 (CEST)
Subject: [rsyslog] Another gdb backtrace
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1B0@grfint2.intern.adiscon.com>
References: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F1B0@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809221738520.2559@sancho.ccd.uniroma2.it>

On Mon, 22 Sep 2008, Rainer Gerhards wrote:

RG> Just to double-check: does the abort happen
RG> 
RG> a) immediately
RG> b) relatively soon after start
RG> c) some time after start, probably late
RG> 
RG> I think it is b). Reason for question: I would eventually like to add 
RG> some instrumentation, but that makes sense only if we do not need to 
RG> wade through several GB of debug log...
RG> 

The free-running doesn't survive more than a couple of hours; I still 
haven't tried a free-running with -dn appended; let me know if you'd 
prefer for me to try starting the daemon now, or if it's better if 
I wait for some more commits.

As for testing, in as much as I understand, to reproduce the problem we 
are going after there would be a need for a load-test harness, and some 
patience, since, in my case, the "writer" server does work without any 
problem, and the crashes do happen on one of my loaded mail gateways, 
which get some thousand messages per hour, and do antispam and antivirus 
work, with sendmail, mailscanner and clamav each spewing a lot of messages 
to filter and dispose of.

See you later, yours

	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From aoz.syn at gmail.com  Tue Sep 23 05:31:29 2008
From: aoz.syn at gmail.com (RB)
Date: Mon, 22 Sep 2008 21:31:29 -0600
Subject: [rsyslog] RPM spec file
Message-ID: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>

I was building a virtual host the other day and noticed only
rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
rather disappointed and immediately whipped up something based on the
2.0.0 specfile.

Attached is a spec file for 3.21.4, but should be usable for most of
the 3.x series.  YMMV, this has not been tested too terribly much.
I'd appreciate a callback if anyone uses it or has a problem - I've
done plenty of packaging, just not for RPM-based distros.


RB

From rgerhards at hq.adiscon.com  Tue Sep 23 08:54:55 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 08:54:55 +0200
Subject: [rsyslog] cisco router config and plain TCP syslog
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>

Hi list,

is there someone on the list successfully using plain TCP syslog
logging? I have one problem case inside the forum where the router does
not properly terminate messages with LF, the required framing:

http://kb.monitorware.com/tcp-syslog-fill-s-up-buffer-and-doesn-t-log-si
ngle-events-t8705.html

I am not an IOS guy, so I would appreciate if someone could drop me the
right configuration for the routers. Actually, I wonder that they do not
seem to do that by default. As far as I remember, this has never been an
issue. I have limited personal experience with PIX, which terminated
messages correct by default.

Any pointer would be appreciated,
Rainer


From rgerhards at hq.adiscon.com  Tue Sep 23 10:31:59 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 10:31:59 +0200
Subject: [rsyslog] FW: [Valgrind-users] helgrind points to race in
	pthread_mutex_lock?
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1B9@grfint2.intern.adiscon.com>

Hi all,

An update on the abort case bug.

Below is one of the responses I got from the valgrind mailing list about
my inquiry. In short, the helgrind log I received seems not to be
absolutely correct and thus is unfortunately of very limited use for
troubleshooting.

There are new versions out and I will ask Lorenzo if it is possible to
run one of those. I'll do that via private mail as I need to forward
some more messages (unfortunately the valgrind mailing list archive
lacks behind several days, so I can not yet refer to the archive...).

Rainer

> ---------- Forwarded message ----------
> From: Julian Seward < >
> Date: Mon, Sep 22, 2008 at 8:54 PM
> Subject: Re: [Valgrind-users] helgrind points to race in
> pthread_mutex_lock?
> To: valgrind-users at lists.sourceforge.net
> Cc: Konstantin Serebryany < >, Rainer
> Gerhards < m>
> 
> 
> 
> On Monday 22 September 2008, Konstantin Serebryany wrote:
> 
> > helgrind is under active development now in two separate branches
> > (HGDEV & YARD).
> > The version in trunk is outdated. Please try YARD first:
> > svn co svn://svn.valgrind.org/valgrind/branches/YARD YARD
> 
> Yes, do try YARD; you might like it more than the 3.3.1 helgrind.
> 
> Nevertheless, the error you show:
> 
> > > ==31831== Possible data race during read of size 4 at 0x6622E8
> > > ==31831==    at 0x50464FE: pthread_mutex_lock
> (pthread_mutex_lock.c:87)
> > > ==31831==    by 0x4C2217B: pthread_mutex_lock
(hg_intercepts.c:400)
> > > ==31831==    by 0x420AFC: dbgGetThrdInfo (debug.c:604)
> > [...]
> 
> should have been suppressed, so you should not see it.  It is due to
an
> internal implementation limitation which is hard to avoid, so in some
> cases we suppress errors which we know cannot be from end-user code.
> 
> I think the relevant suppression in glibc-2.34567-NPTL-helgrind.supp
> is:
> 
>  {
>     helgrind-glibc25-101
>     Helgrind:Race
>     obj:/lib*/libpthread-2.5.*so
>     fun:pthread_*
>  }
> 
> (or corresponding other versions for glibc > 2.5, in the same file)
> 
> One possible reason it did not suppress the error is that you have
> debug information on/for your libpthread, which is an unusual setup
> that
> Helgrind has not been properly tested against.
> 
> But I am not 100% sure about that.
> 
> * if you uninstall the libc debuginfo rpm/deb, does that change
> anything?
> 
> * what glibc version are you using?
> 
> J


From mic at npgx.com.au  Tue Sep 23 11:07:02 2008
From: mic at npgx.com.au (Michael Mansour)
Date: Tue, 23 Sep 2008 20:07:02 +1100
Subject: [rsyslog] RPM spec file
In-Reply-To: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
Message-ID: <20080923090507.M89321@npgx.com.au>

Hi,

> I was building a virtual host the other day and noticed only
> rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> rather disappointed and immediately whipped up something based on the
> 2.0.0 specfile.
> 
> Attached is a spec file for 3.21.4, but should be usable for most of
> the 3.x series.  YMMV, this has not been tested too terribly much.
> I'd appreciate a callback if anyone uses it or has a problem - I've
> done plenty of packaging, just not for RPM-based distros.

I'd love to test this so could you attach the spec or make it available?

I published mine in the rsyslog wiki.

Thanks.

Michael.

> RB
------- End of Original Message -------



From rgerhards at hq.adiscon.com  Tue Sep 23 11:24:05 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 11:24:05 +0200
Subject: [rsyslog] RPM spec file
In-Reply-To: <20080923090507.M89321@npgx.com.au>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<20080923090507.M89321@npgx.com.au>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1BF@grfint2.intern.adiscon.com>

[listadmin speaking]
Ah, I didn't notice. The list processor removes almost all attachments
in order to keep message sizes reasonable and block spread of viruses
should such files be able to go past the first line of defense. Sorry
for the inconvenience this causes...

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Michael Mansour
> Sent: Tuesday, September 23, 2008 11:07 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] RPM spec file
> 
> Hi,
> 
> > I was building a virtual host the other day and noticed only
> > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > rather disappointed and immediately whipped up something based on
the
> > 2.0.0 specfile.
> >
> > Attached is a spec file for 3.21.4, but should be usable for most of
> > the 3.x series.  YMMV, this has not been tested too terribly much.
> > I'd appreciate a callback if anyone uses it or has a problem - I've
> > done plenty of packaging, just not for RPM-based distros.
> 
> I'd love to test this so could you attach the spec or make it
> available?
> 
> I published mine in the rsyslog wiki.
> 
> Thanks.
> 
> Michael.
> 
> > RB
> ------- End of Original Message -------
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From mic at npgx.com.au  Tue Sep 23 12:16:41 2008
From: mic at npgx.com.au (Michael Mansour)
Date: Tue, 23 Sep 2008 21:16:41 +1100
Subject: [rsyslog] [Spam?DateIssue] Re:  RPM spec file
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1BF@grfint2.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<20080923090507.M89321@npgx.com.au>
	<577465F99B41C842AAFBE9ED71E70ABA44F1BF@grfint2.intern.adiscon.com>
Message-ID: <20080923101451.M62228@npgx.com.au>

> [listadmin speaking]
> Ah, I didn't notice. The list processor removes almost all 
> attachments in order to keep message sizes reasonable and block 
> spread of viruses should such files be able to go past the first 
> line of defense. Sorry for the inconvenience this causes...

RB, if you cannot post this to the list could you email it to me directly please?

I'm happy to update the rsyslog wiki page with it so others can download also.

Michael.

> Rainer
> 
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Michael Mansour
> > Sent: Tuesday, September 23, 2008 11:07 AM
> > To: rsyslog-users
> > Subject: Re: [rsyslog] RPM spec file
> > 
> > Hi,
> > 
> > > I was building a virtual host the other day and noticed only
> > > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > > rather disappointed and immediately whipped up something based on
> the
> > > 2.0.0 specfile.
> > >
> > > Attached is a spec file for 3.21.4, but should be usable for most of
> > > the 3.x series.  YMMV, this has not been tested too terribly much.
> > > I'd appreciate a callback if anyone uses it or has a problem - I've
> > > done plenty of packaging, just not for RPM-based distros.
> > 
> > I'd love to test this so could you attach the spec or make it
> > available?
> > 
> > I published mine in the rsyslog wiki.
> > 
> > Thanks.
> > 
> > Michael.
> > 
> > > RB
> > ------- End of Original Message -------
> > 
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
------- End of Original Message -------



From rgerhards at hq.adiscon.com  Tue Sep 23 12:51:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 12:51:14 +0200
Subject: [rsyslog] RPM spec file
In-Reply-To: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>

[oops, forgotten to hit "send" - now a bit outdated, but still useful...]

Hi RB,

I really appreciate the spec file ... but it also creates a bit of a problem for me ;) Let me elaborate: I have stayed away from doing spec files, mostly because I can not ensure they are kept up to date. For that reason, nothing distro-specific is included in the "official source distribution".

If I now include the spec, it may outdate over time plus people come and ask how to work with it, getting us probably down to distro-specific things. I am not sure we want this (or do we want it - I am open to change if there are folks in the community who can commit to support these things [aka "I can not" ;)].

Or is there any other place where such things could be placed (external RPM repositories come to my mind)? I would be more than happy to link to the relevant places.

Again, I really value the contribution, I just do not know how to handle it best.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of RB
> Sent: Tuesday, September 23, 2008 5:31 AM
> To: rsyslog at lists.adiscon.com
> Subject: [rsyslog] RPM spec file
> 
> I was building a virtual host the other day and noticed only
> rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> rather disappointed and immediately whipped up something based on the
> 2.0.0 specfile.
> 
> Attached is a spec file for 3.21.4, but should be usable for most of
> the 3.x series.  YMMV, this has not been tested too terribly much.
> I'd appreciate a callback if anyone uses it or has a problem - I've
> done plenty of packaging, just not for RPM-based distros.
> 
> 
> RB

From mic at npgx.com.au  Tue Sep 23 13:16:00 2008
From: mic at npgx.com.au (Michael Mansour)
Date: Tue, 23 Sep 2008 22:16:00 +1100
Subject: [rsyslog] [Spam?DateIssue] Re:  RPM spec file
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
Message-ID: <20080923110101.M79951@npgx.com.au>

Hi Rainer,

> [oops, forgotten to hit "send" - now a bit outdated, but still useful...]
> 
> Hi RB,
> 
> I really appreciate the spec file ... but it also creates a bit of a 
> problem for me ;) Let me elaborate: I have stayed away from doing 
> spec files, mostly because I can not ensure they are kept up to 
> date. For that reason, nothing distro-specific is included in the 
> "official source distribution".
> 
> If I now include the spec, it may outdate over time plus people come 
> and ask how to work with it, getting us probably down to distro-
> specific things. I am not sure we want this (or do we want it - I am 
> open to change if there are folks in the community who can commit to 
> support these things [aka "I can not" ;)].
> 
> Or is there any other place where such things could be placed 
> (external RPM repositories come to my mind)? I would be more than 
> happy to link to the relevant places.
> 
> Again, I really value the contribution, I just do not know how to 
> handle it best.

My first introduction to rsyslog was via the Dries repository (now part of
RPMforge):

http://dries.ulyssis.org/rpm/packages/rsyslog/info.html

RPMforge have thousands of packages that are maintained for Red Hat based servers.

The problem is, I've asked both Dag and Dries for updated rsyslog versions for
months and they've never replied. I don't know why and they usually reply, but
sometimes they just don't. 

This is why I build my own RPM's on my (and clients) server and why I made my
spec files available on the rsyslog wiki here:

http://wiki.rsyslog.com/index.php/Here_comes_the_first_story

I also provided them for download on my ftp server.

I have since made spec files for 3.18.0-1 but haven't updated since then,
primarily because of lack of time, and haven't updated the wiki with those
updated specs. However I am happy to do this if BR can give me his one, I'll
see if there's anything that's changed first thing.

The other to note, I rarely install anything from source into production
environments. I try to always leave things packaged or I make the specs and
package them myself. 

rpm/deb/etc are just easier to manage, query, update, remove, verify, etc than
from source.

You're not of the minority when packaging for distributions, many developers
don't do it but at the same time, many developers also do. I know one
developer who uses another software package to take his source tarball and
create packages from it for all distro's (deb's, rpm's, tarp's, etc).

But I understand this isn't an argument of whether you should have packages or
not, after all Red Hat will eventually have rsyslog in RPM (but not for
updated versions from you, only what they release and backport fixes for).

So this really comes down to you not being able to so someone/some people just
have to stand up and take responsibility for packaging it. The user/admin
community definately wants it, a web search for the terms "rsyslog repo" or
"rsyslog rpm" will quickly show you this.

Regards,

Michael.

> Rainer
> 
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of RB
> > Sent: Tuesday, September 23, 2008 5:31 AM
> > To: rsyslog at lists.adiscon.com
> > Subject: [rsyslog] RPM spec file
> > 
> > I was building a virtual host the other day and noticed only
> > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > rather disappointed and immediately whipped up something based on the
> > 2.0.0 specfile.
> > 
> > Attached is a spec file for 3.21.4, but should be usable for most of
> > the 3.x series.  YMMV, this has not been tested too terribly much.
> > I'd appreciate a callback if anyone uses it or has a problem - I've
> > done plenty of packaging, just not for RPM-based distros.
> > 
> > 
> > RB
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
------- End of Original Message -------



From aoz.syn at gmail.com  Tue Sep 23 14:11:38 2008
From: aoz.syn at gmail.com (RB)
Date: Tue, 23 Sep 2008 06:11:38 -0600
Subject: [rsyslog] RPM spec file
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
Message-ID: <4255c2570809230511n3453e09ao8caddc895d8cf925@mail.gmail.com>

> I really appreciate the spec file ... but it also creates a bit of a problem for me ;) Let me elaborate: I have stayed away from doing spec files, mostly because I can not ensure they are kept up to date. For that reason, nothing distro-specific is included in the "official source distribution".

Understood; my posting was more for posterity than expecting you to
include it in your distribution.  People looking for a package can
find it now and do with it as they please.  Well, they could if
attachments were allowed through...  :)  My email to Michael should
help that.

> If I now include the spec, it may outdate over time plus people come and ask how to work with it, getting us probably down to distro-specific things. I am not sure we want this (or do we want it - I am open to change if there are folks in the community who can commit to support these things [aka "I can not" ;)].

As a small-time packager, I have to thank you for trying to remain
distro-agnostic.  Few things are more frustrating than trying to
unravel some developer's flavor-specific compile+install+kitchen_sink
script just to get a piece of software packaged for mine.  Much thanks
for staying with the standard autotools approach and letting the
distros sort out how they want to install your software.


RB


From rgerhards at hq.adiscon.com  Tue Sep 23 14:39:03 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 14:39:03 +0200
Subject: [rsyslog] [Spam?DateIssue] Re:  RPM spec file
In-Reply-To: <20080923110101.M79951@npgx.com.au>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<20080923110101.M79951@npgx.com.au>
Message-ID: <1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>

Hi Michael,

great post. Let us see where we come from here...

I know very well that people like to install from packages - actually, I
am one of them ;) So while I try do keep distro-agnostic (thanks RB for
the good words ;)), I would love to see rsyslog packages for all major
distros and and of course for all versions of rsyslog.

Unfortunately, both my knowledge and time is limited. Knowledge can be
expanded, but that takes time, so we are probably down to the "time
limit" problem - which is hard to overcome. I am not justifying me (why
should I?) nor bashing someone (again, why should I?;)) I am just
stating plain, unfortunate facts.

So I need to do a compromise. That currently is that I stay away from
distro-specific things, even in areas where I could join without making
rsyslog distro-specific. Thankfully, people like you, RB, Michael Biebl,
Infofarmer and some more whom I regrettably have not mentioned now join
in and help create great distro-specific things.

But ... sometimes these things are hard to find. The wiki was the first
approach to permit user-created context in an easy to spot and easy to
edit place. The wiki gets around 100 visitors each day and while this is
obviously not a big number, it is one that is constantly growing. So I
think the wiki was a good thing to have (which is also proven by the
fact that we attracted a number of articles).

The mailing list and forum are also good examples. I often do not need
to reply because someone of you did a much better job offering a
solution than I could have done. Excellent.

What is missing is a place to provide things like the rpm package RB
offered. Specific files and such. A quick solution could be that I
collect such material and place it, without any guarantee and whatsoever
support from me, onto the rsyslog download server and offer that
directory as a free resource to the community. That would at least
ensure that there is a single spot where things can be found by anyone
who searches.

Would this make sense? Any more ideas?

Thanks,
Rainer

On Tue, 2008-09-23 at 22:16 +1100, Michael Mansour wrote:
> Hi Rainer,
> 
> > [oops, forgotten to hit "send" - now a bit outdated, but still useful...]
> > 
> > Hi RB,
> > 
> > I really appreciate the spec file ... but it also creates a bit of a 
> > problem for me ;) Let me elaborate: I have stayed away from doing 
> > spec files, mostly because I can not ensure they are kept up to 
> > date. For that reason, nothing distro-specific is included in the 
> > "official source distribution".
> > 
> > If I now include the spec, it may outdate over time plus people come 
> > and ask how to work with it, getting us probably down to distro-
> > specific things. I am not sure we want this (or do we want it - I am 
> > open to change if there are folks in the community who can commit to 
> > support these things [aka "I can not" ;)].
> > 
> > Or is there any other place where such things could be placed 
> > (external RPM repositories come to my mind)? I would be more than 
> > happy to link to the relevant places.
> > 
> > Again, I really value the contribution, I just do not know how to 
> > handle it best.
> 
> My first introduction to rsyslog was via the Dries repository (now part of
> RPMforge):
> 
> http://dries.ulyssis.org/rpm/packages/rsyslog/info.html
> 
> RPMforge have thousands of packages that are maintained for Red Hat based servers.
> 
> The problem is, I've asked both Dag and Dries for updated rsyslog versions for
> months and they've never replied. I don't know why and they usually reply, but
> sometimes they just don't. 
> 
> This is why I build my own RPM's on my (and clients) server and why I made my
> spec files available on the rsyslog wiki here:
> 
> http://wiki.rsyslog.com/index.php/Here_comes_the_first_story
> 
> I also provided them for download on my ftp server.
> 
> I have since made spec files for 3.18.0-1 but haven't updated since then,
> primarily because of lack of time, and haven't updated the wiki with those
> updated specs. However I am happy to do this if BR can give me his one, I'll
> see if there's anything that's changed first thing.
> 
> The other to note, I rarely install anything from source into production
> environments. I try to always leave things packaged or I make the specs and
> package them myself. 
> 
> rpm/deb/etc are just easier to manage, query, update, remove, verify, etc than
> from source.
> 
> You're not of the minority when packaging for distributions, many developers
> don't do it but at the same time, many developers also do. I know one
> developer who uses another software package to take his source tarball and
> create packages from it for all distro's (deb's, rpm's, tarp's, etc).
> 
> But I understand this isn't an argument of whether you should have packages or
> not, after all Red Hat will eventually have rsyslog in RPM (but not for
> updated versions from you, only what they release and backport fixes for).
> 
> So this really comes down to you not being able to so someone/some people just
> have to stand up and take responsibility for packaging it. The user/admin
> community definately wants it, a web search for the terms "rsyslog repo" or
> "rsyslog rpm" will quickly show you this.
> 
> Regards,
> 
> Michael.
> 
> > Rainer
> > 
> > > -----Original Message-----
> > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > > bounces at lists.adiscon.com] On Behalf Of RB
> > > Sent: Tuesday, September 23, 2008 5:31 AM
> > > To: rsyslog at lists.adiscon.com
> > > Subject: [rsyslog] RPM spec file
> > > 
> > > I was building a virtual host the other day and noticed only
> > > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > > rather disappointed and immediately whipped up something based on the
> > > 2.0.0 specfile.
> > > 
> > > Attached is a spec file for 3.21.4, but should be usable for most of
> > > the 3.x series.  YMMV, this has not been tested too terribly much.
> > > I'd appreciate a callback if anyone uses it or has a problem - I've
> > > done plenty of packaging, just not for RPM-based distros.
> > > 
> > > 
> > > RB
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> ------- End of Original Message -------
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Tue Sep 23 14:44:37 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 14:44:37 +0200
Subject: [rsyslog] abort case
In-Reply-To: <dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com>
References: <dc67eef70809220810s1815ff2evce41b096484eb644@mail.gmail.com>
	<59e975c10809221126o37d8919w674f13aee5acc16f@mail.gmail.com>
	<dc67eef70809230133v696f6145r94044ccb30c9cbdc@mail.gmail.com>
	<alpine.DEB.1.10.0809231355450.18598@sancho.ccd.uniroma2.it>
	<dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com>
Message-ID: <1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>

Lorenzo,

I have done a change to the message handler, it is now using an atomic
memory access operation where it previously did not. I have just pushed
that change as part of the helgrind branch.

I would appreciate if you could give it a try and send me (via private
mail) a helgrind log. 

I don't think that this change is sufficient to resolve the issue. But I
would like to take a granular approach so that I can be sure to find the
real root cause.

Thanks,
Rainer

On Tue, 2008-09-23 at 14:04 +0200, Rainer Gerhards wrote:
> ---------- Forwarded message ----------
> From: Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>
> Date: Tue, Sep 23, 2008 at 2:00 PM
> Subject: Re: Fwd: [Valgrind-users] helgrind points to race in
> pthread_mutex_lock?
> To: Rainer Gerhards <rgerhards at gmail.com>
> 
> RG> Lorenzo,
> RG>
> RG> any chance you could do what is described below? (I guess "no", but I
> RG> thought I ask ;)).
> RG>
> 
> It's running! I didn't recompile, since I didn't find anything new within
> the helgrind branch.
> 
> I'm enclosing the very first "race" message, let me know if this does seem
> better.
> 
> Thank you, and keep on course. Yours,
> 
>        lorenzo




From lorenzo at sancho.ccd.uniroma2.it  Tue Sep 23 15:08:34 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Tue, 23 Sep 2008 15:08:34 +0200 (CEST)
Subject: [rsyslog] abort case
In-Reply-To: <1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>
References: <dc67eef70809220810s1815ff2evce41b096484eb644@mail.gmail.com>
	<59e975c10809221126o37d8919w674f13aee5acc16f@mail.gmail.com>
	<dc67eef70809230133v696f6145r94044ccb30c9cbdc@mail.gmail.com>
	<alpine.DEB.1.10.0809231355450.18598@sancho.ccd.uniroma2.it>
	<dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com>
	<1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809231454200.18598@sancho.ccd.uniroma2.it>

On Tue, 23 Sep 2008, Rainer Gerhards wrote:

RG> Lorenzo,
RG> 
RG> I have done a change to the message handler, it is now using an atomic
RG> memory access operation where it previously did not. I have just pushed
RG> that change as part of the helgrind branch.
RG> 

Recompiled/reinstalled/restarted. make did recompile msg.c, I don't know 
why rsyslogd didn't get relinked, but I forced relink by removing rsyslogd 
from tools. 

This time, the server crashed even though it was being helground...

Find enclosed the full debug log.

Yours,

	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From rgerhards at hq.adiscon.com  Tue Sep 23 15:18:18 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 15:18:18 +0200
Subject: [rsyslog] RPM spec file
In-Reply-To: <4255c2570809230511n3453e09ao8caddc895d8cf925@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<4255c2570809230511n3453e09ao8caddc895d8cf925@mail.gmail.com>
Message-ID: <1222175898.2682.190.camel@rgf9dev.intern.adiscon.com>

> script just to get a piece of software packaged for mine.  Much thanks
> for staying with the standard autotools approach and letting the
> distros sort out how they want to install your software.

Praise should go to Peter Vrabec and Michael Biebl, which convinced me
of autotools and also greatly helped me setting things up in a useful
way ;)

Rainer



From aoz.syn at gmail.com  Tue Sep 23 15:53:42 2008
From: aoz.syn at gmail.com (RB)
Date: Tue, 23 Sep 2008 07:53:42 -0600
Subject: [rsyslog] [Spam?DateIssue] Re: RPM spec file
In-Reply-To: <1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<20080923110101.M79951@npgx.com.au>
	<1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>
Message-ID: <4255c2570809230653x3ec19b68mad9fea2da8ceb5f6@mail.gmail.com>

> What is missing is a place to provide things like the rpm package RB
> offered. Specific files and such. A quick solution could be that I
> collect such material and place it, without any guarantee and whatsoever
> support from me, onto the rsyslog download server and offer that
> directory as a free resource to the community. That would at least
> ensure that there is a single spot where things can be found by anyone
> who searches.

Sounds like you need a contrib/ directory, either on your download
server or included in the releases (or both - releases could include a
snapshot).  Linking them from explanatory pages in the wiki will only
serve to help search ranks and generally make everyone happy.  They
should come with (as you said) a disclaimer that best-effort support
may be had on the lists/forums, but that they are unofficial and
therefore not warranted or supported directly by Adiscon.

An alternative would be to allow specific users to upload attachments
to the wiki and link them from a semi-protected page; not as efficient
or as easy to moderate/aggregate, but it would certainly be more
instantaneous.  The 'maintainer' of the given file should additionally
link to instructions on using the package.

Once a sane package is created, most packaging systems make scripted
updates rather easy - use sed to update version numbers/checksums, and
it's good to go.  Gentoo's so easy, all you have to do is re-name the
package file.  Only when major functionality changes (added binaries,
configuration options, etc.) should one have to non-trivially touch
the package.  On that note, the spec file I provided only covers
limited rsyslog functionality - GSSAPI, rfc3195, RELP, and the
debugging tools were all left off simply because I didn't have the
time to build/package their prerequisites.

One last bit: coming from the Gentoo mentality, I'm less interested in
binary packages and far more in the meta-files used to generate those.
 Others may differ, but that may help the bitrot concern.


From aoz.syn at gmail.com  Tue Sep 23 17:13:59 2008
From: aoz.syn at gmail.com (RB)
Date: Tue, 23 Sep 2008 09:13:59 -0600
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
Message-ID: <4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>

> http://kb.monitorware.com/tcp-syslog-fill-s-up-buffer-and-doesn-t-log-single-events-t8705.html

It would seem they're using some version of IOS 12.3 or 12.4; the
'transport X' predicate was introduced some time in the prior but not
documented until the latter.  It would be good to know precisely what
version they are running for reference anyway.

For all I can tell (not having set up a test env myself), it would
seem that just because one indicates TCP as the transport, the
underlying engine doesn't change its semantics and remains at the
UDP-esque 'one packet per message'.  For that matter, I see references
specifically to RFC3164 as opposed to 3195.  Leave it to Cisco...

> I am not an IOS guy, so I would appreciate if someone could drop me the
> right configuration for the routers. Actually, I wonder that they do not
> seem to do that by default. As far as I remember, this has never been an
> issue. I have limited personal experience with PIX, which terminated
> messages correct by default.
:)  My primary experience is with PIX as well.  Looks like the two
primary options are to use 'transport beep' [1] (Cisco's reference to
RFC3195) or to use an ESM filter [2] to add newlines.

[1] http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a00807883c3.html
[2] http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gt_esm.html


From david at lang.hm  Tue Sep 23 17:43:55 2008
From: david at lang.hm (david at lang.hm)
Date: Tue, 23 Sep 2008 08:43:55 -0700 (PDT)
Subject: [rsyslog] [Spam?DateIssue] Re: RPM spec file
In-Reply-To: <4255c2570809230653x3ec19b68mad9fea2da8ceb5f6@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<20080923110101.M79951@npgx.com.au>
	<1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>
	<4255c2570809230653x3ec19b68mad9fea2da8ceb5f6@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0809230840140.31560@asgard.lang.hm>

On Tue, 23 Sep 2008, RB wrote:

>> What is missing is a place to provide things like the rpm package RB
>> offered. Specific files and such. A quick solution could be that I
>> collect such material and place it, without any guarantee and whatsoever
>> support from me, onto the rsyslog download server and offer that
>> directory as a free resource to the community. That would at least
>> ensure that there is a single spot where things can be found by anyone
>> who searches.
>
> Sounds like you need a contrib/ directory, either on your download
> server or included in the releases (or both - releases could include a
> snapshot).  Linking them from explanatory pages in the wiki will only
> serve to help search ranks and generally make everyone happy.  They
> should come with (as you said) a disclaimer that best-effort support
> may be had on the lists/forums, but that they are unofficial and
> therefore not warranted or supported directly by Adiscon.
>
> An alternative would be to allow specific users to upload attachments
> to the wiki and link them from a semi-protected page; not as efficient
> or as easy to moderate/aggregate, but it would certainly be more
> instantaneous.  The 'maintainer' of the given file should additionally
> link to instructions on using the package.
>
> Once a sane package is created, most packaging systems make scripted
> updates rather easy - use sed to update version numbers/checksums, and
> it's good to go.  Gentoo's so easy, all you have to do is re-name the
> package file.  Only when major functionality changes (added binaries,
> configuration options, etc.) should one have to non-trivially touch
> the package.  On that note, the spec file I provided only covers
> limited rsyslog functionality - GSSAPI, rfc3195, RELP, and the
> debugging tools were all left off simply because I didn't have the
> time to build/package their prerequisites.
>
> One last bit: coming from the Gentoo mentality, I'm less interested in
> binary packages and far more in the meta-files used to generate those.
> Others may differ, but that may help the bitrot concern.

I've been using checkinstall to make the packages as I compile them.

it would be handy if rsyslog could include the spec files that it would 
use to create the appropriate packages, but I can understand the 
reluctance to go there.

but if the dependancies are well documented, then creating the appropriate 
file would be pretty easy.

David Lang


From patrick.shen at net-m.de  Wed Sep 24 10:56:30 2008
From: patrick.shen at net-m.de (Patrick Shen)
Date: Wed, 24 Sep 2008 16:56:30 +0800
Subject: [rsyslog] A question about message size
Message-ID: <48DA00BE.2030705@net-m.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Rainer,

Now I am running latest V3 stable (3.18.4) on my company production
machine. We couldn't upgrade to >=3.21.4 to get the benefit of dynamic
setting MESSAGE size due to company policy.

But we need 4K for message size not 2K by default. So I changed MAXLINE
definition in syslogd.h from 2048 to 4096.

Is it correct? And do we have any other solutions with 3.18.4 ?

Many thanks,

- --
Patrick Shen
Operations Engineer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjaAL4ACgkQkHhYtFevC+PhBgCfVnsQU4Zcn9rVgWZIpS5WXqWz
YxMAn3GWCZ2bPvJFthSCb2HECCfIkF7Y
=Rza/
-----END PGP SIGNATURE-----


From rgerhards at hq.adiscon.com  Wed Sep 24 12:39:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 24 Sep 2008 12:39:14 +0200
Subject: [rsyslog] A question about message size
In-Reply-To: <48DA00BE.2030705@net-m.de>
References: <48DA00BE.2030705@net-m.de>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1D4@grfint2.intern.adiscon.com>

Yes, that's right and that's the only solution for v3-stable.

I haven't merged that change into the stable branch because, among all
of the changes done, this one is among those with the greatest potential
to break things. You do not want to have that in v3-stable (just to note
that backporting it is definitely not a good idea ;)).

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Patrick Shen
> Sent: Wednesday, September 24, 2008 10:57 AM
> To: rsyslog-users
> Subject: [rsyslog] A question about message size
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Rainer,
> 
> Now I am running latest V3 stable (3.18.4) on my company production
> machine. We couldn't upgrade to >=3.21.4 to get the benefit of dynamic
> setting MESSAGE size due to company policy.
> 
> But we need 4K for message size not 2K by default. So I changed
MAXLINE
> definition in syslogd.h from 2048 to 4096.
> 
> Is it correct? And do we have any other solutions with 3.18.4 ?
> 
> Many thanks,
> 
> - --
> Patrick Shen
> Operations Engineer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkjaAL4ACgkQkHhYtFevC+PhBgCfVnsQU4Zcn9rVgWZIpS5WXqWz
> YxMAn3GWCZ2bPvJFthSCb2HECCfIkF7Y
> =Rza/
> -----END PGP SIGNATURE-----
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From patrick.shen at net-m.de  Wed Sep 24 13:48:04 2008
From: patrick.shen at net-m.de (Patrick Shen)
Date: Wed, 24 Sep 2008 19:48:04 +0800
Subject: [rsyslog] A question about message size
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1D4@grfint2.intern.adiscon.com>
References: <48DA00BE.2030705@net-m.de>
	<577465F99B41C842AAFBE9ED71E70ABA44F1D4@grfint2.intern.adiscon.com>
Message-ID: <48DA28F4.2070204@net-m.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for your explanation.

Best regards,
Patrick

Rainer Gerhards wrote:
> Yes, that's right and that's the only solution for v3-stable.
> 
> I haven't merged that change into the stable branch because, among all
> of the changes done, this one is among those with the greatest potential
> to break things. You do not want to have that in v3-stable (just to note
> that backporting it is definitely not a good idea ;)).
> 
> Rainer
> 
>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of Patrick Shen
>> Sent: Wednesday, September 24, 2008 10:57 AM
>> To: rsyslog-users
>> Subject: [rsyslog] A question about message size
>>
> Hi Rainer,
> 
> Now I am running latest V3 stable (3.18.4) on my company production
> machine. We couldn't upgrade to >=3.21.4 to get the benefit of dynamic
> setting MESSAGE size due to company policy.
> 
> But we need 4K for message size not 2K by default. So I changed
>> MAXLINE
> definition in syslogd.h from 2048 to 4096.
> 
> Is it correct? And do we have any other solutions with 3.18.4 ?
> 
> Many thanks,
> 
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

- --
Patrick Shen
Operations Engineer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjaKPQACgkQkHhYtFevC+NsSACgiur1TmRgsFmE7qs8ff1c/xGF
ifUAn2miAH8ILxk6KUiT2geoVRYXee/O
=3pVu
-----END PGP SIGNATURE-----


From rgerhards at hq.adiscon.com  Thu Sep 25 16:04:01 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 25 Sep 2008 16:04:01 +0200
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
	<4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>

> > http://kb.monitorware.com/tcp-syslog-fill-s-up-buffer-and-doesn-t-
> log-single-events-t8705.html
> 
> It would seem they're using some version of IOS 12.3 or 12.4; the
> 'transport X' predicate was introduced some time in the prior but not
> documented until the latter.  It would be good to know precisely what
> version they are running for reference anyway.
> 
> For all I can tell (not having set up a test env myself), it would
> seem that just because one indicates TCP as the transport, the
> underlying engine doesn't change its semantics and remains at the
> UDP-esque 'one packet per message'.  For that matter, I see references
> specifically to RFC3164 as opposed to 3195.  Leave it to Cisco...

Quick follow-up: I am working with them, hope to get some results out of
this conversation. As this bug seems to actually exist in IOS and lots
of IOS are rolled out, I'll try to do a work-around, at least if I can
convince myself that it will work in at least many cases ;)

Rainer


From aoz.syn at gmail.com  Thu Sep 25 17:08:44 2008
From: aoz.syn at gmail.com (RB)
Date: Thu, 25 Sep 2008 09:08:44 -0600
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
	<4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>
Message-ID: <4255c2570809250808g2834d6f4k403af11295cdca2e@mail.gmail.com>

> Quick follow-up: I am working with them, hope to get some results out of
> this conversation. As this bug seems to actually exist in IOS and lots
> of IOS are rolled out, I'll try to do a work-around, at least if I can
> convince myself that it will work in at least many cases ;)

I've been watching the thread.  Seems like some people have adopted a
workaround based on the signature at the beginning of the Cisco log
entries, but that's pretty obviously subpar - their switching gear
doesn't seem to add those, at least on the 12.1 2950 I test against.
Sorry I don't have much else to offer here - like the OP noted, all my
logging has been on the LAN, and trusted segments to boot.  I've seen
setups where remote routers logged over IPSEC or GRE tunnels, but
those were still using UDP.


RB


From rgerhards at hq.adiscon.com  Thu Sep 25 17:11:24 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 25 Sep 2008 17:11:24 +0200
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <4255c2570809250808g2834d6f4k403af11295cdca2e@mail.gmail.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com><4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>
	<4255c2570809250808g2834d6f4k403af11295cdca2e@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F206@grfint2.intern.adiscon.com>

> > Quick follow-up: I am working with them, hope to get some results
out
> of
> > this conversation. As this bug seems to actually exist in IOS and
> lots
> > of IOS are rolled out, I'll try to do a work-around, at least if I
> can
> > convince myself that it will work in at least many cases ;)
> 
> I've been watching the thread.  Seems like some people have adopted a
> workaround based on the signature at the beginning of the Cisco log
> entries, but that's pretty obviously subpar - their switching gear
> doesn't seem to add those, at least on the 12.1 2950 I test against.
> Sorry I don't have much else to offer here 

You offered a lot. You post helped track down the problem source and
made make go the right direction :) I think the best thing now is to
wait for what the Cisco folks come up with. And if that takes too long,
I'll add an $WorkAroundCrazyTCPBug directive and see if it works out ;)

> - like the OP noted, all my
> logging has been on the LAN, and trusted segments to boot.  I've seen
> setups where remote routers logged over IPSEC or GRE tunnels, but
> those were still using UDP.

Rainer


From rgerhards at hq.adiscon.com  Fri Sep 26 17:12:09 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 26 Sep 2008 17:12:09 +0200
Subject: [rsyslog] abort case
In-Reply-To: <alpine.DEB.1.10.0809231454200.18598@sancho.ccd.uniroma2.it>
References: <dc67eef70809220810s1815ff2evce41b096484eb644@mail.gmail.com><59e975c10809221126o37d8919w674f13aee5acc16f@mail.gmail.com><dc67eef70809230133v696f6145r94044ccb30c9cbdc@mail.gmail.com><alpine.DEB.1.10.0809231355450.18598@sancho.ccd.uniroma2.it><dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com><1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809231454200.18598@sancho.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F21A@grfint2.intern.adiscon.com>

Lorenzo,

I have created a new version with one slight change, to be found in the helgrind branch.

There is also a new valgrind tool called drd inside the valgrind development tree. I think you already downloaded that tree. If so, could you please replace

Valgrind --tool=helgrind .. rsyslogd ...

with

Valgrind --tool=drd .. rsyslogd ...

Drd does an even better job than helgrind. I also changed the source to remove some debug-system related warning, which otherwise would clutter up the error message. But unfortunately, in my lab I did not find any more problems, except for the small change I mentioned. But that one affects program termination (and in a very subtle way), so it should not change anything for you. I'd still be interested in a new run, including debug info, from you.

Thanks,
Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Lorenzo M. Catucci
> Sent: Tuesday, September 23, 2008 3:09 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] abort case
> 
> On Tue, 23 Sep 2008, Rainer Gerhards wrote:
> 
> RG> Lorenzo,
> RG>
> RG> I have done a change to the message handler, it is now using an
> atomic
> RG> memory access operation where it previously did not. I have just
> pushed
> RG> that change as part of the helgrind branch.
> RG>
> 
> Recompiled/reinstalled/restarted. make did recompile msg.c, I don't
> know
> why rsyslogd didn't get relinked, but I forced relink by removing
> rsyslogd
> from tools.
> 
> This time, the server crashed even though it was being helground...
> 
> Find enclosed the full debug log.
> 
> Yours,
> 
> 	lorenzo
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From friedl at hq.adiscon.com  Tue Sep 30 12:02:14 2008
From: friedl at hq.adiscon.com (Florian Riedl)
Date: Tue, 30 Sep 2008 12:02:14 +0200
Subject: [rsyslog] rsyslog 3.21.5 released
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>

Hi all,

rsyslog 3.21.5, a member of the development branch, has just been
released. It contains new features, improvements and bug fixes. Most
importantly, a bug has been fixed that can cause a segfault on HUP when
using the UDP input. Also, performance has been greatly enhanced
(special thanks to David Lang for his help). Finally, multi-threaded
handling has been improved. This is a recommended update for all
development branch users.

Changelog:

http://www.rsyslog.com/Article279.phtml

Download:

http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-132.phtml

As always, feedback is appreciated.

Florian Riedl
--
Support
=======

Improving rsyslog is costly, but you can help!  We are looking for
organizations that find rsyslog useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for rsyslog are available, and they help
finance continued maintenance.  Adiscon GmbH, a privately held German
company, is currently funding rsyslog development. We are always looking
for interesting development projects. For details on how to help, please
see http://www.rsyslog.com/doc-how2help.html .




From luigi.perroti at googlemail.com  Tue Sep 30 14:20:11 2008
From: luigi.perroti at googlemail.com (Luigi Perroti)
Date: Tue, 30 Sep 2008 14:20:11 +0200
Subject: [rsyslog] rsyslog 3.21.5 released
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>
Message-ID: <d67280e00809300520s625834am9ecbe4ea3d347a42@mail.gmail.com>

On 9/30/08, Florian Riedl <friedl at hq.adiscon.com> wrote:
> Hi all,
>
> rsyslog 3.21.5, a member of the development branch, has just been
> released.

Hi,

I'm eager to switch from the stable to the development branch but
first I'd like to know if the imfile segmentation fix that was shipped
with 3.18.3 has been merged into the development branch.

The changelogs for 3.21.3 - 3.21.5 don't mention this issue so
probably I'll have to wait but I thought I'd ask just in case.

Thanks!

Regards,
Luigi


From rgerhards at hq.adiscon.com  Tue Sep 30 14:28:20 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 30 Sep 2008 14:28:20 +0200
Subject: [rsyslog] rsyslog 3.21.5 released
In-Reply-To: <d67280e00809300520s625834am9ecbe4ea3d347a42@mail.gmail.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>
	<d67280e00809300520s625834am9ecbe4ea3d347a42@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F23F@grfint2.intern.adiscon.com>

Hi Luigi,

yes, this has been merged. All fixes have been merged, except for some
doc things. I think this is the one in question:

http://git.adiscon.com/?p=rsyslog.git;a=commit;h=7b456ce548030ff362d3a2b
e04b1e5c2c89e0dcb

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Luigi Perroti
> Sent: Tuesday, September 30, 2008 2:20 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog 3.21.5 released
> 
> On 9/30/08, Florian Riedl <friedl at hq.adiscon.com> wrote:
> > Hi all,
> >
> > rsyslog 3.21.5, a member of the development branch, has just been
> > released.
> 
> Hi,
> 
> I'm eager to switch from the stable to the development branch but
> first I'd like to know if the imfile segmentation fix that was shipped
> with 3.18.3 has been merged into the development branch.
> 
> The changelogs for 3.21.3 - 3.21.5 don't mention this issue so
> probably I'll have to wait but I thought I'd ask just in case.
> 
> Thanks!
> 
> Regards,
> Luigi
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com


From luigi.perroti at googlemail.com  Tue Sep 30 19:29:56 2008
From: luigi.perroti at googlemail.com (Luigi Perroti)
Date: Tue, 30 Sep 2008 19:29:56 +0200
Subject: [rsyslog] MainMsgQueueWorkerThreads and devel branch
Message-ID: <d67280e00809301029q4b96d88sdf29d0d26f357a79@mail.gmail.com>

Hi,

I've upgraded from 3.18.3-Test6 to 3.21.5 and I noticed that I can
only use a value of 1 for $MainMsgQueueWorkerThreads. I had it set to
8 on the stable branch.

If I set its value to something greater than 1 rsyslog writes the pid
file but doesn't start.

1 thread should be enough for my needs and I can stick with it.
Still I'd like to know if this behaviour is known to the developers,
maybe it is since the documentation recommends a value of 1.

Regards,
Luigi


From rgerhards at hq.adiscon.com  Mon Sep  1 15:32:27 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 1 Sep 2008 15:32:27 +0200
Subject: [rsyslog] Problems migrating from syslog-ng
In-Reply-To: <c24352ca0808220621s5419322fi3f0820e1dea79da9@mail.gmail.com>
References: <c24352ca0808211033u3e1a810dsb5ad7f11c594bfe6@mail.gmail.com><ac9ded160808211046h4eb276e2t9653c5e7169008f5@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA0108D9@grfint2.intern.adiscon.com><c24352ca0808211344n221aff68ib6e143c287680b48@mail.gmail.com><ac9ded160808211400w2da90ce3k17a307a214aa939f@mail.gmail.com>
	<c24352ca0808220621s5419322fi3f0820e1dea79da9@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F05E@grfint2.intern.adiscon.com>

Being back...

(inline)

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Jeff Schroeder
> Sent: Friday, August 22, 2008 3:21 PM
> To: (private) HKS
> Cc: rsyslog-users
> Subject: Re: [rsyslog] Problems migrating from syslog-ng
> 
> On Thu, Aug 21, 2008 at 2:00 PM, (private) HKS <hks.private at gmail.com>
> wrote:
> > On Thu, Aug 21, 2008 at 4:44 PM, Jeff Schroeder
> <jeffschroed at gmail.com> wrote:
> >> On Thu, Aug 21, 2008 at 10:53 AM, Rainer Gerhards
> >> <rgerhards at hq.adiscon.com> wrote:
> >>> I have only been able to have a brief look, but it looks like the
> message is incorrectly formatted. rsyslog is smart enough to detect
> that the hostname is missing if the tag is followed by a character not
> valid in hostnames. But if the tag even looks like a hostname, it has
> no chance of detecting that it isn't one. As suggested, see RFC 3164
> for what the format should look like. I think the -x option (or some
> other) enables to strip hostname detection, but I am not sure. You can
> "solve" this by misusing some fields. E.g. FROMHOST probably has what
> actually is the tag. HKS suggestion will help you find a suitable
> format.
> 
> You were right Rainer. It looks like the java code which injects the
> message is sending malformed
> syslog requests.

Please provide samples of the raw messages, what syslog-ng does to them
and what rsyslog does (and what you would ideally like to see, if that's
different in any aspect ;)). [I know you have sent most of it - except
the source message, but I'd like to have a consistent set to look at.]

> syslog-ng still sends it through and does the correct
> things. Is there a way to make
> rsyslog a bit less strict about it? 

It depends on the above things. The problem is that when we cannot
detect whether it is a tag or a hostname, there is no way to do it
automatically. I can, of course, add a switch that tells the parser that
there never is a hostname inside the message. I suspect this is what
syslog-ng is doing. This prevents relay chains from properly conveying
the hostname, but I guess it would work in your case. It needs to be a
user option, because obviously most users will never want to use this
handling.

> Running rsyslog with -c0 defeats
> the purpose of using rsyslog.

Well... not really. The -cX switches change some aspects of behavior,
but do not change the core itself. However, I do not think that -c0
would change anything. Does it? If so, my analysis would obviously be
wrong...

> Until our application has been fixed and rolled out accross our
> clusters worldwide, we rolled back to syslog-ng.

Of course, I'd like to support the format as-is (under above
constraints;)).

Rainer
> 
> 
> >>
> >> Is there an equivalent of "-x" with "-c 3" enabled? It doesn't seem
> to
> >> work with -c3 and I'd
> >> rather not run in compatibility mode.
> >
> >
> > I don't think so.
> >
> > -HKS
> >
> 
> 
> 
> --
> Jeff Schroeder
> 
> Don't drink and derive, alcohol and analysis don't mix.
> http://www.digitalprognosis.com
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Mon Sep  1 16:41:45 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 01 Sep 2008 16:41:45 +0200
Subject: [rsyslog] broken size_nbr handling
In-Reply-To: <4255c2570808232301n5bab0c30w549df07c8e5b6c1f@mail.gmail.com>
References: <4255c2570808232301n5bab0c30w549df07c8e5b6c1f@mail.gmail.com>
Message-ID: <1220280105.7184.411.camel@rgf9dev.intern.adiscon.com>

Thanks for spotting this problem and the patch. I have just applied it
to the v3-stable branch, will be moved to all others soon.

Rainer

On Sun, 2008-08-24 at 00:01 -0600, RB wrote:
> In implementing my own 'human-readable' size parser (would be nice to
> have one as a part of one of the usable objects), I noticed there
> seemed to be order-of-magnitude issues on the base-10 size definitions
> in cfsysline.c.  Although the base-2 operations properly increase 2^10
> (1024) for each SI prefix, the base-10 ones only increase by one order
> of magnitude (10) instead of the proper 10^3 per prefix, ending up
> with EB only being 10^8 instead of 10^18.
> 
> Following is a simple patch that should put things right:
> ======================================
> diff --git a/runtime/cfsysline.c b/runtime/cfsysline.c
> index 18643ba..1989247 100644
> --- a/runtime/cfsysline.c
> +++ b/runtime/cfsysline.c
> @@ -215,11 +215,11 @@ static rsRetVal doGetSize(uchar **pp, rsRetVal
> (*pSetHdlr)(void*, uid_t), void *
>                 case 'e': i *= (int64) 1024 * 1024 * 1024 * 1024 *
> 1024 * 1024; ++(*pp); break; /* exa */
>                 /* and now the "new" 1000-based definitions */
>                 case 'K': i *= 1000; ++(*pp); break;
> -               case 'M': i *= 10000; ++(*pp); break;
> -               case 'G': i *= 100000; ++(*pp); break;
> -               case 'T': i *= 1000000; ++(*pp); break; /* tera */
> -               case 'P': i *= 10000000; ++(*pp); break; /* peta */
> -               case 'E': i *= 100000000; ++(*pp); break; /* exa */
> +               case 'M': i *= 1000000; ++(*pp); break;
> +               case 'G': i *= 1000000000; ++(*pp); break;
> +               case 'T': i *= 1000000000000; ++(*pp); break; /* tera */
> +               case 'P': i *= 1000000000000000; ++(*pp); break; /* peta */
> +               case 'E': i *= 1000000000000000000; ++(*pp); break; /* exa */
>         }
> 
>         /* done */
> ======================================
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep  1 16:56:42 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 01 Sep 2008 16:56:42 +0200
Subject: [rsyslog] Running hashes
In-Reply-To: <4255c2570808230045kb625e11u795435a8a6c8d457@mail.gmail.com>
References: <4255c2570808230045kb625e11u795435a8a6c8d457@mail.gmail.com>
Message-ID: <1220281002.7184.426.camel@rgf9dev.intern.adiscon.com>

On Sat, 2008-08-23 at 01:45 -0600, RB wrote:
> Acting on an old comment from a friend, I decided to look into what
> it'd take to get rsyslog to perform running hashes of logs.
> Conceptually, it's pretty simple - every Nth message inject one
> message containing the hash of the previous N messages (including the
> previous hash message).  

Yes - this is the way IETF's upcoming syslog-sign is using hashes. It
may be tempting to use that mode for the logs, too...

> It also gave me an excuse to start digging
> into the rsyslog code.
> 
> At first I thought I could do it with a property replacer, but that
> seems a wash since those are wholly message-based and don't [seem to]
> give the opportunity to store information (even a running hash) of
> prior messages.  

That's right and that's by design. The property replacer is a one-way
road.

> A plugin was my next hope, but there doesn't seem to
> be a good mechanism to pipeline those together - AFAICT they're
> expected to be single ingress/egress points, with no interstitial
> stages. 

That's definitely true for input and output plugins. They, by very
definition, are at either end of the processing flow.

>  I see the code for loading other objects as Rainer mentioned
> in April, but that seems more for central functionality than for
> chaining modules together.

You are absolutely correct. These objects are (mostly) for internal
things, so to save us static binding - and the ability to use different
drivers for different needs, e.g. for different network transport
protocols (and maybe later for different, even-smaller and more
abstracted, database drivers).

> This all brings me back to one of my original questions for rsyslog -
> is module chaining something that is even on your radar?  I'm thinking
> normalization, hashing, encryption, etc.  Almost feels like there
> should be another layer here, maybe a "mangle" plugin interface that
> could stack in after im* and before om*?

You are definitely on the right route. If you look at the plugin
definitions, there is another class, not yet implemented, of plugins:
they are called "filter plugins". They will have the ability to take a
message, modify it (or inject a new one based on previous messages) and
so on - at least this is how it was designed roughly a year ago.

With the arrival of the scripting language (in February, if I correctly
remember), new players have entered the field: library plugins that
expose function calls to the script engine. So far, they do NOT yet
exist, but they are pretty well thought out. They are probably the first
thing I will implement when I start bringing the script engine to its
full power. These functions may also be a good place to provide a
"mangling" interface. I am still a bit undecided, maybe I will not 100%
design this, but let the code evolve (sometimes, I think, it is good to
look at code written and see if that "extra bit" just naturally fits
in...).

A bit problematic is the order of events (and message modification) when
the message object is run asynchronously through multiple action queues.
For each queue, the message is forked, so it requires careful design
when to modify which of the forked messages. This can be very powerful,
but also quite complex to configure (where the scripting language
hopefully comes in handy).

Another, internal, thing is message synchronization. So far, property
creation and modification never requires sync objects (like mutexes),
because the always happen in a single thread (for ONE specific message,
of course). With mangling capabilities, things change considerably,
property set methods than need sync capability. This must be implemented
in a way that does not hurt the (for more frequent) case of message
object creation.

Of course, all of this is doable and the base design is there :) I just
wanted to provide an idea why it may take a little while to implement.
Comments and suggestions are most welcome, especially as this is among
the next things on my todo list (if priorities don't change).

Rainer
> 
> 
> RB
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep  1 17:00:15 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 1 Sep 2008 17:00:15 +0200
Subject: [rsyslog] Running hashes
In-Reply-To: <1220281002.7184.426.camel@rgf9dev.intern.adiscon.com>
References: <4255c2570808230045kb625e11u795435a8a6c8d457@mail.gmail.com>
	<1220281002.7184.426.camel@rgf9dev.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F064@grfint2.intern.adiscon.com>

I forgot one thing. If you did not already find it, have a look at this:

http://www.rsyslog.com/doc-generic_design.html

The filter/function plugins are conceptually on the "PLG Ext" et al
layer in this chart. This is not specifically rsyslog design, but it
comes from the same source and conveys the same basic idea ;) [I
initially did that description for some generic IETF work].

Maybe it is useful.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Monday, September 01, 2008 4:57 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] Running hashes
> 
> On Sat, 2008-08-23 at 01:45 -0600, RB wrote:
> > Acting on an old comment from a friend, I decided to look into what
> > it'd take to get rsyslog to perform running hashes of logs.
> > Conceptually, it's pretty simple - every Nth message inject one
> > message containing the hash of the previous N messages (including
the
> > previous hash message).
> 
> Yes - this is the way IETF's upcoming syslog-sign is using hashes. It
> may be tempting to use that mode for the logs, too...
> 
> > It also gave me an excuse to start digging
> > into the rsyslog code.
> >
> > At first I thought I could do it with a property replacer, but that
> > seems a wash since those are wholly message-based and don't [seem
to]
> > give the opportunity to store information (even a running hash) of
> > prior messages.
> 
> That's right and that's by design. The property replacer is a one-way
> road.
> 
> > A plugin was my next hope, but there doesn't seem to
> > be a good mechanism to pipeline those together - AFAICT they're
> > expected to be single ingress/egress points, with no interstitial
> > stages.
> 
> That's definitely true for input and output plugins. They, by very
> definition, are at either end of the processing flow.
> 
> >  I see the code for loading other objects as Rainer mentioned
> > in April, but that seems more for central functionality than for
> > chaining modules together.
> 
> You are absolutely correct. These objects are (mostly) for internal
> things, so to save us static binding - and the ability to use
different
> drivers for different needs, e.g. for different network transport
> protocols (and maybe later for different, even-smaller and more
> abstracted, database drivers).
> 
> > This all brings me back to one of my original questions for rsyslog
-
> > is module chaining something that is even on your radar?  I'm
> thinking
> > normalization, hashing, encryption, etc.  Almost feels like there
> > should be another layer here, maybe a "mangle" plugin interface that
> > could stack in after im* and before om*?
> 
> You are definitely on the right route. If you look at the plugin
> definitions, there is another class, not yet implemented, of plugins:
> they are called "filter plugins". They will have the ability to take a
> message, modify it (or inject a new one based on previous messages)
and
> so on - at least this is how it was designed roughly a year ago.
> 
> With the arrival of the scripting language (in February, if I
correctly
> remember), new players have entered the field: library plugins that
> expose function calls to the script engine. So far, they do NOT yet
> exist, but they are pretty well thought out. They are probably the
> first
> thing I will implement when I start bringing the script engine to its
> full power. These functions may also be a good place to provide a
> "mangling" interface. I am still a bit undecided, maybe I will not
100%
> design this, but let the code evolve (sometimes, I think, it is good
to
> look at code written and see if that "extra bit" just naturally fits
> in...).
> 
> A bit problematic is the order of events (and message modification)
> when
> the message object is run asynchronously through multiple action
> queues.
> For each queue, the message is forked, so it requires careful design
> when to modify which of the forked messages. This can be very
powerful,
> but also quite complex to configure (where the scripting language
> hopefully comes in handy).
> 
> Another, internal, thing is message synchronization. So far, property
> creation and modification never requires sync objects (like mutexes),
> because the always happen in a single thread (for ONE specific
message,
> of course). With mangling capabilities, things change considerably,
> property set methods than need sync capability. This must be
> implemented
> in a way that does not hurt the (for more frequent) case of message
> object creation.
> 
> Of course, all of this is doable and the base design is there :) I
just
> wanted to provide an idea why it may take a little while to implement.
> Comments and suggestions are most welcome, especially as this is among
> the next things on my todo list (if priorities don't change).
> 
> Rainer
> >
> >
> > RB
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Tue Sep  2 12:47:08 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 2 Sep 2008 12:47:08 +0200
Subject: [rsyslog] preview of 3.21.4 devel
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F073@grfint2.intern.adiscon.com>

Hi all,

I am about to release 3.21.4, BUT it contains one big change and I would
appreciate if some of you could give it a try before I officially
release it. In 3.21.4, I have removed the compile-time hardcoded maximum
message size. So far, a message, by default, could be 2K maximum. This
could be changed by modifying the MAXLINE compile time default (and
recompiling/install). This size limit stems back to plain old BSD
syslogd, RFC 3164 (where it is 1k) and the upcoming syslog RFC series
(where it is variable, but 2k is suggested as a minimum). There have
been a lot of questions about larger sizes. So I have now streamlined
the process and created a simple config directive:

$MaxMessageSize 4k

Where 4k is of your choice. You may also specify any non-k value, like
7341. I do not check for a sensible maximum, so you may also specify 4p
(4 petabyte), but I hardly believe that will get you a working instance
;)

I did not blindly change the message size - I tried to keep performance
as good as with the previous approach (dyn memory alloc takes more
time!). So there is chance for failure all over the code. In my test (up
to now), everything works, but I would really appreciate some feedback
from practice.

Please let me know if you experience any issues with that release.

It is available at

http://download.rsyslog.com/rsyslog/rsyslog-3.21.4-Test1.tar.gz

This version also contains a number of smaller fixes, but not yet the
new doc building system (this is next on my agenda).

Your feedback is appreciated.

Rainer


From r.bhatia at ipax.at  Thu Sep  4 10:21:54 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 04 Sep 2008 10:21:54 +0200
Subject: [rsyslog] Problems with spooling to disk
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44EFC8@grfint2.intern.adiscon.com>
References: <20080807120552.GA16724@darville.vm.bytemark.co.uk><577465F99B41C842AAFBE9ED71E70ABA44EF6B@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44EF80@grfint2.intern.adiscon.com><48A2BFA7.8000408@ipax.at>	<1218630780.7184.368.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44EFC8@grfint2.intern.adiscon.com>
Message-ID: <48BF9AA2.1070904@ipax.at>

hi,

i yesterday deployed 3.18.3 and verified that the fix you told specified
below is in the source.

unfortunatly, this does not help and rsyslog hangs. please follow the
steps below to reproduce the error:

1) setup two servers. A is the rsyslog "client" and B is the rsyslog
   server logging to mysql.

A is configured with the debian default config and:
> $WorkDirectory /var/spool/rsyslog/ # where to place spool files
> $ActionQueueFileName remote # unique name prefix for spool files
> $ActionQueueMaxDiskSpace 100M   # 100mb space limit (use as much as possible)
> $ActionQueueSaveOnShutdown on # save messages to disk on shutdown
> $ActionQueueType LinkedList   # run asynchronously
> $ActionResumeRetryCount -1    # infinite retries if host is down
> # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
> *.* @@b.ipax.at:514

B is configured with the debian default config and:
> # provides UDP syslog reception
> $ModLoad imudp
> $UDPServerRun 514
> 
> # provides TCP syslog reception
> $ModLoad imtcp
> $InputTCPServerRun 514
> ...
> $ModLoad ommysql
> :programname, isequal, "prog1" ~
> :programname, isequal, "prog2" ~
> *.* :ommysql:localhost,Syslog,dbuser,dbpass

2) we start A and B and verify that it works correctly:
messages on A are logged to /var/log/ and sent to B

messages on B (= originating from A and B) are logged to /var/log/ and
are sent to the mysql db.

3) i connect to the mysql db and run some sql statements:
> delete from SystemEvents where SysLogTag like "prog1[%";
> delete from SystemEvents where SysLogTag like "prog2[%";
> delete from SystemEvents where SysLogTag like "pam_limits[%";

4) whilst the statement is running, issue the following command on B:
> logger testt

5) observe that testt is neither logged to the mysql db (thats expected
as delete locks the myisam table) but also not logged to /var/log/

this effectivly blocks something causing server A to not function
properly. e.g. apache2, sshd, bind, etc are not working properly.

please help :)

cheers,
raoul


Rainer Gerhards wrote:
> This is the v3-stable fix:
> 
> http://git.adiscon.com/?p=rsyslog.git;a=blobdiff;f=plugins/imuxsock/imux
> sock.c;h=60ccaffbc526a03011be3ce5869e40bc3e32c319;hp=f8798039c5d53e58fc7
> fa17807547862e08c999e;hb=8eb888d049da12e1294a7688432b6325794ade32;hpb=02
> f768c37dac9dde424bbd31e378482750fc276c
> 
> You can also easily apply it to 3.16 - I just won't do it that version
> has been superseded.
> 
> Rainer
> 
>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
>> Sent: Wednesday, August 13, 2008 2:33 PM
>> To: rsyslog-users
>> Subject: Re: [rsyslog] Problems with spooling to disk
>>
>> On Wed, 2008-08-13 at 13:04 +0200, Raoul Bhatia [IPAX] wrote:
>>> hi,
>>>
>>> Rainer Gerhards wrote:
>>>> Thanks, I now received the log files. And, of course, they made
>>>> immediately clear what is going on ;) What you experience is flow
>>>> control kicking in. Let me first elaborate a bit:
>>>>
>>>> Rsyslog knows inputs which can be delayed a bit (like tcp receiver
>> AND
>>>> the local socket) and those who can not (like UDP). The idea is
>> that we
>>>> can slow down senders where this does not result in loss of
>> messages,
>>>> leaving room inside the queue on busy systems for those where we
>> can not
>>>> do that. We had cases where not delaying caused a lot of grief.
>>>>
>>>> There are also two watermarks, the low and high delay mark. If the
>> low
>>>> delay mark is reached, a delayable source is delayed for one
>> second. It
>>>> is at 70% of the (in-memory) queue capacity. Again, this is all
>> done for
>>>> some very good reasons.
>>>>
>>>> However, when I introduced these features, I did not make them
>>>> configurable. Also, I did classify the local unix socket as one
> who
>> can
>>>> be delayed. In your scenario, this does not stop the system, but
>> once
>>>> the local log socket is filled up, it needs to wait one second for
>> each
>>>> message before it is pulled.
>>>>
>>>> Again, the rate limiting logic is there for good reasons. So what
> I
>> now
>>>> see is that I need to add a few config statements to allow to
>> control it
>>>> according to your needs. I am also unsure if I should re-classify
>>>> imuxsock as an input which cannot be delayed - but that also can
>> have
>>>> some drawbacks. Maybe the best thing to do is make its state
>>>> configurable and use "not to be delayed" as default.
>>> ok, after reading through your explanation, i (almost) understand
> the
>>> delay mechanism and that at present it is not configurable.
>>>
>>> almost, because i do not get the part where you talk about the "70%
>> of
>>> the (in-memory) queue capacity".
>> An example: if the configured queue capacity is 10,000 (the default
>> value for the main message queue), than no flow control at all happens
>> until 7,000 messages are inside the queue. Once they are (and only as
>> long as they are), flow control is applied to those inputs that permit
>> it (imuxsock permits it).
>>
>> It doesn't matter here if the queue is disk-assisted or not. Even with
>> disk-assisted queues, this setting is very important to prevent an
>> input
>> (e.g. imfile!) to send massive amounts of data to the queue when there
>> is no need to (because the input can be flow-controlled).
>>
>>> anyways, how does this relate to the original problem, that the
>>> following code stalls the logging process.
>>>
>>>>>> #! /bin/sh
>>>>>> for ((i=1;i<=10000;i+=1)); do
>>>>>>   logger Log line $i
>>>>>> done
>>> is this a capacity problem? is this another problem?
>> It is going over the flow control watermark, flow control kicks in and
>> delays imuxsock writes by one second each as long as there are more
>> than
>> 7,000 messages. No problem, intended behavior, but obviously
>> questionable. In the imuxsock case, there are also some bad cases.
>>
>>> i really consider this a critical bug, as i yesterday ran out of
>>> diskspace on my remote-rsyslog-and-mysql-on-one-host-testbed and the
>>> rsyslog-client, which logs locally and to the remote destination,
>>> stalled completely.
>> We'll - not completely, one message per second ;) But that's probably
>> complete enough ;)
>>
>> As a quick fix, I think I'll make imuxsock a non-flow-controllable
>> input
>> in the v3-stable (3.18.x). The devel will have a switch to make it
> flow
>> controlled if one desires. I'll also add some other knobs to fine-tune
>> the flow control algo, but that probably needs to wait until after my
>> summer break. These tweaks could easily break things and I don't like
>> the idea of doing them under time pressure ;)
>>
>> HTH
>> Rainer
>>> cheers,
>>> raoul
>>> ps: i am on 3.16.1-1~bpo40+1
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep  4 10:26:19 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 4 Sep 2008 10:26:19 +0200
Subject: [rsyslog] Problems with spooling to disk
In-Reply-To: <48BF9AA2.1070904@ipax.at>
References: <20080807120552.GA16724@darville.vm.bytemark.co.uk><577465F99B41C842AAFBE9ED71E70ABA44EF6B@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44EF80@grfint2.intern.adiscon.com><48A2BFA7.8000408@ipax.at>	<1218630780.7184.368.camel@rgf9dev.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44EFC8@grfint2.intern.adiscon.com>
	<48BF9AA2.1070904@ipax.at>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0A0@grfint2.intern.adiscon.com>

Hi Raoul,

could you quickly mail me a debug log of the client? I know I can set up
the lab per your instructions, but that will need some time. Depending
on what I see in the debug log, we could come much quicker to a solution
[I am currently quite busy after my vacation, so I will probably not be
able to set up the lab this week] ;). You can mail the log to me
privately.

Thanks,
Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX]
> Sent: Thursday, September 04, 2008 10:22 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] Problems with spooling to disk
> 
> hi,
> 
> i yesterday deployed 3.18.3 and verified that the fix you told
> specified
> below is in the source.
> 
> unfortunatly, this does not help and rsyslog hangs. please follow the
> steps below to reproduce the error:
> 
> 1) setup two servers. A is the rsyslog "client" and B is the rsyslog
>    server logging to mysql.
> 
> A is configured with the debian default config and:
> > $WorkDirectory /var/spool/rsyslog/ # where to place spool files
> > $ActionQueueFileName remote # unique name prefix for spool files
> > $ActionQueueMaxDiskSpace 100M   # 100mb space limit (use as much as
> possible)
> > $ActionQueueSaveOnShutdown on # save messages to disk on shutdown
> > $ActionQueueType LinkedList   # run asynchronously
> > $ActionResumeRetryCount -1    # infinite retries if host is down
> > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
> > *.* @@b.ipax.at:514
> 
> B is configured with the debian default config and:
> > # provides UDP syslog reception
> > $ModLoad imudp
> > $UDPServerRun 514
> >
> > # provides TCP syslog reception
> > $ModLoad imtcp
> > $InputTCPServerRun 514
> > ...
> > $ModLoad ommysql
> > :programname, isequal, "prog1" ~
> > :programname, isequal, "prog2" ~
> > *.* :ommysql:localhost,Syslog,dbuser,dbpass
> 
> 2) we start A and B and verify that it works correctly:
> messages on A are logged to /var/log/ and sent to B
> 
> messages on B (= originating from A and B) are logged to /var/log/ and
> are sent to the mysql db.
> 
> 3) i connect to the mysql db and run some sql statements:
> > delete from SystemEvents where SysLogTag like "prog1[%";
> > delete from SystemEvents where SysLogTag like "prog2[%";
> > delete from SystemEvents where SysLogTag like "pam_limits[%";
> 
> 4) whilst the statement is running, issue the following command on B:
> > logger testt
> 
> 5) observe that testt is neither logged to the mysql db (thats
expected
> as delete locks the myisam table) but also not logged to /var/log/
> 
> this effectivly blocks something causing server A to not function
> properly. e.g. apache2, sshd, bind, etc are not working properly.
> 
> please help :)
> 
> cheers,
> raoul
> 
> 
> Rainer Gerhards wrote:
> > This is the v3-stable fix:
> >
> >
>
http://git.adiscon.com/?p=rsyslog.git;a=blobdiff;f=plugins/imuxsock/imu
> x
> >
>
sock.c;h=60ccaffbc526a03011be3ce5869e40bc3e32c319;hp=f8798039c5d53e58fc
> 7
> >
>
fa17807547862e08c999e;hb=8eb888d049da12e1294a7688432b6325794ade32;hpb=0
> 2
> > f768c37dac9dde424bbd31e378482750fc276c
> >
> > You can also easily apply it to 3.16 - I just won't do it that
> version
> > has been superseded.
> >
> > Rainer
> >
> >> -----Original Message-----
> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >> Sent: Wednesday, August 13, 2008 2:33 PM
> >> To: rsyslog-users
> >> Subject: Re: [rsyslog] Problems with spooling to disk
> >>
> >> On Wed, 2008-08-13 at 13:04 +0200, Raoul Bhatia [IPAX] wrote:
> >>> hi,
> >>>
> >>> Rainer Gerhards wrote:
> >>>> Thanks, I now received the log files. And, of course, they made
> >>>> immediately clear what is going on ;) What you experience is flow
> >>>> control kicking in. Let me first elaborate a bit:
> >>>>
> >>>> Rsyslog knows inputs which can be delayed a bit (like tcp
receiver
> >> AND
> >>>> the local socket) and those who can not (like UDP). The idea is
> >> that we
> >>>> can slow down senders where this does not result in loss of
> >> messages,
> >>>> leaving room inside the queue on busy systems for those where we
> >> can not
> >>>> do that. We had cases where not delaying caused a lot of grief.
> >>>>
> >>>> There are also two watermarks, the low and high delay mark. If
the
> >> low
> >>>> delay mark is reached, a delayable source is delayed for one
> >> second. It
> >>>> is at 70% of the (in-memory) queue capacity. Again, this is all
> >> done for
> >>>> some very good reasons.
> >>>>
> >>>> However, when I introduced these features, I did not make them
> >>>> configurable. Also, I did classify the local unix socket as one
> > who
> >> can
> >>>> be delayed. In your scenario, this does not stop the system, but
> >> once
> >>>> the local log socket is filled up, it needs to wait one second
for
> >> each
> >>>> message before it is pulled.
> >>>>
> >>>> Again, the rate limiting logic is there for good reasons. So what
> > I
> >> now
> >>>> see is that I need to add a few config statements to allow to
> >> control it
> >>>> according to your needs. I am also unsure if I should re-classify
> >>>> imuxsock as an input which cannot be delayed - but that also can
> >> have
> >>>> some drawbacks. Maybe the best thing to do is make its state
> >>>> configurable and use "not to be delayed" as default.
> >>> ok, after reading through your explanation, i (almost) understand
> > the
> >>> delay mechanism and that at present it is not configurable.
> >>>
> >>> almost, because i do not get the part where you talk about the
"70%
> >> of
> >>> the (in-memory) queue capacity".
> >> An example: if the configured queue capacity is 10,000 (the default
> >> value for the main message queue), than no flow control at all
> happens
> >> until 7,000 messages are inside the queue. Once they are (and only
> as
> >> long as they are), flow control is applied to those inputs that
> permit
> >> it (imuxsock permits it).
> >>
> >> It doesn't matter here if the queue is disk-assisted or not. Even
> with
> >> disk-assisted queues, this setting is very important to prevent an
> >> input
> >> (e.g. imfile!) to send massive amounts of data to the queue when
> there
> >> is no need to (because the input can be flow-controlled).
> >>
> >>> anyways, how does this relate to the original problem, that the
> >>> following code stalls the logging process.
> >>>
> >>>>>> #! /bin/sh
> >>>>>> for ((i=1;i<=10000;i+=1)); do
> >>>>>>   logger Log line $i
> >>>>>> done
> >>> is this a capacity problem? is this another problem?
> >> It is going over the flow control watermark, flow control kicks in
> and
> >> delays imuxsock writes by one second each as long as there are more
> >> than
> >> 7,000 messages. No problem, intended behavior, but obviously
> >> questionable. In the imuxsock case, there are also some bad cases.
> >>
> >>> i really consider this a critical bug, as i yesterday ran out of
> >>> diskspace on my remote-rsyslog-and-mysql-on-one-host-testbed and
> the
> >>> rsyslog-client, which logs locally and to the remote destination,
> >>> stalled completely.
> >> We'll - not completely, one message per second ;) But that's
> probably
> >> complete enough ;)
> >>
> >> As a quick fix, I think I'll make imuxsock a non-flow-controllable
> >> input
> >> in the v3-stable (3.18.x). The devel will have a switch to make it
> > flow
> >> controlled if one desires. I'll also add some other knobs to fine-
> tune
> >> the flow control algo, but that probably needs to wait until after
> my
> >> summer break. These tweaks could easily break things and I don't
> like
> >> the idea of doing them under time pressure ;)
> >>
> >> HTH
> >> Rainer
> >>> cheers,
> >>> raoul
> >>> ps: i am on 3.16.1-1~bpo40+1
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> 
> 
> --
> ____________________________________________________________________
> DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
> Technischer Leiter
> 
> IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
> Barawitzkagasse 10/2/2/11           email.            office at ipax.at
> 1190 Wien                           tel.               +43 1 3670030
> FN 277995t HG Wien                  fax.            +43 1 3670030 15
> ____________________________________________________________________
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Thu Sep  4 11:52:40 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 04 Sep 2008 11:52:40 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080820170735.GB20932@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
Message-ID: <1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>

Hi,

I was now able to apply the patch series - many thanks. It is currently
in the docbook branch, which is also available on my public git server
(so that others can follow).

I am digging into what the patches actually do and, not surprisingly, I
finally need to learn a bit more about docbook to fully understand it
(looks like this gets my prime activity for the time being ;)).

One thing I already noticed. The man pages are generated via the
--enable-regenerate-man switch, but they are also in git. So when I
regenerate them, this results in a large volume of git changes.

In my POV, the man pages are now output files and as such no longer
something that belongs into git. I understand that this has the
implication that when I remove them from git, everyone who pulls the git
archive needs to have the proper tools in place to generate the doc.
However, is this really a problem? AFAIK other projects have similar
demands. So I would prefer to remove the man pages themselves from git
(but of course not from autotools config files, so that they be still
present in a release tarball).

Does this sound reasonable? Any objections (from anyone)?

I also have not yet fully understood the translation workflow. If
the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
be created with the English source doc, which I maintain)?

Please advise.

Thanks,
Rainer


On Thu, 2008-08-21 at 02:07 +0900, Satoru SATOH wrote:
> Hello,
> 
> 
> I posted the first patch but it seems the patch was too big to post. I
> list them here at once.
> 
> Could you please take some time to review these and merge them?
> 
> 
> I splitted origianl big patch into minimum units. However, to complete
> to man-i18n support, the following patches must be applied in this
> order.
> 
> All of the patches below are available from
> http://www.gnome.gr.jp/~ss/t/rsyslog/.
> 
> 
> 1. 0001-man-i18n-move-man-files-from-tools-to-man-C.patch
> 
> This patch just moves man files from tools/ to man/C/ (new dir to hold
> man related stuff) and update related Makefile.am files.
> 
> 
> 2. 0002-man-i18n-add-man-ja.patch
> 
> This patch creates new dir, man/ja/ and Makefile.am in it.
> 
> There are no man files in it and this should not have harmful effects
> for build process at all, I guess.
> 
> 
> 3. 0003-man-i18n-add-man-ja.patch
> 
> This patch adds man files in man/ja and update Makefile.am in it to
> install these.
> 
> 
> 4. 0004-man-i18n-add-docbook-xml-sources-for-man-files.patch
> 
> This patch adds docbook XML sources for man pages.
> 
> 
> 5. 0005-man-i18n-add-m4-macros-in-m4-and-make-aclocal-look.patch
> 
> This patch adds m4 macros in m4/ and make aclocal look for this dir.
> 
> These m4 files are not evaluated in actual and this should not have
> adverse effect at all, I guess.
> 
> 
> 6. 0006-man-i18n-add-build-process-of-man-pages-in-Makefile.patch
> 
> This patch adds transformation process of man pages and po files in
> Makefile.am.
> 
> Added part are in "if ENABLE_REGENERATE_MAN ... endif" and
> ENABLE_REGENERATE_MAN is not defined at this point, so this also should
> not have side effects.
> 
> 
> 7. 0007-man-i18n-add-enable-regenerate-man-option-for-con.patch
> 
> This is the last one. This patch adds "--enable-regenerate-man"
> configure option to enable man build process.
> 
> This option is disabled by default and should not affect normal build
> process, I think.
> 
> 
> How to build:
> 
> To enable the man build process, configure have to be regenerated:
> 
>   $ (autoreconf -vfi && \
>         ./configure --enable-regenerate-man [...other options] && \
>         make && make install
> 
> 
> Translator's workflow:
> 
>  a. initial translation:
> 
>    0. arrange lang dir, that is, cp man/ja to man/YOUR_LANG/ and edit
>       Makefile.am; s/ja/YOUR_LANG/.
>    1. create POT: make -C man/YOUR_LANG/ create-pot
>    2. copy POT to PO and translate it
>    3. run make
> 
>  b. maintanance:
> 
>    1. update PO: make -C man/YOUR_LANG update-po
>    2. update translations
>    3. just run make
> 
> 
> Requirements for man regeneration / translation:
>  
>    xmllint, xsltproc, xml2po in gnome-doc-utils, DocBook DTD and DocBook
>    xslt stylesheet for man pages are required.
> 
>    If xmlcatalog (e.g. /etc/xml/catalog) is configured appropriately,
>    both xmllint and xsltproc will use local DTD and stylsheet files
>    instead of these from remote site
>    (http://www.oasis-open.org/docbook/...).
> 
> 
> - satoru
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From friedl at hq.adiscon.com  Thu Sep  4 12:45:10 2008
From: friedl at hq.adiscon.com (Florian Riedl)
Date: Thu, 4 Sep 2008 12:45:10 +0200
Subject: [rsyslog] rsyslog 3.21.4 (devel) released
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0AA@grfint2.intern.adiscon.com>

Hi all,

we have just released rsyslog 3.21.4, a devel branch release. The most
important new feature is the ability to dynamically configure the
maximum length of a syslog message. Previously, this was only possible
via a recompile and can now be done via the new $MaxMessageSize config
directive. There are also a number of bugfixes new in this release. It
is a recommended update for all devel branch users.


Download:

http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-130.phtml

Changelog:

http://www.rsyslog.com/Article275.phtml

As always, feedback is appreciated.

Florian Riedl
--
Support
=======

Improving rsyslog is costly, but you can help!  We are looking for
organizations that find rsyslog useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for rsyslog are available, and they help
finance continued maintenance.  Adiscon GmbH, a privately held German
company, is currently funding rsyslog development. We are always looking
for interesting development projects. For details on how to help, please
see http://www.rsyslog.com/doc-how2help.html .



From satoru.satoh at gmail.com  Thu Sep  4 22:31:59 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Fri, 5 Sep 2008 05:31:59 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
Message-ID: <20080904203155.GA6912@localhost.localdomain>

Hi,


On Thu, Sep 04, 2008 at 11:52:40AM +0200, Rainer Gerhards wrote:
> Hi,
> 
> I was now able to apply the patch series - many thanks. It is currently
> in the docbook branch, which is also available on my public git server
> (so that others can follow).

Thanks!

> I am digging into what the patches actually do and, not surprisingly, I
> finally need to learn a bit more about docbook to fully understand it
> (looks like this gets my prime activity for the time being ;)).
> 
> One thing I already noticed. The man pages are generated via the
> --enable-regenerate-man switch, but they are also in git. So when I
> regenerate them, this results in a large volume of git changes.
 
Right.

> In my POV, the man pages are now output files and as such no longer
> something that belongs into git. I understand that this has the
> implication that when I remove them from git, everyone who pulls the git
> archive needs to have the proper tools in place to generate the doc.

Exactly. Addtional requirements are the followings.

 - xslt processor, xsltproc
 - xml validator, xmllint
 - properly configured xml catalog or internet access
 - docbook xml dtd (local or remote)
 - docbook xsl stylesheet for docbook-to-man transformation (local or
   remote)
 - xml2po in gnome-doc-utils (optional; must for translators)

I thought that not all of developers have such system and so that this
should be avoided. This is why I disabled man-regeneration process by
default.

> However, is this really a problem? AFAIK other projects have similar
> demands. So I would prefer to remove the man pages themselves from git
> (but of course not from autotools config files, so that they be still
> present in a release tarball).
> 
> Does this sound reasonable? Any objections (from anyone)?

One thing i have to mention.

Actually, man files generated from docbook xml files are slightly
different from original man files ATM. These need some refactoring.

If it's not a matter, it would be ok.

> I also have not yet fully understood the translation workflow. If
> the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
> version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
> be created with the English source doc, which I maintain)?

It is a little much complicated than that. Here are example steps for
german (de) man pages.


[initial translation]

  1. create mandir and makefile.am in it

     $ mkdir man/de && \
        sed 's/LANG = ja/LANG = de/' man/ja/Makefile.am > \
                man/de/Makefile.am

  2. add man/de/ to SUBDIRS in man/Makefile.am

     $ sed -i 's/^\(SUBDIRS.*\)/\1 de/' man/Makefile.am

  3. add man/de/Makefile.am to AC_CONFIG_FILES in configure.ac

  4. generate man/de/Makefile.am

     $ autoreconf -vfi && ./configure --prefix=$(pwd)/i \
        --enable-regenerate-man

  5. generate POT (PO template; language independent) and rename it 

     $ make -C man/de create-pot
     $ mv man/de/rsyslog.conf.5.pot man/de/rsyslog.conf.5.po
     $ mv man/de/rsyslogd.8.pot man/de/rsyslogd.8.po

  6. edit necessary header fields in PO files

     $ vim man/de/rsyslog.conf.5.po
     $ cat man/de/rsyslog.conf.5.po
     msgid ""
     msgstr ""
     "Project-Id-Version: rsyslog HEAD\n"
     "POT-Creation-Date: 2008-09-05 04:41+0900\n"
     "PO-Revision-Date: 2008-09-05 05:01+0900\n"
     "Last-Translator: XXXXX YYYYY <xxxxyyyyy at example.com>\n"
     "Language-Team: German <LL at li.org>\n"
     "MIME-Version: 1.0\n"
     "Content-Type: text/plain; charset=UTF-8\n"
     "Content-Transfer-Encoding: 8bit\n"

     (snip)

  7. translate PO files

  8. generate man files

     $ ./configure --prefix=$(pwd)/i --enable-regenerate-man && make


[update translations]

  1. update PO to follow changes in original docbook xml files

     $ make -C man/de update-po


Please refer to man/ja/Makefile.am also. 


BTW, "C" (man/C) means C (English) locale. This is the traditional dir
name to keep original English message catalogs, I think.

- satoru

(snip)
> > How to build:
> > 
> > To enable the man build process, configure have to be regenerated:
> > 
> >   $ (autoreconf -vfi && \
> >         ./configure --enable-regenerate-man [...other options] && \
> >         make && make install
> > 
> > 
> > Translator's workflow:
> > 
> >  a. initial translation:
> > 
> >    0. arrange lang dir, that is, cp man/ja to man/YOUR_LANG/ and edit
> >       Makefile.am; s/ja/YOUR_LANG/.
> >    1. create POT: make -C man/YOUR_LANG/ create-pot
> >    2. copy POT to PO and translate it
> >    3. run make
> > 
> >  b. maintanance:
> > 
> >    1. update PO: make -C man/YOUR_LANG update-po
> >    2. update translations
> >    3. just run make
> > 
> > 
> > Requirements for man regeneration / translation:
> >  
> >    xmllint, xsltproc, xml2po in gnome-doc-utils, DocBook DTD and DocBook
> >    xslt stylesheet for man pages are required.
> > 
> >    If xmlcatalog (e.g. /etc/xml/catalog) is configured appropriately,
> >    both xmllint and xsltproc will use local DTD and stylsheet files
> >    instead of these from remote site
> >    (http://www.oasis-open.org/docbook/...).
> > 
> > 
> > - satoru


From mbiebl at gmail.com  Thu Sep  4 22:53:38 2008
From: mbiebl at gmail.com (Michael Biebl)
Date: Thu, 4 Sep 2008 22:53:38 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080904203155.GA6912@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
Message-ID: <aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>

Hi,

just curious: Are you also working on getting the other documentation
in doc/ converted to docbook?
Something like [1] would be awesome for rsyslog and I think with
docbook, pdf would just be another output format, right?

While it is great to have documentation at all, the current one is a
bit inconsistent and hard to navigate.


Cheers,
Michael

[1] http://www.exim.org/exim-pdf-current/doc/spec.pdf
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


From rfujita at redhat.com  Fri Sep  5 03:06:25 2008
From: rfujita at redhat.com (Ryo Fujita)
Date: Fri, 5 Sep 2008 10:06:25 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
	<aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
Message-ID: <745EC623-B3A0-4FC8-B01C-91A9BD8B2892@redhat.com>

Hi,

Yes, I'm converting other documentation in doc/ to DocBook xml.
# About 40 docs out of 90 has been converted.

But there are some issues to convert and restructure them,
I consult with Rainer-san out of the ML.

Best Rio.

On 2008/09/05, at 5:53, Michael Biebl wrote:

> Hi,
>
> just curious: Are you also working on getting the other documentation
> in doc/ converted to docbook?
> Something like [1] would be awesome for rsyslog and I think with
> docbook, pdf would just be another output format, right?
>
> While it is great to have documentation at all, the current one is a
> bit inconsistent and hard to navigate.
>
>
> Cheers,
> Michael
>
> [1] http://www.exim.org/exim-pdf-current/doc/spec.pdf
> -- 
> 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

########################################################################
Ryo Fujita <rfujita at redhat.com>
Senior Solution Architect, RHCE
Red Hat K.K.
TEL +81-3-5798-8500
FAX +81-3-5798-8599
Ebisu Neonato 8F
4-1-18 Ebisu, Shibuya-ku,
Tokyo Japan 1500013
########################################################################



From rgerhards at hq.adiscon.com  Fri Sep  5 08:11:39 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 5 Sep 2008 08:11:39 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
References: <20080820170735.GB20932@localhost.localdomain><1220521960.12304.15.camel@rgf9dev.intern.adiscon.com><20080904203155.GA6912@localhost.localdomain>
	<aa76cdac0809041353x4fa79cb7wb3dd967f697c7c23@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0C5@grfint2.intern.adiscon.com>

Just one additional note:

> While it is great to have documentation at all, the current one is a
> bit inconsistent and hard to navigate.

Suggestions for improvement are welcome ;)

Rainer


From rgerhards at hq.adiscon.com  Fri Sep  5 10:42:03 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 05 Sep 2008 10:42:03 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080904203155.GA6912@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
Message-ID: <1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>

Hi,

first of all, many thanks for your continued help. Please let me say
that I so far have very little experience with i18n/l10n under linux and
so may sometimes misunderstand something ;) Your detailled instructions
help much. The rest inline...

Rainer

On Fri, 2008-09-05 at 05:31 +0900, Satoru SATOH wrote:
> Hi,
> > In my POV, the man pages are now output files and as such no longer
> > something that belongs into git. I understand that this has the
> > implication that when I remove them from git, everyone who pulls the git
> > archive needs to have the proper tools in place to generate the doc.
> 
> Exactly. Addtional requirements are the followings.
> 
>  - xslt processor, xsltproc
>  - xml validator, xmllint
>  - properly configured xml catalog or internet access
>  - docbook xml dtd (local or remote)
>  - docbook xsl stylesheet for docbook-to-man transformation (local or
>    remote)
>  - xml2po in gnome-doc-utils (optional; must for translators)
> 
> I thought that not all of developers have such system and so that this
> should be avoided. This is why I disabled man-regeneration process by
> default.

I agree that this may be a problem. However, I don't think it is a very
serious one. I myself have contributed to some projects where I could
not build the documentation. This did not cause any trouble to me while
working at the program sources. Of course, if I would like to create a
full tarball, I need to have everything in place. But only few actually
needs this (am I right here?).

In contrast, the tarball must include the generated mans, as the average
user can not be expected to have the tools at hand (while we still
expect him to have everything at hand necessary to compile the program
sources).

So I would remove the files from git, but leave them within the
distribution source tarball.

> > However, is this really a problem? AFAIK other projects have similar
> > demands. So I would prefer to remove the man pages themselves from git
> > (but of course not from autotools config files, so that they be still
> > present in a release tarball).
> > 
> > Does this sound reasonable? Any objections (from anyone)?
> 
> One thing i have to mention.
> 
> Actually, man files generated from docbook xml files are slightly
> different from original man files ATM. These need some refactoring.

Could you please elaborate a bit on this? Does that mean that the
generated man files (after doing a "make") can not be immediately be
used and need some kind of (manual?) post-processing?

> 
> If it's not a matter, it would be ok.
> 
> > I also have not yet fully understood the translation workflow. If
> > the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
> > version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
> > be created with the English source doc, which I maintain)?
> 
> It is a little much complicated than that. Here are example steps for
> german (de) man pages.

thanks for the detailed instructions, I'll first do a lab to get some experience first (plus read a bit more in various docs) and post questions when/if they come up.




From rgerhards at hq.adiscon.com  Fri Sep  5 16:01:41 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 05 Sep 2008 16:01:41 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080904203155.GA6912@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
Message-ID: <1220623301.12304.61.camel@rgf9dev.intern.adiscon.com>

Hi,


On Fri, 2008-09-05 at 05:31 +0900, Satoru SATOH wrote:
> [snip]

Thanks again for the good description. I think I now understand the
process, but I would like to make sure I really do.

First of all, there seems to be a minor nit with the current set of
files. Please have a look at what happens here:

--------------------------------
[root at rgf9dev rsyslog]# xml2po -v
0.12.2
[root at rgf9dev rsyslog]# make -C man/ja create-pot
make: Entering directory `/home/rger/proj/rsyslog/man/ja'
/usr/bin/xml2po -e -o rsyslogd.8.pot ../C/rsyslogd.8.xml
Traceback (most recent call last):
  File "/usr/bin/xml2po", line 856, in <module>
    doSerialize(doc)
  File "/usr/bin/xml2po", line 589, in doSerialize
    outtxt += doSerialize(child)
  File "/usr/bin/xml2po", line 583, in doSerialize
    (starttag, content, endtag, translation) = processElementTag(node,
repl, 1)
  File "/usr/bin/xml2po", line 525, in processElementTag
    translation = translation.replace('<placeholder-%d/>' % (i),
replacement)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
4930: ordinal not in range(128)
make: *** [rsyslogd.8.pot] Error 1
make: Leaving directory `/home/rger/proj/rsyslog/man/ja'
----------------------------------

Do you have an idea how I can find out what exactly to fix (I think I
understand that there is in invalid character in rsyslogd.8.xml, but the
error message is not very helpful at pointing me at the actual trouble
source ;)).

>From an upper level view, I now understand the workflow as follows:

When I update the documentation, I update the files in ./man/C. These
are kept in docbook format and these are the only sources for the
English language documentation.

After I have updated these files, every translator needs to run 

$ make -C man/<lang> update-po

to update the PO files. The translators will work on the .po files only.
When they are (sufficiently ;)) finished, the man files need to be
regenerated. Let me elaborate a bit on this process, I'd like to get to
some details.

As far as I understand, this results in the .po files being converted
back to docbook. Then, docbook is used to generate the ultimate
destination, e.g. the man files. The same process is used to generate
the English files, except that the docbook tools are run directly,
because there were no interim .po files.

Is this description correct? I am asking because I think it would make
sense to generate different formats (man, html, pdf at least) from the
same set of source files. So I understand that .po is just an interim
step which makes translation easier, but there will be a translated
version which in turn can be processed into any format that docbook
tools support.

I'd greatly appreciate your feedback. If you know how to do it, I would
also greatly appreciate if you could provide me a patch (or
instructions) on how to generate pdf from the "man files".

Thanks,
Rainer


> > I also have not yet fully understood the translation workflow. If
> > the ./ja subdirectory is copied, doesn't it (soon) contain the Japanese
> > version? If so, shouldn't any other subdirectory be copied (e.g. an ./en
> > be created with the English source doc, which I maintain)?
> 
> It is a little much complicated than that. Here are example steps for
> german (de) man pages.
> 
> 
> [initial translation]
> 
>   1. create mandir and makefile.am in it
> 
>      $ mkdir man/de && \
>         sed 's/LANG = ja/LANG = de/' man/ja/Makefile.am > \
>                 man/de/Makefile.am
> 
>   2. add man/de/ to SUBDIRS in man/Makefile.am
> 
>      $ sed -i 's/^\(SUBDIRS.*\)/\1 de/' man/Makefile.am
> 
>   3. add man/de/Makefile.am to AC_CONFIG_FILES in configure.ac
> 
>   4. generate man/de/Makefile.am
> 
>      $ autoreconf -vfi && ./configure --prefix=$(pwd)/i \
>         --enable-regenerate-man
> 
>   5. generate POT (PO template; language independent) and rename it 
> 
>      $ make -C man/de create-pot
>      $ mv man/de/rsyslog.conf.5.pot man/de/rsyslog.conf.5.po
>      $ mv man/de/rsyslogd.8.pot man/de/rsyslogd.8.po
> 
>   6. edit necessary header fields in PO files
> 
>      $ vim man/de/rsyslog.conf.5.po
>      $ cat man/de/rsyslog.conf.5.po
>      msgid ""
>      msgstr ""
>      "Project-Id-Version: rsyslog HEAD\n"
>      "POT-Creation-Date: 2008-09-05 04:41+0900\n"
>      "PO-Revision-Date: 2008-09-05 05:01+0900\n"
>      "Last-Translator: XXXXX YYYYY <xxxxyyyyy at example.com>\n"
>      "Language-Team: German <LL at li.org>\n"
>      "MIME-Version: 1.0\n"
>      "Content-Type: text/plain; charset=UTF-8\n"
>      "Content-Transfer-Encoding: 8bit\n"
> 
>      (snip)
> 
>   7. translate PO files
> 
>   8. generate man files
> 
>      $ ./configure --prefix=$(pwd)/i --enable-regenerate-man && make
> 
> 
> [update translations]
> 
>   1. update PO to follow changes in original docbook xml files
> 
>      $ make -C man/de update-po
> 
> 
> Please refer to man/ja/Makefile.am also. 
> 
> 
> BTW, "C" (man/C) means C (English) locale. This is the traditional dir
> name to keep original English message catalogs, I think.
> 
> - satoru
> 
> (snip)
> > > How to build:
> > > 
> > > To enable the man build process, configure have to be regenerated:
> > > 
> > >   $ (autoreconf -vfi && \
> > >         ./configure --enable-regenerate-man [...other options] && \
> > >         make && make install
> > > 
> > > 
> > > Translator's workflow:
> > > 
> > >  a. initial translation:
> > > 
> > >    0. arrange lang dir, that is, cp man/ja to man/YOUR_LANG/ and edit
> > >       Makefile.am; s/ja/YOUR_LANG/.
> > >    1. create POT: make -C man/YOUR_LANG/ create-pot
> > >    2. copy POT to PO and translate it
> > >    3. run make
> > > 
> > >  b. maintanance:
> > > 
> > >    1. update PO: make -C man/YOUR_LANG update-po
> > >    2. update translations
> > >    3. just run make
> > > 
> > > 
> > > Requirements for man regeneration / translation:
> > >  
> > >    xmllint, xsltproc, xml2po in gnome-doc-utils, DocBook DTD and DocBook
> > >    xslt stylesheet for man pages are required.
> > > 
> > >    If xmlcatalog (e.g. /etc/xml/catalog) is configured appropriately,
> > >    both xmllint and xsltproc will use local DTD and stylsheet files
> > >    instead of these from remote site
> > >    (http://www.oasis-open.org/docbook/...).
> > > 
> > > 
> > > - satoru
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From jorge.fabregas at gmail.com  Fri Sep  5 16:03:03 2008
From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=)
Date: Fri, 5 Sep 2008 10:03:03 -0400
Subject: [rsyslog] Kernel facility & testing with logger command
Message-ID: <200809051003.03373.jorge.fabregas@gmail.com>

Hello everyone,

I'm using rsyslog for the first time and before getting into its features I'm 
doing some basic tests... This is a portion of what I have on my rsyslog.conf:

#KERN FACILITY
kern.=emerg     /var/log/syslog/kern/00-emerg
kern.=alert     /var/log/syslog/kern/01-alert
kern.=crit      /var/log/syslog/kern/02-crit
kern.=err       /var/log/syslog/kern/03-err
kern.=warning   /var/log/syslog/kern/04-warning
kern.=notice    /var/log/syslog/kern/05-notice
kern.=info      /var/log/syslog/kern/06-info
kern.=debug     /var/log/syslog/kern/07-debug

If I do any test with the logger command using the kern facility (and any 
severity) I don't see my message on any of the above files. Example:

logger -p kern.debug "this is a test"

I tried all the other facilities and they all work fine. It's just the kern 
facility. 

What am I missing ?  :)

Thanks in advance,
Jorge


From rgerhards at hq.adiscon.com  Fri Sep  5 16:04:30 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 5 Sep 2008 16:04:30 +0200
Subject: [rsyslog] Kernel facility & testing with logger command
In-Reply-To: <200809051003.03373.jorge.fabregas@gmail.com>
References: <200809051003.03373.jorge.fabregas@gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0DF@grfint2.intern.adiscon.com>

Out of my head, 98% sure: logger (and/or sylsog() call and or imuxsock) does not permit to use the kernel facility. This is to prevent someone from pretending to be the kernel.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Jorge F?bregas
> Sent: Friday, September 05, 2008 4:03 PM
> To: rsyslog at lists.adiscon.com
> Subject: [rsyslog] Kernel facility & testing with logger command
> 
> Hello everyone,
> 
> I'm using rsyslog for the first time and before getting into its
> features I'm
> doing some basic tests... This is a portion of what I have on my
> rsyslog.conf:
> 
> #KERN FACILITY
> kern.=emerg     /var/log/syslog/kern/00-emerg
> kern.=alert     /var/log/syslog/kern/01-alert
> kern.=crit      /var/log/syslog/kern/02-crit
> kern.=err       /var/log/syslog/kern/03-err
> kern.=warning   /var/log/syslog/kern/04-warning
> kern.=notice    /var/log/syslog/kern/05-notice
> kern.=info      /var/log/syslog/kern/06-info
> kern.=debug     /var/log/syslog/kern/07-debug
> 
> If I do any test with the logger command using the kern facility (and
> any
> severity) I don't see my message on any of the above files. Example:
> 
> logger -p kern.debug "this is a test"
> 
> I tried all the other facilities and they all work fine. It's just the
> kern
> facility.
> 
> What am I missing ?  :)
> 
> Thanks in advance,
> Jorge
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From hks.private at gmail.com  Fri Sep  5 16:55:11 2008
From: hks.private at gmail.com ((private) HKS)
Date: Fri, 5 Sep 2008 10:55:11 -0400
Subject: [rsyslog] Kernel facility & testing with logger command
In-Reply-To: <200809051003.03373.jorge.fabregas@gmail.com>
References: <200809051003.03373.jorge.fabregas@gmail.com>
Message-ID: <ac9ded160809050755sb94c292r65a003b22237980b@mail.gmail.com>

Can you paste in your full rsyslog.conf? It's difficult to
troubleshoot without knowing how you're setup.

-HKS

On Fri, Sep 5, 2008 at 10:03 AM, Jorge F?bregas
<jorge.fabregas at gmail.com> wrote:
> Hello everyone,
>
> I'm using rsyslog for the first time and before getting into its features I'm
> doing some basic tests... This is a portion of what I have on my rsyslog.conf:
>
> #KERN FACILITY
> kern.=emerg     /var/log/syslog/kern/00-emerg
> kern.=alert     /var/log/syslog/kern/01-alert
> kern.=crit      /var/log/syslog/kern/02-crit
> kern.=err       /var/log/syslog/kern/03-err
> kern.=warning   /var/log/syslog/kern/04-warning
> kern.=notice    /var/log/syslog/kern/05-notice
> kern.=info      /var/log/syslog/kern/06-info
> kern.=debug     /var/log/syslog/kern/07-debug
>
> If I do any test with the logger command using the kern facility (and any
> severity) I don't see my message on any of the above files. Example:
>
> logger -p kern.debug "this is a test"
>
> I tried all the other facilities and they all work fine. It's just the kern
> facility.
>
> What am I missing ?  :)
>
> Thanks in advance,
> Jorge
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From hks.private at gmail.com  Fri Sep  5 16:57:54 2008
From: hks.private at gmail.com ((private) HKS)
Date: Fri, 5 Sep 2008 10:57:54 -0400
Subject: [rsyslog] Kernel facility & testing with logger command
In-Reply-To: <ac9ded160809050755sb94c292r65a003b22237980b@mail.gmail.com>
References: <200809051003.03373.jorge.fabregas@gmail.com>
	<ac9ded160809050755sb94c292r65a003b22237980b@mail.gmail.com>
Message-ID: <ac9ded160809050757h72d919d5g12e41a54c600c2bf@mail.gmail.com>

Oh, and what your platform is.

-HKS

On Fri, Sep 5, 2008 at 10:55 AM, (private) HKS <hks.private at gmail.com> wrote:
> Can you paste in your full rsyslog.conf? It's difficult to
> troubleshoot without knowing how you're setup.
>
> -HKS
>
> On Fri, Sep 5, 2008 at 10:03 AM, Jorge F?bregas
> <jorge.fabregas at gmail.com> wrote:
>> Hello everyone,
>>
>> I'm using rsyslog for the first time and before getting into its features I'm
>> doing some basic tests... This is a portion of what I have on my rsyslog.conf:
>>
>> #KERN FACILITY
>> kern.=emerg     /var/log/syslog/kern/00-emerg
>> kern.=alert     /var/log/syslog/kern/01-alert
>> kern.=crit      /var/log/syslog/kern/02-crit
>> kern.=err       /var/log/syslog/kern/03-err
>> kern.=warning   /var/log/syslog/kern/04-warning
>> kern.=notice    /var/log/syslog/kern/05-notice
>> kern.=info      /var/log/syslog/kern/06-info
>> kern.=debug     /var/log/syslog/kern/07-debug
>>
>> If I do any test with the logger command using the kern facility (and any
>> severity) I don't see my message on any of the above files. Example:
>>
>> logger -p kern.debug "this is a test"
>>
>> I tried all the other facilities and they all work fine. It's just the kern
>> facility.
>>
>> What am I missing ?  :)
>>
>> Thanks in advance,
>> Jorge
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>
>


From satoru.satoh at gmail.com  Fri Sep  5 17:28:18 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Sat, 6 Sep 2008 00:28:18 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <1220623301.12304.61.camel@rgf9dev.intern.adiscon.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
	<1220623301.12304.61.camel@rgf9dev.intern.adiscon.com>
Message-ID: <20080905152813.GA9242@localhost.localdomain>

Hi,

On Fri, Sep 05, 2008 at 04:01:41PM +0200, Rainer Gerhards wrote:
> First of all, there seems to be a minor nit with the current set of
> files. Please have a look at what happens here:
> 
> --------------------------------
> [root at rgf9dev rsyslog]# xml2po -v
> 0.12.2
> [root at rgf9dev rsyslog]# make -C man/ja create-pot
> make: Entering directory `/home/rger/proj/rsyslog/man/ja'
> /usr/bin/xml2po -e -o rsyslogd.8.pot ../C/rsyslogd.8.xml
(snip)
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
> 4930: ordinal not in range(128)
> make: *** [rsyslogd.8.pot] Error 1
> make: Leaving directory `/home/rger/proj/rsyslog/man/ja'
> ----------------------------------
> Do you have an idea how I can find out what exactly to fix (I think I
> understand that there is in invalid character in rsyslogd.8.xml, but the
> error message is not very helpful at pointing me at the actual trouble
> source ;)).
 
This is an well-known annoying issue of python. 'ascii' is the default
internal encoding so that this happens.

There are many ways to "fix" this but to upgrade the latest
gnome-doc-utils (0.13.1; this problem is solved already), looks the
best.

> >From an upper level view, I now understand the workflow as follows:
> 
> When I update the documentation, I update the files in ./man/C. These
> are kept in docbook format and these are the only sources for the
> English language documentation.
> 
> After I have updated these files, every translator needs to run 
> 
> $ make -C man/<lang> update-po
> 
> to update the PO files. The translators will work on the .po files only.

correct if [s]he or other made the required files (PO) already.

> When they are (sufficiently ;)) finished, the man files need to be
> regenerated. Let me elaborate a bit on this process, I'd like to get to
> some details.
> 
> As far as I understand, this results in the .po files being converted
> back to docbook. Then, docbook is used to generate the ultimate
> destination, e.g. the man files. The same process is used to generate
> the English files, except that the docbook tools are run directly,
> because there were no interim .po files.

exactly. DocBook XML files just play an intermediate format role 
  
  a. to generate man pages (result)
  b. to generate POT (and PO indirectly) to facilitate translation

> Is this description correct? I am asking because I think it would make
> sense to generate different formats (man, html, pdf at least) from the
> same set of source files. So I understand that .po is just an interim
> step which makes translation easier, but there will be a translated
> version which in turn can be processed into any format that docbook
> tools support.

absolutely correct.

> I'd greatly appreciate your feedback. If you know how to do it, I would
> also greatly appreciate if you could provide me a patch (or
> instructions) on how to generate pdf from the "man files".
(snip)

OK, I'll try to make it. wait for a while, please.

Unfortunatelly, xml to pdf transformation process is much complicate
than html/man/other text based formats and it brings another
dependencies - fonts and XSL-FO processor :-P

- satoru


From satoru.satoh at gmail.com  Fri Sep  5 17:59:35 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Sat, 6 Sep 2008 00:59:35 +0900
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>
References: <20080820170735.GB20932@localhost.localdomain>
	<1220521960.12304.15.camel@rgf9dev.intern.adiscon.com>
	<20080904203155.GA6912@localhost.localdomain>
	<1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>
Message-ID: <20080905155931.GB9242@localhost.localdomain>

On Fri, Sep 05, 2008 at 10:42:03AM +0200, Rainer Gerhards wrote:
> > I thought that not all of developers have such system and so that this
> > should be avoided. This is why I disabled man-regeneration process by
> > default.
> 
> I agree that this may be a problem. However, I don't think it is a very
> serious one. I myself have contributed to some projects where I could
> not build the documentation. This did not cause any trouble to me while
> working at the program sources. Of course, if I would like to create a
> full tarball, I need to have everything in place. But only few actually
> needs this (am I right here?).

right. Who needs required tools and files are

 a. developers do git-pull *and* modify man sources
 b. translators contribute initial translation or update it
 c. others just want ;-) to switch on '--enable-regenerate-man' option

> In contrast, the tarball must include the generated mans, as the average
> user can not be expected to have the tools at hand (while we still
> expect him to have everything at hand necessary to compile the program
> sources).
(snip)
 
This should be accomplished already, I think.

I made all related stuff (xml, po, man) in EXTRA_DIST so that these will
be in the archive generated by 'make dist'. 

> > Actually, man files generated from docbook xml files are slightly
> > different from original man files ATM. These need some refactoring.
> 
> Could you please elaborate a bit on this? Does that mean that the
> generated man files (after doing a "make") can not be immediately be
> used and need some kind of (manual?) post-processing?
 
No. There should be no any problems to convert xml files to man pages
but the result *looks* may different.

Transition from man (roff) to DocBook XML is similar to the transition
from old HTML to XHTML + CSS. The authors/editors/writers have to
concentrate attention at the *logical* structure of the text instead of
its appearance.

It's typical that many HTML tags to control appearance found in old HTML
sources and it makes impossible to keep complete same look in new XHTML
+ CSS sources.

- satoru


From rgerhards at hq.adiscon.com  Mon Sep  8 10:24:56 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 8 Sep 2008 10:24:56 +0200
Subject: [rsyslog] [PATCH] man-i18n patches summary
In-Reply-To: <20080905155931.GB9242@localhost.localdomain>
References: <20080820170735.GB20932@localhost.localdomain><1220521960.12304.15.camel@rgf9dev.intern.adiscon.com><20080904203155.GA6912@localhost.localdomain><1220604123.12304.51.camel@rgf9dev.intern.adiscon.com>
	<20080905155931.GB9242@localhost.localdomain>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F0E6@grfint2.intern.adiscon.com>

Hi,

thanks again for your insight. I'll now remove the (generated) man files
from git, but will leave them inside the tarball. I think that is a
workable solution.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Satoru SATOH
> Sent: Friday, September 05, 2008 6:00 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] [PATCH] man-i18n patches summary
> 
> On Fri, Sep 05, 2008 at 10:42:03AM +0200, Rainer Gerhards wrote:
> > > I thought that not all of developers have such system and so that
> this
> > > should be avoided. This is why I disabled man-regeneration process
> by
> > > default.
> >
> > I agree that this may be a problem. However, I don't think it is a
> very
> > serious one. I myself have contributed to some projects where I
could
> > not build the documentation. This did not cause any trouble to me
> while
> > working at the program sources. Of course, if I would like to create
> a
> > full tarball, I need to have everything in place. But only few
> actually
> > needs this (am I right here?).
> 
> right. Who needs required tools and files are
> 
>  a. developers do git-pull *and* modify man sources
>  b. translators contribute initial translation or update it
>  c. others just want ;-) to switch on '--enable-regenerate-man' option
> 
> > In contrast, the tarball must include the generated mans, as the
> average
> > user can not be expected to have the tools at hand (while we still
> > expect him to have everything at hand necessary to compile the
> program
> > sources).
> (snip)
> 
> This should be accomplished already, I think.
> 
> I made all related stuff (xml, po, man) in EXTRA_DIST so that these
> will
> be in the archive generated by 'make dist'.
> 
> > > Actually, man files generated from docbook xml files are slightly
> > > different from original man files ATM. These need some
refactoring.
> >
> > Could you please elaborate a bit on this? Does that mean that the
> > generated man files (after doing a "make") can not be immediately be
> > used and need some kind of (manual?) post-processing?
> 
> No. There should be no any problems to convert xml files to man pages
> but the result *looks* may different.
> 
> Transition from man (roff) to DocBook XML is similar to the transition
> from old HTML to XHTML + CSS. The authors/editors/writers have to
> concentrate attention at the *logical* structure of the text instead
of
> its appearance.
> 
> It's typical that many HTML tags to control appearance found in old
> HTML
> sources and it makes impossible to keep complete same look in new
XHTML
> + CSS sources.
> 
> - satoru
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Thu Sep 11 15:27:49 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 11 Sep 2008 15:27:49 +0200
Subject: [rsyslog] docbook and math
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F12B@grfint2.intern.adiscon.com>

Hi folks,

and especially those that are proficient with docbook ;) I have one
question. I am thinking about a series of design papers. I think,
however, that at least some of them will require a lot of mathematical
formulas. Typically, I'd say that should be done in LaTeX. But with
moving to docbook for the user doc, it may be good to use a single
system.

I have now investigated docbook and maths a bit, but what I found didn't
look very promising. The best I found was MathML, which is far too
verbose for any hand-editing (and I don't want to rely on specialized
formula editors). I also found some references to embedded TeX, but that
looked quite hackish.

Could somebody enlighten me on the current typical approach for such
papers? Do they still usually go the LaTeX way or is there a good way to
do it with docbook?

Many thanks in advance,
Rainer


From david at lang.hm  Mon Sep 15 07:30:15 2008
From: david at lang.hm (david at lang.hm)
Date: Sun, 14 Sep 2008 22:30:15 -0700 (PDT)
Subject: [rsyslog] making a custom input module
Message-ID: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>

my second project is to try and modify rsyslog to recieve logs from an 
application. the application sends the logs over TCP and expects an 
application-level handshake (very similar to relp). at the moment I want 
to try and avoid having to change the application (many different products 
with different release schedules), and instead teach rsyslog to deal with 
the existing log format.

at the moment I am trying to understand the imtcp module, but I am getting 
lost in the callbacks. it looks like rsyslog is calling a routine in 
imtcp, which calls a routine in tcpsrv, which calls a routine somewhere 
else to actually recieve the log.

ideally what I would like to use is to take imtcp and replace the message 
recieving/parsing logic with my own, then have it submit the parsed 
message into the queue (which looks like it would be via the SubmitMsg() 
call).

but at the moment I am lost in the twisty maze of function calls between 
source files, all of which look different.

I'm also not clear on what fields inside of the Msg structure need to be 
populated. looking at Msg.c/h I see a lot of fields there, but it looks 
like many/most of them are optional.

any pointers?

David Lang


From david at lang.hm  Mon Sep 15 07:23:11 2008
From: david at lang.hm (david at lang.hm)
Date: Sun, 14 Sep 2008 22:23:11 -0700 (PDT)
Subject: [rsyslog] optimization questions
Message-ID: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>

I've got a couple projects I'm working on that rsyslog is looking like a 
good answer to. I'm going to send questions about them in seperate 
messages.

the first project is a traditional syslog server. I've been testing 
various syslog implementations to find out what sort of performance they 
can sustain.

I've gotten the (almost) standard sysklogd to sustail almost 30,000 
messages/sec (udp) before it starts loosing significant numbers of logs

rsyslog is able to handle bursts of around 150,000 messages/sec, but it 
doesn't seem to write them out very fast, and over time seems to be 
limited to ~22,000 messages/sec

the hardware I am running this test on is insanely overpowered (four 
dual-core opterons, 16G of ram, battery-backed cache on a raid card with 
high-speed SAS drives). in production I will be working with slower 
hardware, but I'm trying to find the limits of the software before I start 
introducing lower hardware limits.

what can I look at doing to speed up the writing of data from the queues? 
does rsyslog write the messages one at a time, or does it have an option 
for writing them in batches (pulling a bunch off of the queue and sending 
them all at once)?

some sort of batch mode would be critical for writes to a database where 
you can frequently get 1000x speedups if you do the inserts as a single 
transaction as opposed to individual transactions.

David Lang


From david at lang.hm  Mon Sep 15 08:13:43 2008
From: david at lang.hm (david at lang.hm)
Date: Sun, 14 Sep 2008 23:13:43 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
Message-ID: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>

looking through the rsyslog.conf man page I see ways to tell rsyslogd to 
run a command when a file is over a given size, but I see no examples or 
details of what that command can/should do.

what I want to do is to move the file out of the way, kick rsyslogd so 
that it starts writing to a new file, then compress the old file (which 
can take a significant amount of time)

traditionally I have rotated syslogs by doing a mv of the logfile followed 
by a kill -HUP of the syslog process (usually out of crontab)

In my testing of rsyslog I have been doing this, but once in a while 
rsyslog doesn't release the file it's writing and start a new one, instead 
it keeps writing to the old file.

so this means that my command can't spawn a background task that does a mv 
of the file followed by a kill -HUP of rsyslogd.

what should I be doing?

David Lang



From rgerhards at hq.adiscon.com  Mon Sep 15 08:39:24 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 08:39:24 +0200
Subject: [rsyslog] optimization questions
In-Reply-To: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>
Message-ID: <1221460764.2682.9.camel@rgf9dev.intern.adiscon.com>

Hi David,

thanks for your message and interest. This is very welcome as I would
really like to get hold of more insight into rsyslog's performance in
real-world and extreme scenarios. So far, I have unfortunately been
unable to do that, because I had no funding for the required hardware
and time to conduct the testing. I would *really* appreciate if you
could help with that and I would be very willing to tweak the code for
optimum performance (actually, I am always very concerned about high
performance and I was a bit sad about the fact that I could not ensure
it).

Having said that, I'd first of all would like to have a look at your
rsyslog.conf, so that we are on common ground. Also, I think, this can
become quite lengthy and also of interest for others. May it be useful
to discuss this on the web forum, so that we can easier keep track of
things. If you think this is useful, I recommend this one here:

http://kb.monitorware.com/general-f34.html

some more comments inline:

On Mon, 2008-09-15 at 07:23 +0200, david at lang.hm wrote:
> I've got a couple projects I'm working on that rsyslog is looking like
> a
> good answer to. I'm going to send questions about them in seperate
> messages.
> 
> the first project is a traditional syslog server. I've been testing
> various syslog implementations to find out what sort of performance
> they
> can sustain.
> 
> I've gotten the (almost) standard sysklogd to sustail almost 30,000
> messages/sec (udp) before it starts loosing significant numbers of
> logs
> 
> rsyslog is able to handle bursts of around 150,000 messages/sec, but
> it
> doesn't seem to write them out very fast, and over time seems to be
> limited to ~22,000 messages/sec
> 
> the hardware I am running this test on is insanely overpowered (four
> dual-core opterons, 16G of ram, battery-backed cache on a raid card
> with
> high-speed SAS drives). in production I will be working with slower
> hardware, but I'm trying to find the limits of the software before I
> start
> introducing lower hardware limits.
> 
> what can I look at doing to speed up the writing of data from the
> queues?
> does rsyslog write the messages one at a time, or does it have an
> option
> for writing them in batches (pulling a bunch off of the queue and
> sending
> them all at once)?

The design is that each individual message is pushed to the output. The
output than writes the message. There has been discussion about a lazy
write, but nothing in this regard has yet been implemented.

Note that this is a good time to request new things. I am finished with
the last major thing (TLS) support and in front of the next one
(enhanced scripting), but scripting, I think, could be moved to a later
time in favour of something more important (like performance ;)).
> 
> some sort of batch mode would be critical for writes to a database
> where
> you can frequently get 1000x speedups if you do the inserts as a
> single
> transaction as opposed to individual transactions.

I am not (any longer) so much a database guy. Can I really do a batch
insert with them? Can you point me to an API?

Looking forward to your reply!
Rainer




From rgerhards at hq.adiscon.com  Mon Sep 15 08:47:13 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 08:47:13 +0200
Subject: [rsyslog] making a custom input module
In-Reply-To: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
Message-ID: <1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>

On Sun, 2008-09-14 at 22:30 -0700, david at lang.hm wrote:
> my second project is to try and modify rsyslog to recieve logs from an 
> application. the application sends the logs over TCP and expects an 
> application-level handshake (very similar to relp). at the moment I want 
> to try and avoid having to change the application (many different products 
> with different release schedules), and instead teach rsyslog to deal with 
> the existing log format.
> 
> at the moment I am trying to understand the imtcp module, but I am getting 
> lost in the callbacks. it looks like rsyslog is calling a routine in 
> imtcp, which calls a routine in tcpsrv, which calls a routine somewhere 
> else to actually recieve the log.

The imtcp module has a lot of history and too complex code. This all
stems back to various stages of GSSAPI integration. Things have been
simplified with the introduction of the transport stream layer, but the
imtcp module does not yet reflect this simplicity. So far, I am hesitant
to split these things, because we still do not have a clean gssapi
netstream driver.

I can tell you where you need to provide callbacks ... or you could
start from imrelp, which in regard means mostly from scratch, but
actually receiving tcp isn't rocket science, so it may be easier to
start with a proper template without tcp functionality and integrate
your tcp reception code into it. What do you (think ;)) you prefer?

> ideally what I would like to use is to take imtcp and replace the message 
> recieving/parsing logic with my own, then have it submit the parsed 
> message into the queue (which looks like it would be via the SubmitMsg() 
> call).
> 
> but at the moment I am lost in the twisty maze of function calls between 
> source files, all of which look different.
> 
> I'm also not clear on what fields inside of the Msg structure need to be 
> populated. looking at Msg.c/h I see a lot of fields there, but it looks 
> like many/most of them are optional.

look at imfile. This is what you need:

	CHKiRet(msgConstruct(&pMsg));
	MsgSetFlowControlType(pMsg, eFLOWCTL_FULL_DELAY);
	MsgSetInputName(pMsg, "imfile");
	MsgSetUxTradMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
	MsgSetRawMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
	MsgSetMSG(pMsg, (char*)rsCStrGetSzStr(cstrLine));
	MsgSetHOSTNAME(pMsg, (char*)glbl.GetLocalHostName());
	MsgSetTAG(pMsg, (char*)pInfo->pszTag);
	pMsg->iFacility = LOG_FAC(pInfo->iFacility);
	pMsg->iSeverity = LOG_PRI(pInfo->iSeverity);
	pMsg->bParseHOSTNAME = 0;
	datetime.getCurrTime(&(pMsg->tTIMESTAMP)); /* use the current time! */
	CHKiRet(submitMsg(pMsg))

Also look at imtemplate, which is a template input module. Sometimes it
is a bit outdated, if you have a problem during compile, tell me ;)

Rainer
> 
> any pointers?
> 
> David Lang
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep 15 08:54:59 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 08:54:59 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
Message-ID: <1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>

This, too, is quite old, to-be-replaced on demand functionality ...
without any demand for replacement up to now ;)

Do you know this guide:
http://www.rsyslog.com/doc-log_rotation_fix_size.html

The shell script could spawn off an async process, but I have never
tried this...

Also <inline>:
On Sun, 2008-09-14 at 23:13 -0700, david at lang.hm wrote:
> looking through the rsyslog.conf man page I see ways to tell rsyslogd to 
> run a command when a file is over a given size, but I see no examples or 
> details of what that command can/should do.
> 
> what I want to do is to move the file out of the way, kick rsyslogd so 
> that it starts writing to a new file, then compress the old file (which 
> can take a significant amount of time)
> 
> traditionally I have rotated syslogs by doing a mv of the logfile followed 
> by a kill -HUP of the syslog process (usually out of crontab)
> 
> In my testing of rsyslog I have been doing this, but once in a while 
> rsyslog doesn't release the file it's writing and start a new one, instead 
> it keeps writing to the old file.

This very much smells like a bug. Can you elaborate on what you did?

> 
> so this means that my command can't spawn a background task that does a mv 
> of the file followed by a kill -HUP of rsyslogd.
> 
> what should I be doing?
> 
> David Lang
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From david at lang.hm  Mon Sep 15 09:01:40 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:01:40 -0700 (PDT)
Subject: [rsyslog] optimization questions
In-Reply-To: <1221460764.2682.9.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142216120.19489@asgard.lang.hm>
	<1221460764.2682.9.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150001160.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> Hi David,
>
> thanks for your message and interest. This is very welcome as I would
> really like to get hold of more insight into rsyslog's performance in
> real-world and extreme scenarios. So far, I have unfortunately been
> unable to do that, because I had no funding for the required hardware
> and time to conduct the testing. I would *really* appreciate if you
> could help with that and I would be very willing to tweak the code for
> optimum performance (actually, I am always very concerned about high
> performance and I was a bit sad about the fact that I could not ensure
> it).
>
> Having said that, I'd first of all would like to have a look at your
> rsyslog.conf, so that we are on common ground. Also, I think, this can
> become quite lengthy and also of interest for others. May it be useful
> to discuss this on the web forum, so that we can easier keep track of
> things. If you think this is useful, I recommend this one here:
>
> http://kb.monitorware.com/general-f34.html

done, I created a topic in the developers corner

David Lang

> some more comments inline:
>
> On Mon, 2008-09-15 at 07:23 +0200, david at lang.hm wrote:
>> I've got a couple projects I'm working on that rsyslog is looking like
>> a
>> good answer to. I'm going to send questions about them in seperate
>> messages.
>>
>> the first project is a traditional syslog server. I've been testing
>> various syslog implementations to find out what sort of performance
>> they
>> can sustain.
>>
>> I've gotten the (almost) standard sysklogd to sustail almost 30,000
>> messages/sec (udp) before it starts loosing significant numbers of
>> logs
>>
>> rsyslog is able to handle bursts of around 150,000 messages/sec, but
>> it
>> doesn't seem to write them out very fast, and over time seems to be
>> limited to ~22,000 messages/sec
>>
>> the hardware I am running this test on is insanely overpowered (four
>> dual-core opterons, 16G of ram, battery-backed cache on a raid card
>> with
>> high-speed SAS drives). in production I will be working with slower
>> hardware, but I'm trying to find the limits of the software before I
>> start
>> introducing lower hardware limits.
>>
>> what can I look at doing to speed up the writing of data from the
>> queues?
>> does rsyslog write the messages one at a time, or does it have an
>> option
>> for writing them in batches (pulling a bunch off of the queue and
>> sending
>> them all at once)?
>
> The design is that each individual message is pushed to the output. The
> output than writes the message. There has been discussion about a lazy
> write, but nothing in this regard has yet been implemented.
>
> Note that this is a good time to request new things. I am finished with
> the last major thing (TLS) support and in front of the next one
> (enhanced scripting), but scripting, I think, could be moved to a later
> time in favour of something more important (like performance ;)).
>>
>> some sort of batch mode would be critical for writes to a database
>> where
>> you can frequently get 1000x speedups if you do the inserts as a
>> single
>> transaction as opposed to individual transactions.
>
> I am not (any longer) so much a database guy. Can I really do a batch
> insert with them? Can you point me to an API?
>
> Looking forward to your reply!
> Rainer
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From david at lang.hm  Mon Sep 15 09:10:42 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:10:42 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> This, too, is quite old, to-be-replaced on demand functionality ...
> without any demand for replacement up to now ;)
>
> Do you know this guide:
> http://www.rsyslog.com/doc-log_rotation_fix_size.html
>
> The shell script could spawn off an async process, but I have never
> tried this...
>
> Also <inline>:
> On Sun, 2008-09-14 at 23:13 -0700, david at lang.hm wrote:
>> looking through the rsyslog.conf man page I see ways to tell rsyslogd to
>> run a command when a file is over a given size, but I see no examples or
>> details of what that command can/should do.
>>
>> what I want to do is to move the file out of the way, kick rsyslogd so
>> that it starts writing to a new file, then compress the old file (which
>> can take a significant amount of time)
>>
>> traditionally I have rotated syslogs by doing a mv of the logfile followed
>> by a kill -HUP of the syslog process (usually out of crontab)
>>
>> In my testing of rsyslog I have been doing this, but once in a while
>> rsyslog doesn't release the file it's writing and start a new one, instead
>> it keeps writing to the old file.
>
> This very much smells like a bug. Can you elaborate on what you did?

rsyslogd 3.18.3 on one machine with the config file

$ModLoad immark
$MarkMessagePeriod 1200
$ModLoad imuxsock
$ModLoad imudp
$ModLoad imklog
$UDPServerRun 514
$AllowedSender UDP, 127.0.0.1, 192.0.0.0/8
$umask 0000
$FileGroup root
$FileOwner root
$template TraditionalFormat,"%timegenerated% %HOSTNAME% 
%syslogtag%%msg:::drop-last-lf%\n"
*.*     /var/log/messages;TraditionalFormat      # log to a file in the 
traditional format

tcpreplay on a second machine spewing log entries at it at a rate of 
~30,000 logs/sec

crontab running the following script every 5 min

#!/bin/sh
#

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

umask 022
year=`date +%Y`
month=`date +%m`
day=`date +%d`
fdate=`date +%Y%m%d.%H%M`
logroot=/var/log
logroll=$logroot/oldlogs

cd $logroot
mkdir -p $logroll/$year/$month/$day >/dev/null 2>/dev/null
mv messages $logroll/$year/$month/$day/messages.$fdate
pkill -HUP rsyslogd
2>/dev/null &
gzip -9 $logroll/$year/$month/$day/messages.$fdate


I get a couple of rotations sucessfully (with ~22,000 logs/sec in the 
files), but then rsyslog seems to hang.
lsof show it with the file open that was moved (and later deleted by 
gzip).
I need to do a kill -9 of rsyslogd to get it to recover.

David Lang

>>
>> so this means that my command can't spawn a background task that does a mv
>> of the file followed by a kill -HUP of rsyslogd.
>>
>> what should I be doing?
>>
>> David Lang
>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Mon Sep 15 09:13:16 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:13:16 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
Message-ID: <1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:10 -0700, david at lang.hm wrote:
> > This very much smells like a bug. Can you elaborate on what you did?
> 
> rsyslogd 3.18.3 on one machine with the config file
> 
> $ModLoad immark
> $MarkMessagePeriod 1200
> $ModLoad imuxsock
> $ModLoad imudp
> $ModLoad imklog
> $UDPServerRun 514
> $AllowedSender UDP, 127.0.0.1, 192.0.0.0/8
> $umask 0000
> $FileGroup root
> $FileOwner root
> $template TraditionalFormat,"%timegenerated% %HOSTNAME% 
> %syslogtag%%msg:::drop-last-lf%\n"
> *.*     /var/log/messages;TraditionalFormat      # log to a file in the 
> traditional format
> 
> tcpreplay on a second machine spewing log entries at it at a rate of 
> ~30,000 logs/sec
> 
> crontab running the following script every 5 min
> 
> #!/bin/sh
> #
> 
> PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
> 
> umask 022
> year=`date +%Y`
> month=`date +%m`
> day=`date +%d`
> fdate=`date +%Y%m%d.%H%M`
> logroot=/var/log
> logroll=$logroot/oldlogs
> 
> cd $logroot
> mkdir -p $logroll/$year/$month/$day >/dev/null 2>/dev/null
> mv messages $logroll/$year/$month/$day/messages.$fdate
> pkill -HUP rsyslogd
> 2>/dev/null &
> gzip -9 $logroll/$year/$month/$day/messages.$fdate
> 
> 
> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the 
> files), but then rsyslog seems to hang.
> lsof show it with the file open that was moved (and later deleted by 
> gzip).
> I need to do a kill -9 of rsyslogd to get it to recover.

Definitely a bug... I now "just" need to find out where. I guess there
is some mutex issue in the queue engine during shutdown. Don't expect a
fix too soon, but I'll do my best. I hope I can find a simpler error
condition (if my conclusion on the problem source is right...)

Rainer



From david at lang.hm  Mon Sep 15 09:16:23 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:16:23 -0700 (PDT)
Subject: [rsyslog] making a custom input module
In-Reply-To: <1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
	<1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Sun, 2008-09-14 at 22:30 -0700, david at lang.hm wrote:
>> my second project is to try and modify rsyslog to recieve logs from an
>> application. the application sends the logs over TCP and expects an
>> application-level handshake (very similar to relp). at the moment I want
>> to try and avoid having to change the application (many different products
>> with different release schedules), and instead teach rsyslog to deal with
>> the existing log format.
>>
>> at the moment I am trying to understand the imtcp module, but I am getting
>> lost in the callbacks. it looks like rsyslog is calling a routine in
>> imtcp, which calls a routine in tcpsrv, which calls a routine somewhere
>> else to actually recieve the log.
>
> The imtcp module has a lot of history and too complex code. This all
> stems back to various stages of GSSAPI integration. Things have been
> simplified with the introduction of the transport stream layer, but the
> imtcp module does not yet reflect this simplicity. So far, I am hesitant
> to split these things, because we still do not have a clean gssapi
> netstream driver.
>
> I can tell you where you need to provide callbacks ... or you could
> start from imrelp, which in regard means mostly from scratch, but
> actually receiving tcp isn't rocket science, so it may be easier to
> start with a proper template without tcp functionality and integrate
> your tcp reception code into it. What do you (think ;)) you prefer?

the simpler the better. I'm pretty rusty with my C and I never did much 
network or threaded programming in the first place, so while I can debug 
programs in any language, I'm currently not much beyond the cut-n-past 
stage here.

it sounds like I should not start from imtcp.

however when I looked at imrelp it looked like everything in in the relp 
libraries, and I was hoping to avoid diving into them for the moment.

are any of the other tcp-based transports in better shape? or should I 
start from scratch with the imtemplate plugin?

David Lang

>> ideally what I would like to use is to take imtcp and replace the message
>> recieving/parsing logic with my own, then have it submit the parsed
>> message into the queue (which looks like it would be via the SubmitMsg()
>> call).
>>
>> but at the moment I am lost in the twisty maze of function calls between
>> source files, all of which look different.
>>
>> I'm also not clear on what fields inside of the Msg structure need to be
>> populated. looking at Msg.c/h I see a lot of fields there, but it looks
>> like many/most of them are optional.
>
> look at imfile. This is what you need:
>
> 	CHKiRet(msgConstruct(&pMsg));
> 	MsgSetFlowControlType(pMsg, eFLOWCTL_FULL_DELAY);
> 	MsgSetInputName(pMsg, "imfile");
> 	MsgSetUxTradMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
> 	MsgSetRawMsg(pMsg, (char*)rsCStrGetSzStr(cstrLine));
> 	MsgSetMSG(pMsg, (char*)rsCStrGetSzStr(cstrLine));
> 	MsgSetHOSTNAME(pMsg, (char*)glbl.GetLocalHostName());
> 	MsgSetTAG(pMsg, (char*)pInfo->pszTag);
> 	pMsg->iFacility = LOG_FAC(pInfo->iFacility);
> 	pMsg->iSeverity = LOG_PRI(pInfo->iSeverity);
> 	pMsg->bParseHOSTNAME = 0;
> 	datetime.getCurrTime(&(pMsg->tTIMESTAMP)); /* use the current time! */
> 	CHKiRet(submitMsg(pMsg))
>
> Also look at imtemplate, which is a template input module. Sometimes it
> is a bit outdated, if you have a problem during compile, tell me ;)
>
> Rainer
>>
>> any pointers?
>>
>> David Lang
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From david at lang.hm  Mon Sep 15 09:17:47 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:17:47 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

>> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the
>> files), but then rsyslog seems to hang.
>> lsof show it with the file open that was moved (and later deleted by
>> gzip).
>> I need to do a kill -9 of rsyslogd to get it to recover.
>
> Definitely a bug... I now "just" need to find out where. I guess there
> is some mutex issue in the queue engine during shutdown. Don't expect a
> fix too soon, but I'll do my best. I hope I can find a simpler error
> condition (if my conclusion on the problem source is right...)

let me know if you need me to try anything. given the volume of logs I 
don't know if it would be worth trying to do a strace.

David Lang


From rgerhards at hq.adiscon.com  Mon Sep 15 09:19:43 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:19:43 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
Message-ID: <1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:17 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> >> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the
> >> files), but then rsyslog seems to hang.
> >> lsof show it with the file open that was moved (and later deleted by
> >> gzip).
> >> I need to do a kill -9 of rsyslogd to get it to recover.
> >
> > Definitely a bug... I now "just" need to find out where. I guess there
> > is some mutex issue in the queue engine during shutdown. Don't expect a
> > fix too soon, but I'll do my best. I hope I can find a simpler error
> > condition (if my conclusion on the problem source is right...)
> 
> let me know if you need me to try anything. given the volume of logs I 
> don't know if it would be worth trying to do a strace.

I agree, it doesn't make any sense. It may be worth trying to run
rsyslog with runtime instrumentation turned on in debug mode. That will
generate tons of debug output and it will make things awfully slow, but
at least we may be able to get some information out of it.

... well... one thing: could you run an unmodified version of WinSyslog
under valgrind and let me know if there are any valgrind exceptions
before it hangs? This, too, will make it very slow, but I guess/hope
that doesn't affect the outcome.

Rainer



From rgerhards at hq.adiscon.com  Mon Sep 15 09:20:57 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:20:57 +0200
Subject: [rsyslog] making a custom input module
In-Reply-To: <alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
	<1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>
Message-ID: <1221463257.2682.34.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:16 -0700, david at lang.hm wrote:
> the simpler the better. I'm pretty rusty with my C and I never did much 
> network or threaded programming in the first place, so while I can debug 
> programs in any language, I'm currently not much beyond the cut-n-past 
> stage here.
> 
> it sounds like I should not start from imtcp.
> 
> however when I looked at imrelp it looked like everything in in the relp 
> libraries, and I was hoping to avoid diving into them for the moment.
> 
> are any of the other tcp-based transports in better shape? or should I 
> start from scratch with the imtemplate plugin?

Bear a bit with me (but ping me if I don't reply by mid-week). I'll have
a look and recommend the way I think is best given the constraints.

Rainer



From david at lang.hm  Mon Sep 15 09:26:57 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:26:57 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:17 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>
>>>> I get a couple of rotations sucessfully (with ~22,000 logs/sec in the
>>>> files), but then rsyslog seems to hang.
>>>> lsof show it with the file open that was moved (and later deleted by
>>>> gzip).
>>>> I need to do a kill -9 of rsyslogd to get it to recover.
>>>
>>> Definitely a bug... I now "just" need to find out where. I guess there
>>> is some mutex issue in the queue engine during shutdown. Don't expect a
>>> fix too soon, but I'll do my best. I hope I can find a simpler error
>>> condition (if my conclusion on the problem source is right...)
>>
>> let me know if you need me to try anything. given the volume of logs I
>> don't know if it would be worth trying to do a strace.
>
> I agree, it doesn't make any sense. It may be worth trying to run
> rsyslog with runtime instrumentation turned on in debug mode. That will
> generate tons of debug output and it will make things awfully slow, but
> at least we may be able to get some information out of it.

do I need to recompile it, or is it a config/command line option?

> ... well... one thing: could you run an unmodified version of WinSyslog
> under valgrind and let me know if there are any valgrind exceptions
> before it hangs? This, too, will make it very slow, but I guess/hope
> that doesn't affect the outcome.

I'm running on linux machines, so I don't know if WinSyslog can be made to 
work. I would need to be pointed at the source.

David Lang


From david at lang.hm  Mon Sep 15 09:27:47 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:27:47 -0700 (PDT)
Subject: [rsyslog] making a custom input module
In-Reply-To: <1221463257.2682.34.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142223130.19489@asgard.lang.hm>
	<1221461233.2682.17.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150012510.19489@asgard.lang.hm>
	<1221463257.2682.34.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150027110.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:16 -0700, david at lang.hm wrote:
>> the simpler the better. I'm pretty rusty with my C and I never did much
>> network or threaded programming in the first place, so while I can debug
>> programs in any language, I'm currently not much beyond the cut-n-past
>> stage here.
>>
>> it sounds like I should not start from imtcp.
>>
>> however when I looked at imrelp it looked like everything in in the relp
>> libraries, and I was hoping to avoid diving into them for the moment.
>>
>> are any of the other tcp-based transports in better shape? or should I
>> start from scratch with the imtemplate plugin?
>
> Bear a bit with me (but ping me if I don't reply by mid-week). I'll have
> a look and recommend the way I think is best given the constraints.

Ok, in the meantime I'll forget about trying to untangle imtcp and see 
what I can do seperatly.

David Lang


From rgerhards at hq.adiscon.com  Mon Sep 15 09:28:04 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:28:04 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
Message-ID: <1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:26 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> > I agree, it doesn't make any sense. It may be worth trying to run
> > rsyslog with runtime instrumentation turned on in debug mode. That will
> > generate tons of debug output and it will make things awfully slow, but
> > at least we may be able to get some information out of it.
> 
> do I need to recompile it, or is it a config/command line option?

you need to compile it, but let's do the valgrind test first (less
effort required).
> 
> > ... well... one thing: could you run an unmodified version of WinSyslog
> > under valgrind and let me know if there are any valgrind exceptions
> > before it hangs? This, too, will make it very slow, but I guess/hope
> > that doesn't affect the outcome.
> 
> I'm running on linux machines, so I don't know if WinSyslog can be made to 
> work. I would need to be pointed at the source.

lol - that happens if you have two conversations open at one time ;) Actually, I meant rsyslog. Forget about the WinSyslog part ;)

Rainer



From david at lang.hm  Mon Sep 15 09:34:17 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:34:17 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:26 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>
>>> I agree, it doesn't make any sense. It may be worth trying to run
>>> rsyslog with runtime instrumentation turned on in debug mode. That will
>>> generate tons of debug output and it will make things awfully slow, but
>>> at least we may be able to get some information out of it.
>>
>> do I need to recompile it, or is it a config/command line option?
>
> you need to compile it, but let's do the valgrind test first (less
> effort required).
>>
>>> ... well... one thing: could you run an unmodified version of WinSyslog
>>> under valgrind and let me know if there are any valgrind exceptions
>>> before it hangs? This, too, will make it very slow, but I guess/hope
>>> that doesn't affect the outcome.
>>
>> I'm running on linux machines, so I don't know if WinSyslog can be made to
>> work. I would need to be pointed at the source.
>
> lol - that happens if you have two conversations open at one time ;) Actually, I meant rsyslog. Forget about the WinSyslog part ;)

ok, I've never run vagrind, let me see what I can find.

David Lang


From rgerhards at hq.adiscon.com  Mon Sep 15 09:37:20 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 09:37:20 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
Message-ID: <1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:34 -0700, david at lang.hm wrote:
> ok, I've never run vagrind, let me see what I can find.

It's far easier than I thought when I used valgrind for the first time:
simply install a recent release and start rsyslog as usual, just add
"valgrind" before rsyslog (so valgrind is the command and rsyslog an
arguement". e.g.

$ ./rsyslogd -c3

becomes

$ valgrind ./rsyslogd -c3

That's it! :-)

There are a couple of options for valgrind, but for starters the defaults are fine.

Rainer



From david at lang.hm  Mon Sep 15 09:53:41 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 00:53:41 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> Date: Mon, 15 Sep 2008 09:37:20 +0200
> From: Rainer Gerhards <rgerhards at hq.adiscon.com>
> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
> To: rsyslog-users <rsyslog at lists.adiscon.com>
> Subject: Re: [rsyslog] how to best rotate files
> 
> On Mon, 2008-09-15 at 00:34 -0700, david at lang.hm wrote:
>> ok, I've never run vagrind, let me see what I can find.
>
> It's far easier than I thought when I used valgrind for the first time:
> simply install a recent release and start rsyslog as usual, just add
> "valgrind" before rsyslog (so valgrind is the command and rsyslog an
> arguement". e.g.
>
> $ ./rsyslogd -c3
>
> becomes
>
> $ valgrind ./rsyslogd -c3
>
> That's it! :-)
>
> There are a couple of options for valgrind, but for starters the defaults are fine.

I did --trace-children=yes (otherwise it wouldn't stay attached) and 
--leak-detail=yes (since it seemed to report memory leaks in the first 
run)

this seemed to run into problems with the first rotation (which given that 
there was no process to do a kill -HUP on, isn't surprising)

David Lang

==10726== Memcheck, a memory error detector.
==10726== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==10726== Using LibVEX rev 1658, a library for dynamic binary translation.
==10726== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==10726== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.
==10726== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==10726== For more details, rerun with: -v
==10726==
==10726== My PID = 10726, parent PID = 13696.  Prog and args are:
==10726==    /usr/local/sbin/rsyslogd
==10726==    -c3
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x40091D5: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x40091DE: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010B04: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010C61: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006E47: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Invalid read of size 8
==10726==    at 0x4010C54: (within /lib/ld-2.3.6.so)
==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10726==    by 0x4007113: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010A70: (within /lib/ld-2.3.6.so)
==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006117: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Conditional jump or move depends on uninitialised value(s)
==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10726==    by 0x4008B91: (within /lib/ld-2.3.6.so)
==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== Invalid read of size 8
==10726==    at 0x4010C20: (within /lib/ld-2.3.6.so)
==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10726==    by 0x4006123: (within /lib/ld-2.3.6.so)
==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10726==
==10726== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
==10726== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
==10726== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
==10726== For counts of detected errors, rerun with: -v
==10726== searching for pointers to 437 not-freed blocks.
==10726== checked 172,368 bytes.
==10726==
==10726== LEAK SUMMARY:
==10726==    definitely lost: 0 bytes in 0 blocks.
==10726==      possibly lost: 0 bytes in 0 blocks.
==10726==    still reachable: 24,090 bytes in 437 blocks.
==10726==         suppressed: 0 bytes in 0 blocks.
==10726== Reachable blocks (those to which a pointer was found) are not 
shown.
==10726== To see them, rerun with: --show-reachable=yes




==10730== Memcheck, a memory error detector.
==10730== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==10730== Using LibVEX rev 1658, a library for dynamic binary translation.
==10730== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==10730== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.
==10730== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==10730== For more details, rerun with: -v
==10730==
==10730== My PID = 10730, parent PID = 13696.  Prog and args are:
==10730==    /usr/local/sbin/rsyslogd
==10730==    -c3
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x40091D5: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x40091DE: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010B04: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010C61: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006E47: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Invalid read of size 8
==10730==    at 0x4010C54: (within /lib/ld-2.3.6.so)
==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10730==    by 0x4007113: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010A70: (within /lib/ld-2.3.6.so)
==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006117: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Conditional jump or move depends on uninitialised value(s)
==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
==10730==    by 0x4008B91: (within /lib/ld-2.3.6.so)
==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==
==10730== Invalid read of size 8
==10730==    at 0x4010C20: (within /lib/ld-2.3.6.so)
==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10730==    by 0x4006123: (within /lib/ld-2.3.6.so)
==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
==10731== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
hints
==10731==    This could cause spurious value errors to appear.
==10731==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
proper wrapper.
==10731==
==10731== Conditional jump or move depends on uninitialised value(s)
==10731==    at 0x4009442: (within /lib/ld-2.3.6.so)
==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==
==10731== Conditional jump or move depends on uninitialised value(s)
==10731==    at 0x4009339: (within /lib/ld-2.3.6.so)
==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==
==10731== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)
==10731==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
==10731==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
==10731==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
==10731==    by 0x4145F1: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
==10731==    by 0x5295B57: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)
==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
==10731==  Address 0x7FEFFB401 is on thread 1's stack
==10730==
==10730== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
==10730== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
==10730== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
==10730== For counts of detected errors, rerun with: -v
==10730== searching for pointers to 437 not-freed blocks.
==10730== checked 173,712 bytes.
==10730==
==10730== LEAK SUMMARY:
==10730==    definitely lost: 0 bytes in 0 blocks.
==10730==      possibly lost: 0 bytes in 0 blocks.
==10730==    still reachable: 24,090 bytes in 437 blocks.
==10730==         suppressed: 0 bytes in 0 blocks.
==10730== Reachable blocks (those to which a pointer was found) are not 
shown.
==10730== To see them, rerun with: --show-reachable=yes
==10731==
==10731== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from 
1)
==10731== malloc/free: in use at exit: 13,231 bytes in 85 blocks.
==10731== malloc/free: 3,058,176 allocs, 3,058,091 frees, 619,413,167 
bytes allocated.
==10731== For counts of detected errors, rerun with: -v
==10731== searching for pointers to 85 not-freed blocks.
==10731== checked 33,675,000 bytes.
==10731==
==10731==
==10731== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely 
lost in loss record 9 of 25
==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
==10731==    by 0x5295A31: ???
==10731==    by 0x5295C3C: ???
==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
==10731==
==10731==
==10731== 584 (104 direct, 480 indirect) bytes in 2 blocks are definitely 
lost in loss record 13 of 25
==10731==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==10731==    by 0x502F63F: (within /lib/libc-2.3.6.so)
==10731==    by 0x502FD95: __nss_database_lookup (in /lib/libc-2.3.6.so)
==10731==    by 0x59B373F: ???
==10731==    by 0x59B4532: ???
==10731==    by 0x4FE5BF4: getgrnam_r (in /lib/libc-2.3.6.so)
==10731==    by 0x4272C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x426A48: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
==10731==
==10731==
==10731== 544 bytes in 4 blocks are possibly lost in loss record 20 of 25
==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
==10731==    by 0x400EA3D: _dl_allocate_tls (in /lib/ld-2.3.6.so)
==10731==    by 0x4C3B500: pthread_create@@GLIBC_2.2.5 (in 
/lib/libpthread-2.3.6.so)
==10731==    by 0x41690E: wtpAdviseMaxWorkers (in 
/usr/local/sbin/rsyslogd)
==10731==    by 0x41A4EF: queueStart (in /usr/local/sbin/rsyslogd)
==10731==    by 0x40B5BC: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
==10731==
==10731==
==10731== 1,420 (928 direct, 492 indirect) bytes in 2 blocks are 
definitely lost in loss record 23 of 25
==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
==10731==    by 0x41F13F: msgConstruct (in /usr/local/sbin/rsyslogd)
==10731==    by 0x40ABA9: logmsgInternal (in /usr/local/sbin/rsyslogd)
==10731==    by 0x40BEC9: (within /usr/local/sbin/rsyslogd)
==10731==    by 0x40C07A: realMain (in /usr/local/sbin/rsyslogd)
==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
==10731==
==10731== LEAK SUMMARY:
==10731==    definitely lost: 1,064 bytes in 5 blocks.
==10731==    indirectly lost: 1,036 bytes in 34 blocks.
==10731==      possibly lost: 544 bytes in 4 blocks.
==10731==    still reachable: 10,587 bytes in 42 blocks.
==10731==         suppressed: 0 bytes in 0 blocks.
==10731== Reachable blocks (those to which a pointer was found) are not 
shown.
==10731== To see them, rerun with: --show-reachable=yes



From rgerhards at hq.adiscon.com  Mon Sep 15 10:23:51 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 10:23:51 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
Message-ID: <1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 00:53 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> I did --trace-children=yes (otherwise it wouldn't stay attached) and 
> --leak-detail=yes (since it seemed to report memory leaks in the first 
> run)

Well, I am actually not so much interested in what the forked processes
do. They have "memory leaks", but these "leaks" stem from process
duplication and are cleaned up by the OS when the forked process
terminates. Cleaning them up oneself creates unnecessary CPU, as the OS
does it much more efficient. Also, the hang is related to the parent
process. Thus, I'd actually pefer --trace-children=no ;)

I also notice that it would be of advantage to do a compile with

./configure --enable-debug --enable-valgrind

as this leads to better debug trace information. But the parent trace is most interesting first (if there is anything reported from valgrind).

Rainer

> 
> this seemed to run into problems with the first rotation (which given that 
> there was no process to do a kill -HUP on, isn't surprising)
> 
> David Lang
> 
> ==10726== Memcheck, a memory error detector.
> ==10726== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> ==10726== Using LibVEX rev 1658, a library for dynamic binary translation.
> ==10726== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> ==10726== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
> framework.
> ==10726== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> ==10726== For more details, rerun with: -v
> ==10726==
> ==10726== My PID = 10726, parent PID = 13696.  Prog and args are:
> ==10726==    /usr/local/sbin/rsyslogd
> ==10726==    -c3
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x40091D5: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x40091DE: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010B04: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010C61: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006E47: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Invalid read of size 8
> ==10726==    at 0x4010C54: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10726==    by 0x4007113: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010A70: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006117: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Conditional jump or move depends on uninitialised value(s)
> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4008B91: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== Invalid read of size 8
> ==10726==    at 0x4010C20: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10726==    by 0x4006123: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10726==
> ==10726== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
> ==10726== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
> ==10726== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
> ==10726== For counts of detected errors, rerun with: -v
> ==10726== searching for pointers to 437 not-freed blocks.
> ==10726== checked 172,368 bytes.
> ==10726==
> ==10726== LEAK SUMMARY:
> ==10726==    definitely lost: 0 bytes in 0 blocks.
> ==10726==      possibly lost: 0 bytes in 0 blocks.
> ==10726==    still reachable: 24,090 bytes in 437 blocks.
> ==10726==         suppressed: 0 bytes in 0 blocks.
> ==10726== Reachable blocks (those to which a pointer was found) are not 
> shown.
> ==10726== To see them, rerun with: --show-reachable=yes
> 
> 
> 
> 
> ==10730== Memcheck, a memory error detector.
> ==10730== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> ==10730== Using LibVEX rev 1658, a library for dynamic binary translation.
> ==10730== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> ==10730== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
> framework.
> ==10730== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> ==10730== For more details, rerun with: -v
> ==10730==
> ==10730== My PID = 10730, parent PID = 13696.  Prog and args are:
> ==10730==    /usr/local/sbin/rsyslogd
> ==10730==    -c3
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x40091D5: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x40091DE: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010B04: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010C61: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006E47: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Invalid read of size 8
> ==10730==    at 0x4010C54: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10730==    by 0x4007113: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010A70: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006117: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Conditional jump or move depends on uninitialised value(s)
> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4008B91: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==
> ==10730== Invalid read of size 8
> ==10730==    at 0x4010C20: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10730==    by 0x4006123: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
> ==10731== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
> hints
> ==10731==    This could cause spurious value errors to appear.
> ==10731==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
> proper wrapper.
> ==10731==
> ==10731== Conditional jump or move depends on uninitialised value(s)
> ==10731==    at 0x4009442: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==
> ==10731== Conditional jump or move depends on uninitialised value(s)
> ==10731==    at 0x4009339: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==
> ==10731== Syscall param socketcall.sendto(msg) points to uninitialised 
> byte(s)
> ==10731==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
> ==10731==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4145F1: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x5295B57: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==  Address 0x7FEFFB401 is on thread 1's stack
> ==10730==
> ==10730== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
> ==10730== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
> ==10730== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
> ==10730== For counts of detected errors, rerun with: -v
> ==10730== searching for pointers to 437 not-freed blocks.
> ==10730== checked 173,712 bytes.
> ==10730==
> ==10730== LEAK SUMMARY:
> ==10730==    definitely lost: 0 bytes in 0 blocks.
> ==10730==      possibly lost: 0 bytes in 0 blocks.
> ==10730==    still reachable: 24,090 bytes in 437 blocks.
> ==10730==         suppressed: 0 bytes in 0 blocks.
> ==10730== Reachable blocks (those to which a pointer was found) are not 
> shown.
> ==10730== To see them, rerun with: --show-reachable=yes
> ==10731==
> ==10731== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from 
> 1)
> ==10731== malloc/free: in use at exit: 13,231 bytes in 85 blocks.
> ==10731== malloc/free: 3,058,176 allocs, 3,058,091 frees, 619,413,167 
> bytes allocated.
> ==10731== For counts of detected errors, rerun with: -v
> ==10731== searching for pointers to 85 not-freed blocks.
> ==10731== checked 33,675,000 bytes.
> ==10731==
> ==10731==
> ==10731== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely 
> lost in loss record 9 of 25
> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> ==10731==    by 0x5295A31: ???
> ==10731==    by 0x5295C3C: ???
> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> ==10731==
> ==10731==
> ==10731== 584 (104 direct, 480 indirect) bytes in 2 blocks are definitely 
> lost in loss record 13 of 25
> ==10731==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> ==10731==    by 0x502F63F: (within /lib/libc-2.3.6.so)
> ==10731==    by 0x502FD95: __nss_database_lookup (in /lib/libc-2.3.6.so)
> ==10731==    by 0x59B373F: ???
> ==10731==    by 0x59B4532: ???
> ==10731==    by 0x4FE5BF4: getgrnam_r (in /lib/libc-2.3.6.so)
> ==10731==    by 0x4272C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x426A48: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
> ==10731==
> ==10731==
> ==10731== 544 bytes in 4 blocks are possibly lost in loss record 20 of 25
> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> ==10731==    by 0x400EA3D: _dl_allocate_tls (in /lib/ld-2.3.6.so)
> ==10731==    by 0x4C3B500: pthread_create@@GLIBC_2.2.5 (in 
> /lib/libpthread-2.3.6.so)
> ==10731==    by 0x41690E: wtpAdviseMaxWorkers (in 
> /usr/local/sbin/rsyslogd)
> ==10731==    by 0x41A4EF: queueStart (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40B5BC: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> ==10731==
> ==10731==
> ==10731== 1,420 (928 direct, 492 indirect) bytes in 2 blocks are 
> definitely lost in loss record 23 of 25
> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> ==10731==    by 0x41F13F: msgConstruct (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40ABA9: logmsgInternal (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40BEC9: (within /usr/local/sbin/rsyslogd)
> ==10731==    by 0x40C07A: realMain (in /usr/local/sbin/rsyslogd)
> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> ==10731==
> ==10731== LEAK SUMMARY:
> ==10731==    definitely lost: 1,064 bytes in 5 blocks.
> ==10731==    indirectly lost: 1,036 bytes in 34 blocks.
> ==10731==      possibly lost: 544 bytes in 4 blocks.
> ==10731==    still reachable: 10,587 bytes in 42 blocks.
> ==10731==         suppressed: 0 bytes in 0 blocks.
> ==10731== Reachable blocks (those to which a pointer was found) are not 
> shown.
> ==10731== To see them, rerun with: --show-reachable=yes
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From david at lang.hm  Mon Sep 15 10:31:47 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 01:31:47 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 00:53 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>> I did --trace-children=yes (otherwise it wouldn't stay attached) and
>> --leak-detail=yes (since it seemed to report memory leaks in the first
>> run)
>
> Well, I am actually not so much interested in what the forked processes
> do. They have "memory leaks", but these "leaks" stem from process
> duplication and are cleaned up by the OS when the forked process
> terminates. Cleaning them up oneself creates unnecessary CPU, as the OS
> does it much more efficient. Also, the hang is related to the parent
> process. Thus, I'd actually pefer --trace-children=no ;)
>
> I also notice that it would be of advantage to do a compile with
>
> ./configure --enable-debug --enable-valgrind
>
> as this leads to better debug trace information. But the parent trace is most interesting first (if there is anything reported from valgrind).

Ok, I will do this in the morning.

one other item that occured to me, should I even be doing the kill -HUP? 
or does rsyslog open the file for writing each time (so that I just have 
to mv the file away and it will create a new one)?

David Lang

> Rainer
>
>>
>> this seemed to run into problems with the first rotation (which given that
>> there was no process to do a kill -HUP on, isn't surprising)
>>
>> David Lang
>>
>> ==10726== Memcheck, a memory error detector.
>> ==10726== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10726== Using LibVEX rev 1658, a library for dynamic binary translation.
>> ==10726== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
>> ==10726== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
>> framework.
>> ==10726== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10726== For more details, rerun with: -v
>> ==10726==
>> ==10726== My PID = 10726, parent PID = 13696.  Prog and args are:
>> ==10726==    /usr/local/sbin/rsyslogd
>> ==10726==    -c3
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x40091D5: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x40091DE: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010B04: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010C61: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006E47: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Invalid read of size 8
>> ==10726==    at 0x4010C54: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
>> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10726==    by 0x4007113: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010A70: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006117: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Conditional jump or move depends on uninitialised value(s)
>> ==10726==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4008B91: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== Invalid read of size 8
>> ==10726==    at 0x4010C20: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
>> ==10726==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10726==    by 0x4006123: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10726==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10726==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10726==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10726==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10726==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10726==
>> ==10726== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
>> ==10726== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
>> ==10726== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
>> ==10726== For counts of detected errors, rerun with: -v
>> ==10726== searching for pointers to 437 not-freed blocks.
>> ==10726== checked 172,368 bytes.
>> ==10726==
>> ==10726== LEAK SUMMARY:
>> ==10726==    definitely lost: 0 bytes in 0 blocks.
>> ==10726==      possibly lost: 0 bytes in 0 blocks.
>> ==10726==    still reachable: 24,090 bytes in 437 blocks.
>> ==10726==         suppressed: 0 bytes in 0 blocks.
>> ==10726== Reachable blocks (those to which a pointer was found) are not
>> shown.
>> ==10726== To see them, rerun with: --show-reachable=yes
>>
>>
>>
>>
>> ==10730== Memcheck, a memory error detector.
>> ==10730== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10730== Using LibVEX rev 1658, a library for dynamic binary translation.
>> ==10730== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
>> ==10730== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
>> framework.
>> ==10730== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
>> ==10730== For more details, rerun with: -v
>> ==10730==
>> ==10730== My PID = 10730, parent PID = 13696.  Prog and args are:
>> ==10730==    /usr/local/sbin/rsyslogd
>> ==10730==    -c3
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x40091D5: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x40091DE: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x420F94: confClassInit (in /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x40C36C: realMain (in /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010B04: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010C61: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006E47: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Invalid read of size 8
>> ==10730==    at 0x4010C54: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==  Address 0x5198C60 is 16 bytes inside a block of size 23 alloc'd
>> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10730==    by 0x4007113: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5054467: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010A70: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x400610A: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006117: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Conditional jump or move depends on uninitialised value(s)
>> ==10730==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4008B91: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==
>> ==10730== Invalid read of size 8
>> ==10730==    at 0x4010C20: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4008D38: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==  Address 0x519AEC8 is 32 bytes inside a block of size 35 alloc'd
>> ==10730==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10730==    by 0x4006123: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5052230: (within /lib/libc-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10730==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10730==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10730==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10730==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10730==    by 0x41C1EE: (within /usr/local/sbin/rsyslogd)
>> ==10731== Warning: noted but unhandled ioctl 0x5422 with no size/direction
>> hints
>> ==10731==    This could cause spurious value errors to appear.
>> ==10731==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
>> proper wrapper.
>> ==10731==
>> ==10731== Conditional jump or move depends on uninitialised value(s)
>> ==10731==    at 0x4009442: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==
>> ==10731== Conditional jump or move depends on uninitialised value(s)
>> ==10731==    at 0x4009339: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5052622: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
>> ==10731==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
>> ==10731==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
>> ==10731==    by 0x42643E: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x422418: doModLoad (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==
>> ==10731== Syscall param socketcall.sendto(msg) points to uninitialised
>> byte(s)
>> ==10731==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4145F1: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x5295B57: addAllowedSenderLine (in
>> /usr/local/lib/rsyslog/lmnet.so)
>> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==  Address 0x7FEFFB401 is on thread 1's stack
>> ==10730==
>> ==10730== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
>> ==10730== malloc/free: in use at exit: 24,090 bytes in 437 blocks.
>> ==10730== malloc/free: 577 allocs, 140 frees, 32,887 bytes allocated.
>> ==10730== For counts of detected errors, rerun with: -v
>> ==10730== searching for pointers to 437 not-freed blocks.
>> ==10730== checked 173,712 bytes.
>> ==10730==
>> ==10730== LEAK SUMMARY:
>> ==10730==    definitely lost: 0 bytes in 0 blocks.
>> ==10730==      possibly lost: 0 bytes in 0 blocks.
>> ==10730==    still reachable: 24,090 bytes in 437 blocks.
>> ==10730==         suppressed: 0 bytes in 0 blocks.
>> ==10730== Reachable blocks (those to which a pointer was found) are not
>> shown.
>> ==10730== To see them, rerun with: --show-reachable=yes
>> ==10731==
>> ==10731== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from
>> 1)
>> ==10731== malloc/free: in use at exit: 13,231 bytes in 85 blocks.
>> ==10731== malloc/free: 3,058,176 allocs, 3,058,091 frees, 619,413,167
>> bytes allocated.
>> ==10731== For counts of detected errors, rerun with: -v
>> ==10731== searching for pointers to 85 not-freed blocks.
>> ==10731== checked 33,675,000 bytes.
>> ==10731==
>> ==10731==
>> ==10731== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely
>> lost in loss record 9 of 25
>> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
>> ==10731==    by 0x5295A31: ???
>> ==10731==    by 0x5295C3C: ???
>> ==10731==    by 0x42239D: doNameLine (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
>> ==10731==
>> ==10731==
>> ==10731== 584 (104 direct, 480 indirect) bytes in 2 blocks are definitely
>> lost in loss record 13 of 25
>> ==10731==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
>> ==10731==    by 0x502F63F: (within /lib/libc-2.3.6.so)
>> ==10731==    by 0x502FD95: __nss_database_lookup (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x59B373F: ???
>> ==10731==    by 0x59B4532: ???
>> ==10731==    by 0x4FE5BF4: getgrnam_r (in /lib/libc-2.3.6.so)
>> ==10731==    by 0x4272C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x426A48: processCfSysLineCommand (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x42122D: cfsysline (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4213CC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4221C5: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B330: (within /usr/local/sbin/rsyslogd)
>> ==10731==
>> ==10731==
>> ==10731== 544 bytes in 4 blocks are possibly lost in loss record 20 of 25
>> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
>> ==10731==    by 0x400EA3D: _dl_allocate_tls (in /lib/ld-2.3.6.so)
>> ==10731==    by 0x4C3B500: pthread_create@@GLIBC_2.2.5 (in
>> /lib/libpthread-2.3.6.so)
>> ==10731==    by 0x41690E: wtpAdviseMaxWorkers (in
>> /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x41A4EF: queueStart (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40B5BC: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40CEA1: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
>> ==10731==
>> ==10731==
>> ==10731== 1,420 (928 direct, 492 indirect) bytes in 2 blocks are
>> definitely lost in loss record 23 of 25
>> ==10731==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
>> ==10731==    by 0x41F13F: msgConstruct (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40ABA9: logmsgInternal (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40BEC9: (within /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x40C07A: realMain (in /usr/local/sbin/rsyslogd)
>> ==10731==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
>> ==10731==
>> ==10731== LEAK SUMMARY:
>> ==10731==    definitely lost: 1,064 bytes in 5 blocks.
>> ==10731==    indirectly lost: 1,036 bytes in 34 blocks.
>> ==10731==      possibly lost: 544 bytes in 4 blocks.
>> ==10731==    still reachable: 10,587 bytes in 42 blocks.
>> ==10731==         suppressed: 0 bytes in 0 blocks.
>> ==10731== Reachable blocks (those to which a pointer was found) are not
>> shown.
>> ==10731== To see them, rerun with: --show-reachable=yes
>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Mon Sep 15 10:57:26 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 10:57:26 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
Message-ID: <1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> one other item that occured to me, should I even be doing the kill -HUP? 
> or does rsyslog open the file for writing each time (so that I just have 
> to mv the file away and it will create a new one)?

no, you need the HUP. Otherwise the file is kept open (so this is no
easy way to improve performance ;))

Rainer



From david at lang.hm  Mon Sep 15 11:07:22 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 02:07:22 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>
>> one other item that occured to me, should I even be doing the kill -HUP?
>> or does rsyslog open the file for writing each time (so that I just have
>> to mv the file away and it will create a new one)?
>
> no, you need the HUP. Otherwise the file is kept open (so this is no
> easy way to improve performance ;))

here is a run with the debug and valgrind options

==11835== Memcheck, a memory error detector.

==11835== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.

==11835== Using LibVEX rev 1658, a library for dynamic binary translation.

==11835== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.

==11835== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.

==11835== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.

==11835== For more details, rerun with: -v

==11835==

==11835== My PID = 11835, parent PID = 11702.  Prog and args are:

==11835==    /usr/local/sbin/rsyslogd

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x40091D5: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==11835==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x40091DE: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==11835==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010AEE: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010AF9: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010B04: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010C61: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006E47: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Invalid read of size 8

==11835==    at 0x4010C54: (within /lib/ld-2.3.6.so)

==11835==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==11835==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==  Address 0x5198EB0 is 16 bytes inside a block of size 23 alloc'd

==11835==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==11835==    by 0x4007113: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x5054467: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==11835==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==11835==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==11835==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==11835==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010A70: (within /lib/ld-2.3.6.so)

==11835==    by 0x400610A: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010A7F: (within /lib/ld-2.3.6.so)

==11835==    by 0x400610A: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010A8E: (within /lib/ld-2.3.6.so)

==11835==    by 0x400610A: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006117: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Conditional jump or move depends on uninitialised value(s)

==11835==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==11835==    by 0x4008B91: (within /lib/ld-2.3.6.so)

==11835==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==

==11835== Invalid read of size 8

==11835==    at 0x4010C20: (within /lib/ld-2.3.6.so)

==11835==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==11835==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==  Address 0x519B1C0 is 32 bytes inside a block of size 35 alloc'd

==11835==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==11835==    by 0x4006123: (within /lib/ld-2.3.6.so)

==11835==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==11835==    by 0x5052230: (within /lib/libc-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11835==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11835==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11835==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11835==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11835==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11835==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==11836== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
hints

==11836==    This could cause spurious value errors to appear.

==11836==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
proper wrapper.

==11836==

==11836== Conditional jump or move depends on uninitialised value(s)

==11836==    at 0x4009442: (within /lib/ld-2.3.6.so)

==11836==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11836==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11836==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11836==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==11836==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==11836==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==11836==

==11836== Conditional jump or move depends on uninitialised value(s)

==11836==    at 0x4009339: (within /lib/ld-2.3.6.so)

==11836==    by 0x5052622: (within /lib/libc-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==11836==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==11836==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==11836==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==11836==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==11836==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==11836==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==11836==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==11836==

==11836== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)

==11836==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)

==11836==    by 0x503E8C9: (within /lib/libc-2.3.6.so)

==11836==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)

==11836==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)

==11836==    by 0x5295D97: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==11836==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==11836==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==11836==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==11836==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==11836==    by 0x40D3D1: realMain (in /usr/local/sbin/rsyslogd)
==11836==  Address 0x7FEFFB371 is on thread 1's stack

==11835==

==11835== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)

==11835== malloc/free: in use at exit: 25,332 bytes in 459 blocks.

==11835== malloc/free: 606 allocs, 147 frees, 36,928 bytes allocated.

==11835== For counts of detected errors, rerun with: -v

==11835== searching for pointers to 459 not-freed blocks.

==11835== checked 175,080 bytes.

==11835==

==11835== LEAK SUMMARY:

==11835==    definitely lost: 0 bytes in 0 blocks.

==11835==      possibly lost: 0 bytes in 0 blocks.

==11835==    still reachable: 25,332 bytes in 459 blocks.

==11835==         suppressed: 0 bytes in 0 blocks.

==11835== Reachable blocks (those to which a pointer was found) are not 
shown.

==11835== To see them, rerun with: --show-reachable=yes

==11836==

==11836== ERROR SUMMARY: 54 errors from 16 contexts (suppressed: 10 from 
1)

==11836== malloc/free: in use at exit: 20,815 bytes in 114 blocks.

==11836== malloc/free: 1,738 allocs, 1,624 frees, 255,036 bytes allocated.

==11836== For counts of detected errors, rerun with: -v

==11836== searching for pointers to 114 not-freed blocks.

==11836== checked 33,711,344 bytes.

==11836==

==11836== LEAK SUMMARY:

==11836==    definitely lost: 2,020 bytes in 35 blocks.

==11836==      possibly lost: 544 bytes in 4 blocks.

==11836==    still reachable: 18,251 bytes in 75 blocks.

==11836==         suppressed: 0 bytes in 0 blocks.

==11836== Use --leak-check=full to see details of leaked memory.




From rgerhards at hq.adiscon.com  Mon Sep 15 11:28:19 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 11:28:19 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
Message-ID: <1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>

On Mon, 2008-09-15 at 02:07 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> > On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
> >> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> >
> >> one other item that occured to me, should I even be doing the kill -HUP?
> >> or does rsyslog open the file for writing each time (so that I just have
> >> to mv the file away and it will create a new one)?
> >
> > no, you need the HUP. Otherwise the file is kept open (so this is no
> > easy way to improve performance ;))
> 
> here is a run with the debug and valgrind options

mmhhh... it still is missing lots of information. Did "make install"
install to incorrect locations? This happens quite often, especially on
x64 systems (I've fallen myself more than once into this trap).

Rainer



From david at lang.hm  Mon Sep 15 11:51:30 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 02:51:30 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> On Mon, 2008-09-15 at 02:07 -0700, david at lang.hm wrote:
>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>
>>> On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
>>>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>>>
>>>> one other item that occured to me, should I even be doing the kill -HUP?
>>>> or does rsyslog open the file for writing each time (so that I just have
>>>> to mv the file away and it will create a new one)?
>>>
>>> no, you need the HUP. Otherwise the file is kept open (so this is no
>>> easy way to improve performance ;))
>>
>> here is a run with the debug and valgrind options
>
> mmhhh... it still is missing lots of information. Did "make install"
> install to incorrect locations? This happens quite often, especially on
> x64 systems (I've fallen myself more than once into this trap).

trying again (this time remembering to add -c3 to the command line)

==12351== Memcheck, a memory error detector.

==12351== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.

==12351== Using LibVEX rev 1658, a library for dynamic binary translation.

==12351== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.

==12351== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.

==12351== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.

==12351== For more details, rerun with: -v

==12351==

==12351== My PID = 12351, parent PID = 11702.  Prog and args are:

==12351==    /usr/local/sbin/rsyslogd

==12351==    -c3

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x40091D5: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x40091DE: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)

==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010AEE: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010AF9: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010B04: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010C61: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006E47: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Invalid read of size 8

==12351==    at 0x4010C54: (within /lib/ld-2.3.6.so)

==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==  Address 0x5198EB0 is 16 bytes inside a block of size 23 alloc'd

==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12351==    by 0x4007113: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)

==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)

==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)

==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)

==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010A70: (within /lib/ld-2.3.6.so)

==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010A7F: (within /lib/ld-2.3.6.so)

==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010A8E: (within /lib/ld-2.3.6.so)

==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006117: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Conditional jump or move depends on uninitialised value(s)

==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)

==12351==    by 0x4008B91: (within /lib/ld-2.3.6.so)

==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==

==12351== Invalid read of size 8

==12351==    at 0x4010C20: (within /lib/ld-2.3.6.so)

==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)

==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==  Address 0x519B1C0 is 32 bytes inside a block of size 35 alloc'd

==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12351==    by 0x4006123: (within /lib/ld-2.3.6.so)

==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)

==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)

==12352== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
hints

==12352==    This could cause spurious value errors to appear.

==12352==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
proper wrapper.

==12352==

==12352== Conditional jump or move depends on uninitialised value(s)

==12352==    at 0x4009442: (within /lib/ld-2.3.6.so)

==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==

==12352== Conditional jump or move depends on uninitialised value(s)

==12352==    at 0x4009339: (within /lib/ld-2.3.6.so)

==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)

==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)

==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)

==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)

==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)

==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==

==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)

==12352==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)

==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)

==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)

==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)

==12352==    by 0x5295D97: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D3D1: realMain (in /usr/local/sbin/rsyslogd)

==12352==  Address 0x7FEFFB361 is on thread 1's stack

==12351==

==12351== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)

==12351== malloc/free: in use at exit: 24,243 bytes in 445 blocks.

==12351== malloc/free: 585 allocs, 140 frees, 33,424 bytes allocated.

==12351== For counts of detected errors, rerun with: -v

==12351== searching for pointers to 445 not-freed blocks.

==12351== checked 174,016 bytes.

==12351==

==12351== LEAK SUMMARY:

==12351==    definitely lost: 0 bytes in 0 blocks.

==12351==      possibly lost: 0 bytes in 0 blocks.

==12351==    still reachable: 24,243 bytes in 445 blocks.

==12351==         suppressed: 0 bytes in 0 blocks.

==12351== Reachable blocks (those to which a pointer was found) are not 
shown.

==12351== To see them, rerun with: --show-reachable=yes

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAEDD: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF02: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF10: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E44 is 4 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF1E: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid write of size 4

==12352==    at 0x57AAF14: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid write of size 4

==12352==    at 0x57AAF38: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF4A: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid free() / delete / delete[]

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAF62: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
byte(s)

==12352==    at 0x50202D0: sendto (in /lib/libc-2.3.6.so)

==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)

==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)

==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)

==12352==    by 0x5295D97: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==  Address 0x7FEFFB361 is on thread 1's stack

==12352==

==12352== Thread 5:

==12352== Invalid read of size 4

==12352==    at 0x57AB092: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)

==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AB063: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)

==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Thread 1:

==12352== Invalid read of size 4

==12352==    at 0x5295196: closeUDPListenSockets (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd

==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)

==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==

==12352== Invalid read of size 4

==12352==    at 0x57AAF20: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)

==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 free'd

==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)

==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)

==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)

==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)

==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)

==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)



valgrind: m_mallocfree.c:194 (get_bszB_as_is): Assertion 'bszB_lo == 
bszB_hi' failed.

valgrind: Heap block lo/hi size mismatch: lo = 2, hi = 562949953486848.

Probably caused by overrunning/underrunning a heap block's bounds.



==12352==    at 0x3801770A: report_and_quit (m_libcassert.c:136)

==12352==    by 0x38017A6D: vgPlain_assert_fail (m_libcassert.c:200)

==12352==    by 0x380208D8: vgPlain_arena_malloc (m_mallocfree.c:191)

==12352==    by 0x3803523B: vgPlain_cli_malloc (replacemalloc_core.c:101)

==12352==    by 0x38002487: vgMemCheck_calloc (mc_malloc_wrappers.c:182)

==12352==    by 0x3803592F: do_client_request (scheduler.c:1166)

==12352==    by 0x38036FAD: vgPlain_scheduler (scheduler.c:869)

==12352==    by 0x38051849: run_a_thread_NORETURN (syswrap-linux.c:87)



sched status:

   running_tid=1



Thread 1: status = VgTs_Runnable

==12352==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)

==12352==    by 0x414B72: rsCStrConstruct (in /usr/local/sbin/rsyslogd)

==12352==    by 0x414D0C: rsCStrConstructFromszStr (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4162FB: rsParsConstructFromSz (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x5295D52: addAllowedSenderLine (in 
/usr/local/lib/rsyslog/lmnet.so)

==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)

==12352==    by 0x429771: processCfSysLineCommand (in 
/usr/local/sbin/rsyslogd)

==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)

==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)

==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)

==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)




From satoru.satoh at gmail.com  Mon Sep 15 11:56:29 2008
From: satoru.satoh at gmail.com (Satoru SATOH)
Date: Mon, 15 Sep 2008 18:56:29 +0900
Subject: [rsyslog] docbook and math
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F12B@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F12B@grfint2.intern.adiscon.com>
Message-ID: <20080915095627.GA14056@localhost.localdomain>

Hi,


I don't have enough experience with docbook and math formulas but LaTeX
might be better for now unfortunatelly, I guess.

If you go with docbook, current dtd-based docbook (4.x) does not well
with MathML natively and you might have to convert math formula to some
formats of image somehow. There may be two choices.

 1) write math formulas in LaTex and convert to images (EPS, PNG, ...)
 2) write math formulas in MathML and convert to images (SVG, ...)

Here are some related links.

 * http://www.sagehill.net/docbookxsl/MathML.html
 * http://www.grigoriev.ru/svgmath/
 * http://www.sagehill.net/docbookxsl/SVGimages.html

IIWM, I would choose 2) (mathml -> svg) and try svgmath.

Other random notes about MathML:

 * OpenOffice.org-Math supports MathML output.

 * Gecho based browsers (e.g. firefox) can display MathML docs.
   * http://www.mozilla.org/projects/mathml/authoring.html
   * http://www.mozilla.org/projects/mathml/fonts/ (MathML fonts)

 * MathML has two ways to markup; contents markup and presentation
   markup. MathMLc2p
   (http://www.lri.fr/~pietriga/mathmlc2p/mathmlc2p.html) might 
   help if you have to transform from the former into the later.


- satoru

On Thu, Sep 11, 2008 at 03:27:49PM +0200, Rainer Gerhards wrote:
> Hi folks,
> 
> and especially those that are proficient with docbook ;) I have one
> question. I am thinking about a series of design papers. I think,
> however, that at least some of them will require a lot of mathematical
> formulas. Typically, I'd say that should be done in LaTeX. But with
> moving to docbook for the user doc, it may be good to use a single
> system.
> 
> I have now investigated docbook and maths a bit, but what I found didn't
> look very promising. The best I found was MathML, which is far too
> verbose for any hand-editing (and I don't want to rely on specialized
> formula editors). I also found some references to embedded TeX, but that
> looked quite hackish.
> 
> Could somebody enlighten me on the current typical approach for such
> papers? Do they still usually go the LaTeX way or is there a good way to
> do it with docbook?
> 
> Many thanks in advance,
> Rainer


From rgerhards at hq.adiscon.com  Mon Sep 15 11:57:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 11:57:14 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
Message-ID: <1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>

mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
still has no source line information. Without that, it has very little
value. OK, I'll look at some other ways.

Rainer

On Mon, 2008-09-15 at 02:51 -0700, david at lang.hm wrote:
> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> 
> > On Mon, 2008-09-15 at 02:07 -0700, david at lang.hm wrote:
> >> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> >>
> >>> On Mon, 2008-09-15 at 01:31 -0700, david at lang.hm wrote:
> >>>> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
> >>>
> >>>> one other item that occured to me, should I even be doing the kill -HUP?
> >>>> or does rsyslog open the file for writing each time (so that I just have
> >>>> to mv the file away and it will create a new one)?
> >>>
> >>> no, you need the HUP. Otherwise the file is kept open (so this is no
> >>> easy way to improve performance ;))
> >>
> >> here is a run with the debug and valgrind options
> >
> > mmhhh... it still is missing lots of information. Did "make install"
> > install to incorrect locations? This happens quite often, especially on
> > x64 systems (I've fallen myself more than once into this trap).
> 
> trying again (this time remembering to add -c3 to the command line)
> 
> ==12351== Memcheck, a memory error detector.
> 
> ==12351== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> 
> ==12351== Using LibVEX rev 1658, a library for dynamic binary translation.
> 
> ==12351== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> 
> ==12351== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
> framework.
> 
> ==12351== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> 
> ==12351== For more details, rerun with: -v
> 
> ==12351==
> 
> ==12351== My PID = 12351, parent PID = 11702.  Prog and args are:
> 
> ==12351==    /usr/local/sbin/rsyslogd
> 
> ==12351==    -c3
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x40091D5: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x40091DE: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x423414: confClassInit (in /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x40C89C: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010AEE: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010AF9: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010B04: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CB6: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010C61: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006E47: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Invalid read of size 8
> 
> ==12351==    at 0x4010C54: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==  Address 0x5198EB0 is 16 bytes inside a block of size 23 alloc'd
> 
> ==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12351==    by 0x4007113: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5054467: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x50544B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F426: __nss_lookup_function (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x502F4D4: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5034272: gethostbyname_r (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x5033A72: gethostbyname (in /lib/libc-2.3.6.so)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010A70: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010A7F: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010A8E: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x400610A: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006117: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Conditional jump or move depends on uninitialised value(s)
> 
> ==12351==    at 0x4010C2D: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4008B91: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==
> 
> ==12351== Invalid read of size 8
> 
> ==12351==    at 0x4010C20: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4008D38: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4004CF2: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006D6C: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==  Address 0x519B1C0 is 32 bytes inside a block of size 35 alloc'd
> 
> ==12351==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12351==    by 0x4006123: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4006CD3: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5052230: (within /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12351==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12351==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12351==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12351==    by 0x41E15E: (within /usr/local/sbin/rsyslogd)
> 
> ==12352== Warning: noted but unhandled ioctl 0x5422 with no size/direction 
> hints
> 
> ==12352==    This could cause spurious value errors to appear.
> 
> ==12352==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
> proper wrapper.
> 
> ==12352==
> 
> ==12352== Conditional jump or move depends on uninitialised value(s)
> 
> ==12352==    at 0x4009442: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==
> 
> ==12352== Conditional jump or move depends on uninitialised value(s)
> 
> ==12352==    at 0x4009339: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5052622: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x5051CC7: _dl_open (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x4D4B114: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x400B7D0: (within /lib/ld-2.3.6.so)
> 
> ==12352==    by 0x4D4B649: (within /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x4D4B0D1: dlopen (in /lib/libdl-2.3.6.so)
> 
> ==12352==    by 0x428F2E: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4248A8: doModLoad (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==
> 
> ==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
> byte(s)
> 
> ==12352==    at 0x5020275: sendto (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x5295D97: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D3D1: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==  Address 0x7FEFFB361 is on thread 1's stack
> 
> ==12351==
> 
> ==12351== ERROR SUMMARY: 15 errors from 13 contexts (suppressed: 9 from 1)
> 
> ==12351== malloc/free: in use at exit: 24,243 bytes in 445 blocks.
> 
> ==12351== malloc/free: 585 allocs, 140 frees, 33,424 bytes allocated.
> 
> ==12351== For counts of detected errors, rerun with: -v
> 
> ==12351== searching for pointers to 445 not-freed blocks.
> 
> ==12351== checked 174,016 bytes.
> 
> ==12351==
> 
> ==12351== LEAK SUMMARY:
> 
> ==12351==    definitely lost: 0 bytes in 0 blocks.
> 
> ==12351==      possibly lost: 0 bytes in 0 blocks.
> 
> ==12351==    still reachable: 24,243 bytes in 445 blocks.
> 
> ==12351==         suppressed: 0 bytes in 0 blocks.
> 
> ==12351== Reachable blocks (those to which a pointer was found) are not 
> shown.
> 
> ==12351== To see them, rerun with: --show-reachable=yes
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAEDD: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF02: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF10: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E44 is 4 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF1E: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid write of size 4
> 
> ==12352==    at 0x57AAF14: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid write of size 4
> 
> ==12352==    at 0x57AAF38: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF4A: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid free() / delete / delete[]
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAF62: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51B1E40 is 0 bytes inside a block of size 12 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Syscall param socketcall.sendto(msg) points to uninitialised 
> byte(s)
> 
> ==12352==    at 0x50202D0: sendto (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x503E8C9: (within /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x500AF2C: getaddrinfo (in /lib/libc-2.3.6.so)
> 
> ==12352==    by 0x415F0D: parsAddrWithBits (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x5295D97: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==  Address 0x7FEFFB361 is on thread 1's stack
> 
> ==12352==
> 
> ==12352== Thread 5:
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AB092: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)
> 
> ==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AB063: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x41657B: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so)
> 
> ==12352==    by 0x501F5D1: clone (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Thread 1:
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x5295196: closeUDPListenSockets (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB348 is 0 bytes after a block of size 8 alloc'd
> 
> ==12352==    at 0x4A1B858: malloc (vg_replace_malloc.c:149)
> 
> ==12352==    by 0x57AAEE9: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==
> 
> ==12352== Invalid read of size 4
> 
> ==12352==    at 0x57AAF20: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x429A0C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> ==12352==  Address 0x51DB34C is 4 bytes after a block of size 8 free'd
> 
> ==12352==    at 0x4A1B46D: free (vg_replace_malloc.c:233)
> 
> ==12352==    by 0x57AAE04: (within /usr/local/lib/rsyslog/imudp.so)
> 
> ==12352==    by 0x4165D1: thrdTerminate (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x416617: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42A9F9: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42AC3D: llDestroy (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x41640D: thrdTerminateAll (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B7BF: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> 
> 
> valgrind: m_mallocfree.c:194 (get_bszB_as_is): Assertion 'bszB_lo == 
> bszB_hi' failed.
> 
> valgrind: Heap block lo/hi size mismatch: lo = 2, hi = 562949953486848.
> 
> Probably caused by overrunning/underrunning a heap block's bounds.
> 
> 
> 
> ==12352==    at 0x3801770A: report_and_quit (m_libcassert.c:136)
> 
> ==12352==    by 0x38017A6D: vgPlain_assert_fail (m_libcassert.c:200)
> 
> ==12352==    by 0x380208D8: vgPlain_arena_malloc (m_mallocfree.c:191)
> 
> ==12352==    by 0x3803523B: vgPlain_cli_malloc (replacemalloc_core.c:101)
> 
> ==12352==    by 0x38002487: vgMemCheck_calloc (mc_malloc_wrappers.c:182)
> 
> ==12352==    by 0x3803592F: do_client_request (scheduler.c:1166)
> 
> ==12352==    by 0x38036FAD: vgPlain_scheduler (scheduler.c:869)
> 
> ==12352==    by 0x38051849: run_a_thread_NORETURN (syswrap-linux.c:87)
> 
> 
> 
> sched status:
> 
>    running_tid=1
> 
> 
> 
> Thread 1: status = VgTs_Runnable
> 
> ==12352==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
> 
> ==12352==    by 0x414B72: rsCStrConstruct (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x414D0C: rsCStrConstructFromszStr (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4162FB: rsParsConstructFromSz (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x5295D52: addAllowedSenderLine (in 
> /usr/local/lib/rsyslog/lmnet.so)
> 
> ==12352==    by 0x42482D: doNameLine (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x429771: processCfSysLineCommand (in 
> /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4236AD: cfsysline (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x42384C: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x424655: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40B860: (within /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x40D534: realMain (in /usr/local/sbin/rsyslogd)
> 
> ==12352==    by 0x4F724C9: (below main) (in /lib/libc-2.3.6.so)
> 
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep 15 12:13:45 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 15 Sep 2008 12:13:45 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221461699.2682.20.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
	<1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
Message-ID: <1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>

side-note: do you mind if we concentrate on the performance issue first
and keep an eye on this here (as a secondary goal) while we do it? I
think that would enable me to address both most quickly (I can add
instrumentation code/checks while I modify the file output). There may
come a time when reversing priorities makes sense, but for now I think
this would be the best way...

Rainer
On Mon, 2008-09-15 at 11:57 +0200, Rainer Gerhards wrote:
> mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
> still has no source line information. Without that, it has very little
> value. OK, I'll look at some other ways.




From david at lang.hm  Mon Sep 15 13:14:42 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 04:14:42 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<alpine.DEB.1.10.0809150004390.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
	<1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
	<1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, Rainer Gerhards wrote:

> side-note: do you mind if we concentrate on the performance issue first
> and keep an eye on this here (as a secondary goal) while we do it? I
> think that would enable me to address both most quickly (I can add
> instrumentation code/checks while I modify the file output). There may
> come a time when reversing priorities makes sense, but for now I think
> this would be the best way...

no problem.

> Rainer
> On Mon, 2008-09-15 at 11:57 +0200, Rainer Gerhards wrote:
>> mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
>> still has no source line information. Without that, it has very little
>> value. OK, I'll look at some other ways.
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From lorenzo at sancho.ccd.uniroma2.it  Fri Sep 12 12:40:20 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Fri, 12 Sep 2008 12:40:20 +0200 (CEST)
Subject: [rsyslog] rsyslog frequent crashes
Message-ID: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>

The system is a dual processor / quad core Xeon E5335 running a 64 bit 
debian lenny distribution; I've enabled both debug and rtinst configure,
and installed an unstripped binary; I'm attaching the full backtrace here.

the system should act as a client to a remote syslog server; I'm enclosing 
the conf files too.

In the previous attempts (before enabling rtinst and debug), I got lines 
like "rsyslogd: double free or corruption (!prev): 0x0000000000674c50"
in the failover log (corresponding to the _nodebug backtrace); this last 
time, the line I've got is

"msg.c:273: msgDestruct: Assertion `(unsigned) ((obj_t*)
            (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed."

and the double free detector didn't fire.

I'm really at a loss now: I've been lured into experimenting rsyslog from 
the high level architectural description being this clean and seemingly 
powerful, but now I fear I still cannot rely on this logger in production.

Eager to help in debugging, sincerely yours

 	lorenzo



+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Core was generated by `/usr/sbin/rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 16283]
[New process 16285]
[New process 16284]
[New process 16282]
[New process 16281]
#0  0x00002b44aa374ef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 16281):
#0  0x00002b44aa40bf12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x000000000040efb9 in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:2563
	dbgCALLStaCK_POP_POINT = 0
	iRet = <value optimized out>
	i = <value optimized out>
	p = <value optimized out>
	num_fds = <value optimized out>
	ch = <value optimized out>
	hent = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0x1, 
    sa_sigaction = 0x1}, sa_mask = {__val = {0 <repeats 16 times>}}, 
  sa_flags = 0, sa_restorer = 0}
	bIsFirstOption = <value optimized out>
	bEOptionWasGiven = <value optimized out>
	bImUxSockLoaded = <value optimized out>
	arg = <value optimized out>
	legacyConfLine = '\0' <repeats 79 times>
	pdbgFuncDB = (dbgFuncDB_t *) 0x66e320
	__func__ = "realMain"
#2  0x00002b44aa3611a6 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#3  0x00000000004096b9 in _start ()
No locals.

Thread 4 (process 16282):
#0  0x00002b44a9d23fad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x0000000000416333 in dbgCondTimedWait (cond=0x686fe0, 
    pmut=0xffffffffffffff92, abstime=0x407fffd0, pFuncDB=0x6a6bc0, ln=403, 
    iStackPtr=<value optimized out>) at debug.c:555
	ret = <value optimized out>
#2  0x0000000000421f59 in wtiWorker (pThis=0x688160) at wti.c:403
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130748, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727512550297697851, 1727653793608105531}, __mask_was_saved = 0}}, 
  __pad = {0x408000d0, 0x0, 0x68a740, 0x19f}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 1
	iCancelStateSave = 0
	t = {tv_sec = 1221174340, tv_nsec = 609910833}
	pWtp = (wtp_t *) 0x687b50
	bInactivityTOOccured = 0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6a6bc0
	__func__ = "wtiWorker"
	__PRETTY_FUNCTION__ = "wtiWorker"
#3  0x00000000004209c2 in wtpWorker (arg=0x688160) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130512, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727511424978517563, 1727653794260319803}, __mask_was_saved = 0}}, 
  __pad = {0x408001e0, 0x0, 0x40800950, 0x40800950}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 0
	iCancelStateSave = 0
	pWti = (wti_t *) 0x688160
	pThis = (wtp_t *) 0x687b50
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x68a740
	__func__ = "wtpWorker"
	__PRETTY_FUNCTION__ = "wtpWorker"
#4  0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 3 (process 16284):
#0  0x00002b44aa40bf12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b44aacb4773 in runInput (pThrd=<value optimized out>)
    at imuxsock.c:235
	maxfds = 0
	nfds = <value optimized out>
	i = <value optimized out>
	fd = <value optimized out>
	readfds = {fds_bits = {1, 0 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x6aa6f0
	__func__ = "runInput"
#2  0x000000000041be2d in thrdStarter (arg=0x6a8a40) at threads.c:139
	dbgCALLStaCK_POP_POINT = 0
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x6aa620
	__func__ = "thrdStarter"
	__PRETTY_FUNCTION__ = "thrdStarter"
#3  0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 2 (process 16285):
#0  0x00002b44a9d267eb in read () from /lib/libpthread.so.0
No symbol table info available.
#1  0x00002b44aaeb91c7 in klogLogKMsg () at linux.c:454
	dbgCALLStaCK_POP_POINT = 2
	pdbgFuncDB = (dbgFuncDB_t *) 0x6af730
	__func__ = "klogLogKMsg"
#2  0x00002b44aaeb84a4 in runInput (pThrd=0x6abae0) at imklog.c:208
	dbgCALLStaCK_POP_POINT = 1
	iRet = RS_RET_OK
	pdbgFuncDB = (dbgFuncDB_t *) 0x6af660
	__func__ = "runInput"
#3  0x000000000041be2d in thrdStarter (arg=0x6abae0) at threads.c:139
	dbgCALLStaCK_POP_POINT = 0
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x6aa620
	__func__ = "thrdStarter"
	__PRETTY_FUNCTION__ = "thrdStarter"
#4  0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 1 (process 16283):
#0  0x00002b44aa374ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b44aa376413 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x0000000000415a5f in sigsegvHdlr (signum=6) at debug.c:741
	signame = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
  sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0}
#3  <signal handler called>
No symbol table info available.
#4  0x00002b44aa374ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#5  0x00002b44aa376413 in abort () from /lib/libc.so.6
No symbol table info available.
#6  0x00002b44aa36ddc9 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#7  0x000000000042e550 in msgDestruct (ppThis=0x692a20) at msg.c:273
	dbgCALLStaCK_POP_POINT = 8
	iCancelStateSave = <value optimized out>
	pThis = (msg_t *) 0x2aaaac0008c0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6addf0
	__func__ = "msgDestruct"
	__PRETTY_FUNCTION__ = "msgDestruct"
#8  0x000000000043d346 in actionCallAction (pAction=0x6929c0, 
    pMsg=0x2aaaac000ac0) at action.c:661
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {6891968, 
        1727510324980350523, 6, 4240656, 1090522784, 1090522696, 
        1727510325009710651, 1727653804676349499}, __mask_was_saved = 0}}, 
  __pad = {0x41000f60, 0x0, 0x692820, 0x40b510}}
	__cancel_arg = (void *) 0x692a70
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 7
	iRet = <value optimized out>
	iCancelStateSave = 0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ad2b0
	__func__ = "actionCallAction"
	__PRETTY_FUNCTION__ = "actionCallAction"
#9  0x000000000040b567 in processMsgDoActions (pData=0x6929c0, 
    pParam=0x41000ea0) at syslogd.c:1094
	dbgCALLStaCK_POP_POINT = 6
	iRet = <value optimized out>
	iRetMod = <value optimized out>
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ad180
	__func__ = "processMsgDoActions"
	__PRETTY_FUNCTION__ = "processMsgDoActions"
#10 0x000000000043c0ce in llExecFunc (pThis=0x692820, 
    pFunc=0x40b510 <processMsgDoActions>, pParam=0x41000ea0)
    at linkedlist.c:390
	dbgCALLStaCK_POP_POINT = 5
	iRet = RS_RET_OK
	iRetLL = RS_RET_OK
	pData = (void *) 0x6929c0
	llCookie = (linkedListCookie_t) 0x6920c0
	llCookiePrev = (linkedListCookie_t) 0x0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ad050
	__func__ = "llExecFunc"
	__PRETTY_FUNCTION__ = "llExecFunc"
#11 0x000000000040b0c9 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x2aaaac000ac0) at syslogd.c:1137
	dbgCALLStaCK_POP_POINT = 3
	pMsg = (msg_t *) 0x2aaaac000ac0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6accb0
	__func__ = "msgConsumer"
	__PRETTY_FUNCTION__ = "msgConsumer"
#12 0x000000000042521f in queueConsumerReg (pThis=0x692db0, pWti=0x6a6900, 
    iCancelStateSave=<value optimized out>) at queue.c:1570
	dbgCALLStaCK_POP_POINT = 2
	iRet = RS_RET_OK
	pdbgFuncDB = (dbgFuncDB_t *) 0x6ac8d0
	__func__ = "queueConsumerReg"
	__PRETTY_FUNCTION__ = "queueConsumerReg"
#13 0x0000000000421eb0 in wtiWorker (pThis=0x6a6900) at wti.c:413
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523452, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727510324967767611, 1727653793608105531}, __mask_was_saved = 0}}, 
  __pad = {0x410010d0, 0x0, 0x68a740, 0x19f}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 1
	iCancelStateSave = 0
	t = {tv_sec = 1221174340, tv_nsec = 478220993}
	pWtp = (wtp_t *) 0x680d90
	bInactivityTOOccured = 0
	pdbgFuncDB = (dbgFuncDB_t *) 0x6a6bc0
	__func__ = "wtiWorker"
	__PRETTY_FUNCTION__ = "wtiWorker"
#14 0x00000000004209c2 in wtpWorker (arg=0x6a6900) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523216, 
        1727653261974306363, 47573906921472, 47573906882304, 0, 4096, 
        1727510324930018875, 1727653794260319803}, __mask_was_saved = 0}}, 
  __pad = {0x410011e0, 0x0, 0x0, 0x0}}
	not_first_call = <value optimized out>
	dbgCALLStaCK_POP_POINT = 0
	iCancelStateSave = 0
	pWti = (wti_t *) 0x6a6900
	pThis = (wtp_t *) 0x680d90
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
	pdbgFuncDB = (dbgFuncDB_t *) 0x68a740
	__func__ = "wtpWorker"
	__PRETTY_FUNCTION__ = "wtpWorker"
#15 0x00002b44a9d1ffc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#16 0x00002b44aa4127cd in clone () from /lib/libc.so.6
No symbol table info available.
#17 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) 
-------------- next part --------------
#  /etc/rsyslog.conf	Configuration file for rsyslog v3.
#
#			For more information see 
#			/usr/share/doc/rsyslog-doc/html/rsyslog_conf.html


#################
#### MODULES ####
#################

$ModLoad imuxsock # provides support for local system logging
$ModLoad imklog   # provides kernel logging support (previously done by rklogd) 
#$ModLoad immark  # provides --MARK-- message capability

# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514


###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use default timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf


###############
#### RULES ####
###############

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*			/var/log/auth.log
*.*;auth,authpriv.none		-/var/log/syslog
#cron.*				/var/log/cron.log
daemon.*			-/var/log/daemon.log
kern.*				-/var/log/kern.log
lpr.*				-/var/log/lpr.log
#mail.*				-/var/log/mail.log
user.*				-/var/log/user.log

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info			-/var/log/mail.info
mail.warn			-/var/log/mail.warn
mail.err			/var/log/mail.err

#
# Logging for INN news system.
#
news.crit			/var/log/news/news.crit
news.err			/var/log/news/news.err
news.notice			-/var/log/news/news.notice

#
# Some "catch-all" log files.
#
*.=debug;\
	auth,authpriv.none;\
	news.none;mail.none	-/var/log/debug
*.=info;*.=notice;*.=warn;\
	auth,authpriv.none;\
	cron,daemon.none;\
	mail,news.none		-/var/log/messages

#
# Emergencies are sent to everybody logged in.
#
*.emerg				*

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;\
#	news.=crit;news.=err;news.=notice;\
#	*.=debug;*.=info;\
#	*.=notice;*.=warn	/dev/tty8

# The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
# you must invoke `xconsole' with the `-file' option:
# 
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
#      busy site..
#
daemon.*;mail.*;\
	news.err;\
	*.=debug;*.=info;\
	*.=notice;*.=warn	|/dev/xconsole
-------------- next part --------------
#$ModLoad omrelp 
$WorkDirectory /var/log/rsyslog 
$ActionQueueType LinkedList   # use asynchronous processing
$ActionQueueFileName srvrfwd  # set file name, also enables disk mode
$ActionResumeRetryCount -1    # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
mail.* @@<remote_addr>:514

$ActionExecOnlyIfPreviousIsSuspended on
& /var/log/rsyslog/failover.log
$ActionExecOnlyIfPreviousIsSuspended off

-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Core was generated by `/usr/sbin/rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 23847]
[New process 23849]
[New process 23848]
[New process 23846]
[New process 23845]
#0  0x00002b479d1c3ef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 23845):
#0  0x00002b479d25af12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x000000000040e0c9 in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:2563
	iRet = <value optimized out>
	i = <value optimized out>
	p = <value optimized out>
	num_fds = <value optimized out>
	ch = <value optimized out>
	hent = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0x1, 
    sa_sigaction = 0x1}, sa_mask = {__val = {0 <repeats 16 times>}}, 
  sa_flags = 0, sa_restorer = 0}
	bIsFirstOption = <value optimized out>
	bEOptionWasGiven = <value optimized out>
	bImUxSockLoaded = <value optimized out>
	arg = <value optimized out>
	legacyConfLine = '\0' <repeats 79 times>
#2  0x00002b479d1b01a6 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#3  0x0000000000409609 in _start ()
No locals.

Thread 4 (process 23846):
#0  0x00002b479cb72fad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x0000000000418e00 in wtiWorker (pThis=0x64f4a0) at wti.c:403
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130748, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094035857682333242, 9093894727638318650}, __mask_was_saved = 0}}, 
  __pad = {0x408000d0, 0x0, 0x40800950, 0x40800950}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	t = {tv_sec = 1221135378, tv_nsec = 723151645}
	pWtp = (wtp_t *) 0x64f360
	bInactivityTOOccured = 0
#2  0x0000000000418032 in wtpWorker (arg=<value optimized out>) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1082130512, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094034911474613818, 9093894729333866042}, __mask_was_saved = 0}}, 
  __pad = {0x408001e0, 0x0, 0x40800950, 0x40800950}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	pWti = (wti_t *) 0x64f4a0
	pThis = (wtp_t *) 0x64f360
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#3  0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 3 (process 23848):
#0  0x00002b479d25af12 in select () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b479db01413 in runInput (pThrd=<value optimized out>)
    at imuxsock.c:235
	maxfds = 0
	nfds = <value optimized out>
	i = <value optimized out>
	fd = <value optimized out>
	readfds = {fds_bits = {1, 0 <repeats 15 times>}}
#2  0x0000000000416420 in thrdStarter (arg=0x66bd70) at threads.c:139
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#3  0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 2 (process 23849):
#0  0x00002b479cb757eb in read () from /lib/libpthread.so.0
No symbol table info available.
#1  0x00002b479dd05c5f in klogLogKMsg () at linux.c:454
No locals.
#2  0x00002b479dd0517c in runInput (pThrd=0x66c1f0) at imklog.c:208
	iRet = <value optimized out>
#3  0x0000000000416420 in thrdStarter (arg=0x66c1f0) at threads.c:139
	iRet = <value optimized out>
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#4  0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 1 (process 23847):
#0  0x00002b479d1c3ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b479d1c5413 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x0000000000411abf in sigsegvHdlr (signum=6) at debug.c:741
	signame = <value optimized out>
	sigAct = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
  sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0}
#3  <signal handler called>
No symbol table info available.
#4  0x00002b479d1c3ef5 in raise () from /lib/libc.so.6
No symbol table info available.
#5  0x00002b479d1c5413 in abort () from /lib/libc.so.6
No symbol table info available.
#6  0x00002b479d2003e8 in __libc_message () from /lib/libc.so.6
No symbol table info available.
#7  0x00002b479d205968 in malloc_printerr () from /lib/libc.so.6
No symbol table info available.
#8  0x00002b479d207a76 in free () from /lib/libc.so.6
No symbol table info available.
#9  0x0000000000420f2d in msgDestruct (ppThis=0x6532a0) at msg.c:284
	iCancelStateSave = 0
	pThis = (msg_t *) 0x2aaab401e480
#10 0x000000000042a797 in actionCallAction (pAction=0x653240, 
    pMsg=0x2aaab0020620) at action.c:661
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090522832, 
        9093895273491594810, 6631600, 1090522832, 4238944, 1090522856, 
        9094038209632009786, 9093894735514959418}, __mask_was_saved = 0}}, 
  __pad = {0x41000f70, 0x0, 0xbf11, 0x0}}
	__cancel_arg = (void *) 0x6532f0
	not_first_call = <value optimized out>
	iRet = <value optimized out>
	iCancelStateSave = 0
#11 0x000000000040ae79 in processMsgDoActions (pData=0x5d25, pParam=0x41000ed0)
    at syslogd.c:1094
	iRet = <value optimized out>
	iRetMod = <value optimized out>
#12 0x0000000000429b97 in llExecFunc (pThis=0x6530b0, 
    pFunc=0x40ae60 <processMsgDoActions>, pParam=0x41000ed0)
    at linkedlist.c:390
	iRet = RS_RET_OK
	llCookie = (linkedListCookie_t) 0x652c60
	llCookiePrev = (linkedListCookie_t) 0x0
#13 0x000000000040aab0 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=<value optimized out>) at syslogd.c:1137
	pMsg = (msg_t *) 0x2aaab0020620
#14 0x000000000041aa31 in queueConsumerReg (pThis=0x656980, pWti=0x64bcf0, 
    iCancelStateSave=<value optimized out>) at queue.c:1570
	iRet = RS_RET_OK
#15 0x0000000000418e6f in wtiWorker (pThis=0x64bcf0) at wti.c:413
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523452, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094038209713798714, 9093894727638318650}, __mask_was_saved = 0}}, 
  __pad = {0x410010d0, 0x0, 0x0, 0x0}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	t = {tv_sec = 1221135378, tv_nsec = 595602238}
	pWtp = (wtp_t *) 0x64bbb0
	bInactivityTOOccured = 0
#16 0x0000000000418032 in wtpWorker (arg=<value optimized out>) at wtp.c:417
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1090523216, 
        9093895273491594810, 47586571945984, 47586571906816, 0, 4096, 
        9094038210546368058, 9093894729333866042}, __mask_was_saved = 0}}, 
  __pad = {0x410011e0, 0x0, 0x0, 0x0}}
	not_first_call = <value optimized out>
	iCancelStateSave = 0
	pWti = (wti_t *) 0x64bcf0
	pThis = (wtp_t *) 0x64bbb0
	sigSet = {__val = {18446744067267100671, 
    18446744073709551615 <repeats 15 times>}}
#17 0x00002b479cb6efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#18 0x00002b479d2617cd in clone () from /lib/libc.so.6
No symbol table info available.
#19 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) quit

From hks.private at gmail.com  Mon Sep 15 19:06:23 2008
From: hks.private at gmail.com ((private) HKS)
Date: Mon, 15 Sep 2008 13:06:23 -0400
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
Message-ID: <ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>

What version of rsyslog is this?

-HKS

On Fri, Sep 12, 2008 at 6:40 AM, Lorenzo M. Catucci
<lorenzo at sancho.ccd.uniroma2.it> wrote:
> The system is a dual processor / quad core Xeon E5335 running a 64 bit
> debian lenny distribution; I've enabled both debug and rtinst configure,
> and installed an unstripped binary; I'm attaching the full backtrace here.
>
> the system should act as a client to a remote syslog server; I'm enclosing
> the conf files too.
>
> In the previous attempts (before enabling rtinst and debug), I got lines
> like "rsyslogd: double free or corruption (!prev): 0x0000000000674c50"
> in the failover log (corresponding to the _nodebug backtrace); this last
> time, the line I've got is
>
> "msg.c:273: msgDestruct: Assertion `(unsigned) ((obj_t*)
>           (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed."
>
> and the double free detector didn't fire.
>
> I'm really at a loss now: I've been lured into experimenting rsyslog from
> the high level architectural description being this clean and seemingly
> powerful, but now I fear I still cannot rely on this logger in production.
>
> Eager to help in debugging, sincerely yours
>
>        lorenzo
>
>
>
> +-------------------------+----------------------------------------------+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
> +-------------------------+----------------------------------------------+
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>
>


From david at lang.hm  Tue Sep 16 06:44:30 2008
From: david at lang.hm (david at lang.hm)
Date: Mon, 15 Sep 2008 21:44:30 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm>
	<1221462796.2682.28.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm>
	<1221463183.2682.32.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm>
	<1221463684.2682.37.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm>
	<1221464240.2682.41.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm>
	<1221467031.2682.48.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm>
	<1221469046.2682.50.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm>
	<1221470899.2682.60.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm>
	<1221472634.2682.62.camel@rgf9dev.intern.adiscon.com>
	<1221473625.2682.65.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>
Message-ID: <alpine.DEB.1.10.0809152143060.17326@asgard.lang.hm>

On Mon, 15 Sep 2008, david at lang.hm wrote:

> On Mon, 15 Sep 2008, Rainer Gerhards wrote:
>
>> side-note: do you mind if we concentrate on the performance issue first
>> and keep an eye on this here (as a secondary goal) while we do it? I
>> think that would enable me to address both most quickly (I can add
>> instrumentation code/checks while I modify the file output). There may
>> come a time when reversing priorities makes sense, but for now I think
>> this would be the best way...
>
> no problem.

an interesting tidbit, once I started the performance testing with name 
lookups turned off I haven't had a failure of the rotation.

I left it running overnight under heavy load, so I'll see how far it got 
in the morning.

David Lang

>> Rainer
>> On Mon, 2008-09-15 at 11:57 +0200, Rainer Gerhards wrote:
>>> mhh... maybe the valgrind version is too old (I am using 3.3.1) - it
>>> still has no source line information. Without that, it has very little
>>> value. OK, I'll look at some other ways.
>>
>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Tue Sep 16 07:17:02 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 16 Sep 2008 07:17:02 +0200
Subject: [rsyslog] how to best rotate files
In-Reply-To: <alpine.DEB.1.10.0809152143060.17326@asgard.lang.hm>
References: <alpine.DEB.1.10.0809142308490.19489@asgard.lang.hm><1221462796.2682.28.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150016410.19489@asgard.lang.hm><1221463183.2682.32.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150025380.19489@asgard.lang.hm><1221463684.2682.37.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150033470.19489@asgard.lang.hm><1221464240.2682.41.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150047450.19489@asgard.lang.hm><1221467031.2682.48.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150130430.17326@asgard.lang.hm><1221469046.2682.50.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150204140.17326@asgard.lang.hm><1221470899.2682.60.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150244010.17326@asgard.lang.hm><1221472634.2682.62.camel@rgf9dev.intern.adiscon.com><1221473625.2682.65.camel@rgf9dev.intern.adiscon.com><alpine.DEB.1.10.0809150414290.17326@asgard.lang.hm>
	<alpine.DEB.1.10.0809152143060.17326@asg ard.lang.hm>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F147@grfint2.intern.adiscon.com>

> an interesting tidbit, once I started the performance testing with
name
> lookups turned off I haven't had a failure of the rotation.
> 
> I left it running overnight under heavy load, so I'll see how far it
> got
> in the morning.

Oh, that's very interesting.

Looking forward to the results.

Rainer


From lorenzo at sancho.ccd.uniroma2.it  Tue Sep 16 09:50:11 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Tue, 16 Sep 2008 09:50:11 +0200 (CEST)
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
	<ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>

On Mon, 15 Sep 2008, (private) HKS wrote:

> What version of rsyslog is this?
>
> -HKS
>

At first it was with pristine debian's 3.18.2; I later tried upgrading to 
3.18.3 but the problem persisted.

Sorry for confusion.

Thank you,

 	lorenzo


From hks.private at gmail.com  Tue Sep 16 15:52:49 2008
From: hks.private at gmail.com ((private) HKS)
Date: Tue, 16 Sep 2008 09:52:49 -0400
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it>
	<ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com>
	<alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>
Message-ID: <ac9ded160809160652v7a6e0598q37a17452523d270a@mail.gmail.com>

This looks similar to the issue I reported at
http://kb.monitorware.com/random-daemon-stops-t8626.html

I haven't been able to reproduce it with any frequency, so hopefully
your data will be what Rainer needs to track this down.

-HKS


On Tue, Sep 16, 2008 at 3:50 AM, Lorenzo M. Catucci
<lorenzo at sancho.ccd.uniroma2.it> wrote:
> On Mon, 15 Sep 2008, (private) HKS wrote:
>
>> What version of rsyslog is this?
>>
>> -HKS
>>
>
> At first it was with pristine debian's 3.18.2; I later tried upgrading to
> 3.18.3 but the problem persisted.
>
> Sorry for confusion.
>
> Thank you,
>
>        lorenzo
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Tue Sep 16 15:54:00 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 16 Sep 2008 15:54:00 +0200
Subject: [rsyslog] rsyslog frequent crashes
In-Reply-To: <ac9ded160809160652v7a6e0598q37a17452523d270a@mail.gmail.com>
References: <alpine.DEB.1.10.0809121148120.21244@sancho.ccd.uniroma2.it><ac9ded160809151006x3f0fe485ke5e6830cba759a66@mail.gmail.com><alpine.DEB.1.10.0809160944240.3740@ronzinante.ccd.uniroma2.it>
	<ac9ded160809160652v7a6e0598q37a17452523d270a@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F155@grfint2.intern.adiscon.com>

Sorry for not replying yet. I am currently very busy with another
activity. Though not a crash, I'd like to finish that first, before I
lose the context that was so costly to achive ;)

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of (private) HKS
> Sent: Tuesday, September 16, 2008 3:53 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog frequent crashes
> 
> This looks similar to the issue I reported at
> http://kb.monitorware.com/random-daemon-stops-t8626.html
> 
> I haven't been able to reproduce it with any frequency, so hopefully
> your data will be what Rainer needs to track this down.
> 
> -HKS
> 
> 
> On Tue, Sep 16, 2008 at 3:50 AM, Lorenzo M. Catucci
> <lorenzo at sancho.ccd.uniroma2.it> wrote:
> > On Mon, 15 Sep 2008, (private) HKS wrote:
> >
> >> What version of rsyslog is this?
> >>
> >> -HKS
> >>
> >
> > At first it was with pristine debian's 3.18.2; I later tried
> upgrading to
> > 3.18.3 but the problem persisted.
> >
> > Sorry for confusion.
> >
> > Thank you,
> >
> >        lorenzo
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> >
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From david at lang.hm  Tue Sep 16 19:03:54 2008
From: david at lang.hm (david at lang.hm)
Date: Tue, 16 Sep 2008 10:03:54 -0700 (PDT)
Subject: [rsyslog] how to best rotate files
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F147@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F147@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809161002240.21981@asgard.lang.hm>

On Tue, 16 Sep 2008, Rainer Gerhards wrote:

>> an interesting tidbit, once I started the performance testing with
> name
>> lookups turned off I haven't had a failure of the rotation.
>>
>> I left it running overnight under heavy load, so I'll see how far it
>> got
>> in the morning.
>
> Oh, that's very interesting.
>
> Looking forward to the results.

a little more detail.

if I do an strace of a thread when I do the HUP, that thread does not 
close properly and never releases the file (I think the same thing was 
happening when I tried to run it under valgrind)

with name lookups disabled it ran overnight rotating once a min 
(processing 40,000 requests/sec)

David Lang


From rgerhards at hq.adiscon.com  Wed Sep 17 15:42:16 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 17 Sep 2008 15:42:16 +0200
Subject: [rsyslog] Change to mark message algo
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F16A@grfint2.intern.adiscon.com>

Hi,

initially driven by a performance discussion, the question has come up
when mark messages should be processed.

The current implementation is (by design) close to what sysklogd does:
marks are generated in intervals for all outputs (files and such) and
are send to each of the outputs. The outputs process the mark message if
the output was idle for at least half the past interval (otherwise, the
mark is simply ignored).

So, looking from an individual output's point of view, mark messages do
not happen at precise intervals after the last message was processed by
the output, but seem to be rather random from that POV.

In rsyslog, I use the time the message was handed over to the output as
the time of last processing. Some (namely David Lang in the link below)
can argue that this is incorrect, or at least not the only way to handle
it valid. The argument is that the time of message reception is the one
to look at when processing marks. After some hesitation, I see some
logic in this definition and I am very tempted to change rsyslog to use
that definition. Obviously, this can result in different mark handling
than to what we have today. Usually, though, things are not really
different, but they may become quite different if a messages was stuck
in a queue for some time.

I invite you to have a look at the relevant forum discussion. This is a
good entry point:

http://kb.monitorware.com/rsyslog-performance-t8691-30.html#p13825

Please let me know if you have any concerns. If I do not hear anything,
I'll change rsyslog to use the reception timestamp. This also has
performance benefit.

Thanks,
Rainer


From hks.private at gmail.com  Wed Sep 17 16:41:22 2008
From: hks.private at gmail.com ((private) HKS)
Date: Wed, 17 Sep 2008 10:41:22 -0400
Subject: [rsyslog] Change to mark message algo
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F16A@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16A@grfint2.intern.adiscon.com>
Message-ID: <ac9ded160809170741t29870421g9f68c5b0e176cbee@mail.gmail.com>

No concerns here - that makes significantly more sense to an
undereducated sysadmin.

-HKS

On Wed, Sep 17, 2008 at 9:42 AM, Rainer Gerhards
<rgerhards at hq.adiscon.com> wrote:
> Hi,
>
> initially driven by a performance discussion, the question has come up
> when mark messages should be processed.
>
> The current implementation is (by design) close to what sysklogd does:
> marks are generated in intervals for all outputs (files and such) and
> are send to each of the outputs. The outputs process the mark message if
> the output was idle for at least half the past interval (otherwise, the
> mark is simply ignored).
>
> So, looking from an individual output's point of view, mark messages do
> not happen at precise intervals after the last message was processed by
> the output, but seem to be rather random from that POV.
>
> In rsyslog, I use the time the message was handed over to the output as
> the time of last processing. Some (namely David Lang in the link below)
> can argue that this is incorrect, or at least not the only way to handle
> it valid. The argument is that the time of message reception is the one
> to look at when processing marks. After some hesitation, I see some
> logic in this definition and I am very tempted to change rsyslog to use
> that definition. Obviously, this can result in different mark handling
> than to what we have today. Usually, though, things are not really
> different, but they may become quite different if a messages was stuck
> in a queue for some time.
>
> I invite you to have a look at the relevant forum discussion. This is a
> good entry point:
>
> http://kb.monitorware.com/rsyslog-performance-t8691-30.html#p13825
>
> Please let me know if you have any concerns. If I do not hear anything,
> I'll change rsyslog to use the reception timestamp. This also has
> performance benefit.
>
> Thanks,
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>


From rgerhards at hq.adiscon.com  Wed Sep 17 17:57:25 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 17 Sep 2008 17:57:25 +0200
Subject: [rsyslog] abort cases
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>

Hi,

just an update. While I have been silent, I am looking at the aborts
that were recently reported. I think they are related to threading
issues. I am reviewing some code and conducting some tests. This
unfortunately takes some time. I just wanted to let you know that
something is happening ;)

Interestingly, this seems to play nicely with the performance
optimization effort. It may even be that removing the cause could
improve performance, but it is too early to be sure it will... I have
not yet identified a sure cause.

I will keep you updated and post questions when I have them.

Thanks,
Rainer


From lorenzo at sancho.ccd.uniroma2.it  Wed Sep 17 18:46:22 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Wed, 17 Sep 2008 18:46:22 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>

On Wed, 17 Sep 2008, Rainer Gerhards wrote:

> Hi,
>
> just an update. While I have been silent, I am looking at the aborts
> that were recently reported. I think they are related to threading
> issues. I am reviewing some code and conducting some tests. This
> unfortunately takes some time. I just wanted to let you know that
> something is happening ;)
>

In the meanwhile, I've compiled once more with --enable-valgrind and I'm 
running the daemon under valgrind. Since with no other change the daemon 
is still running, while it usually didn't last more than 12 hours, it 
seems the timing variation does somewhat cure the symptoms.

>
> Interestingly, this seems to play nicely with the performance
> optimization effort. It may even be that removing the cause could
> improve performance, but it is too early to be sure it will... I have
> not yet identified a sure cause.
>
> I will keep you updated and post questions when I have them.
>

We are all waiting for you questions... in the hope we can be of any help!

Thank you, yours

 	lorenzo


From rgerhards at hq.adiscon.com  Wed Sep 17 18:49:01 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 17 Sep 2008 18:49:01 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>

> > just an update. While I have been silent, I am looking at the aborts
> > that were recently reported. I think they are related to threading
> > issues. I am reviewing some code and conducting some tests. This
> > unfortunately takes some time. I just wanted to let you know that
> > something is happening ;)
> >
> 
> In the meanwhile, I've compiled once more with --enable-valgrind and
> I'm
> running the daemon under valgrind. Since with no other change the
> daemon
> is still running, while it usually didn't last more than 12 hours, it
> seems the timing variation does somewhat cure the symptoms.

This is what I am thinking, too. I am running it under helgrind. If you
do that, you'll see a couple of warnings, most have been found to be
harmless by previous analysis. Anyhow, I am re-doing the analysis now
(what takes quite a bit of time). I am just telling you so that you
don't wonder when you see so many warnings. I think there is even a
discussion thread somewhere telling why this is. Mostly it is cases
where we do not really need sync... or so I thought ;)

Rainer


From lorenzo at sancho.ccd.uniroma2.it  Wed Sep 17 19:36:42 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Wed, 17 Sep 2008 19:36:42 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>

>> is still running, while it usually didn't last more than 12 hours, it
>> seems the timing variation does somewhat cure the symptoms.
>
> This is what I am thinking, too. I am running it under helgrind. If you
> do that, you'll see a couple of warnings, most have been found to be
> harmless by previous analysis. Anyhow, I am re-doing the analysis now
> (what takes quite a bit of time). I am just telling you so that you
> don't wonder when you see so many warnings. I think there is even a
> discussion thread somewhere telling why this is. Mostly it is cases
> where we do not really need sync... or so I thought ;)
>

Just to help me understand, do you think val-grinding this time is 
near-to-useless, and I'd better restart the daemon under helgrind, or you 
prefer I continue valgrinding while you helgrind?

I feared uttering the words "race condition" would have been doing just 
like the patient telling the doctor what he does want to hear as a 
dyagnosis... now that I see you are looking for missing syncs I think we 
share this gut feeling... Please let me know if I can help more, since 
I'm somewhat in the hope this dreaded shared memory 8 way system could 
very well shake the races... As a matter of fact, the destination server 
is a twin-brother of the source one, and is running (and logging to 
postgresql) without any hiccup since started-up.

Thank you very much, yours,

 	lorenzo


From rgerhards at hq.adiscon.com  Thu Sep 18 09:23:11 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 09:23:11 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
Message-ID: <1221722591.2682.137.camel@rgf9dev.intern.adiscon.com>

On Wed, 2008-09-17 at 19:36 +0200, Lorenzo M. Catucci wrote:
> >> is still running, while it usually didn't last more than 12 hours, it
> >> seems the timing variation does somewhat cure the symptoms.
> >
> > This is what I am thinking, too. I am running it under helgrind. If you
> > do that, you'll see a couple of warnings, most have been found to be
> > harmless by previous analysis. Anyhow, I am re-doing the analysis now
> > (what takes quite a bit of time). I am just telling you so that you
> > don't wonder when you see so many warnings. I think there is even a
> > discussion thread somewhere telling why this is. Mostly it is cases
> > where we do not really need sync... or so I thought ;)
> >
> 
> Just to help me understand, do you think val-grinding this time is 
> near-to-useless, and I'd better restart the daemon under helgrind, or you 
> prefer I continue valgrinding while you helgrind?

>From a pragmatical POV: if running it under valgrind helps ease the
immediate problem, please do that. I suspect valgrind will not report
anything, but if it does, that would probably be very interesting.

Using valgrind's helgrind tool does not make sense to you, because it
emits lots of message, which need to be interpreted by someone with deep
knowledge of the code. This is what I am looking at.

> I feared uttering the words "race condition" would have been doing just 
> like the patient telling the doctor what he does want to hear as a 
> dyagnosis... now that I see you are looking for missing syncs I think we 
> share this gut feeling... 

Yes, definitely. There is also one not directly technical reason that
makes me believe this: we had almost no serious issue with rsyslog since
the highly parallel multi-threading engine was introduced. I was a bit
astonished, because doing such a complex beast absolutely correctly in
the first place - even with the lots of testing it received in my
environment - is something I only very seldomly hear about. Now, out of
the sudden, multiple bug reports, all pointing into the same direction
come in. I now conclude that many folks were hesitant to actually use
the new version and now that time has passed, deployments into high
demand environments begin. Unfortunately, I do not have funding for the
high end machines and the amount of time required to do all these high
end testing after the release was finished (and even if I had, I'd
probably still not seen one issue or the other). So it sounds somewhat
logical to me that we have now begun to actually do the firedrill for
the new highly parallel processing part. And that, of course, points
into issues with thread execution order, aka race conditions ;) This
direction would also explain why the issues did not come up earlier
(with reasoning given above).

> Please let me know if I can help more, since 
> I'm somewhat in the hope this dreaded shared memory 8 way system could 
> very well shake the races... As a matter of fact, the destination server 
> is a twin-brother of the source one, and is running (and logging to 
> postgresql) without any hiccup since started-up.

All you can do at this time is being patient. I am reviewing the code.
The worker thread pools and all this logic is highly complex. I must
make sure that I have again a very tight grip on it, review all the
subtle cases I came along and then look at the helgrind output and other
diagnostic sources to see where the issue is. Probably then it would be
useful to have a gdb backtrace of an aborted process (or the more the
better), but my experience with these kinds of problems is that good
analysis is more likely to solve them than any captured real-time data.

As soon as I have a question, I'll post. Should you notice something
that you find interesting, please post. Ignoring something is easy, not
knowing something that may potentially help would be bad ;)

Rainer



From rgerhards at hq.adiscon.com  Thu Sep 18 09:35:17 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 09:35:17 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
Message-ID: <1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>

> Please let me know if I can help more, since 
> I'm somewhat in the hope this dreaded shared memory 8 way system could 
> very well shake the races... As a matter of fact, the destination server 
> is a twin-brother of the source one, and is running (and logging to 
> postgresql) without any hiccup since started-up.

Oh, I forgot, there is one thing you could actually do: I do not intend
to do any threading changes to the current stable. This may sound silly,
because it looks like a bug, but I expect that a lot of changes need to
be done, especially to make helgrind happy (so that it can be used). The
amount of changes I expect are far too intrusive for the stable. After
all, the majority of folks do not experience the bug. So the "fix" will
become part of the current devel.

As such, it would be very useful for me if you could try out the latest
devel versions as I modify them. It would be really great if you could
pull them from my git archive at git.adiscon.com/git/rsyslog.git

The same to everyone else interested in this work ;)

Rainer



From rgerhards at hq.adiscon.com  Thu Sep 18 09:59:15 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 09:59:15 +0200
Subject: [rsyslog] rsyslog 3.18.4 released
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F170@grfint2.intern.adiscon.com>

Hi all,

I have just released rsyslog 3.18.4, a member of the v3-stable branch.
This is a bugfixing release. It contains a number of fixes, most
importantly one that could cause undesired message discarding when the
queue is nearly full. This was caused by an invalid default enabling
discard-on-queue-full when this was not explicitly configured. There are
also other fixes. All users of the v3-stable branch are advised to
update to this release.

Changelog with full details:
http://www.rsyslog.com/Article277.phtml

Download:
http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-131.phtml

I hope this release is useful. As always, feedback is greatly
appreciated.
Rainer


From rgerhards at hq.adiscon.com  Thu Sep 18 10:14:35 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 10:14:35 +0200
Subject: [rsyslog] autoconf support for atomic operations
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>

Hi all,

in my effort to get a clean helgrind output (and to solve the stability
problems that recently showed up, I am going to re-enable support for
atomic operations). Unfortunately, the following post is still correct
and I do not know how to use autotools to check for the ability of
atomic operations:

http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html

While the post contains a potentially good pointer to a solution, I do
not know how to apply it to rsyslog ;) If anyone could lend me a helping
hand, that would be great. In the meantime, I'll simply go and make a
--enable-atomic ./configure switch - that's IMHO the best solution given
the current state of affairs.

Rainer


From rgerhards at hq.adiscon.com  Thu Sep 18 10:35:27 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 10:35:27 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>

Hold on... I should have searched first, then asked. Looks like I found
a solution. Will post more later.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Thursday, September 18, 2008 10:15 AM
> To: rsyslog-users
> Subject: [rsyslog] autoconf support for atomic operations
> 
> Hi all,
> 
> in my effort to get a clean helgrind output (and to solve the
stability
> problems that recently showed up, I am going to re-enable support for
> atomic operations). Unfortunately, the following post is still correct
> and I do not know how to use autotools to check for the ability of
> atomic operations:
> 
> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> 
> While the post contains a potentially good pointer to a solution, I do
> not know how to apply it to rsyslog ;) If anyone could lend me a
> helping
> hand, that would be great. In the meantime, I'll simply go and make a
> --enable-atomic ./configure switch - that's IMHO the best solution
> given
> the current state of affairs.
> 
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From rgerhards at hq.adiscon.com  Thu Sep 18 10:50:38 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 10:50:38 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>

Yes, looks like it works. This is what I did:

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123c
83383ba256c4e67679c8d

Comments are appreciated.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Thursday, September 18, 2008 10:35 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] autoconf support for atomic operations
> 
> Hold on... I should have searched first, then asked. Looks like I
found
> a solution. Will post more later.
> 
> Rainer
> 
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> > Sent: Thursday, September 18, 2008 10:15 AM
> > To: rsyslog-users
> > Subject: [rsyslog] autoconf support for atomic operations
> >
> > Hi all,
> >
> > in my effort to get a clean helgrind output (and to solve the
> stability
> > problems that recently showed up, I am going to re-enable support
for
> > atomic operations). Unfortunately, the following post is still
> correct
> > and I do not know how to use autotools to check for the ability of
> > atomic operations:
> >
> > http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> >
> > While the post contains a potentially good pointer to a solution, I
> do
> > not know how to apply it to rsyslog ;) If anyone could lend me a
> > helping
> > hand, that would be great. In the meantime, I'll simply go and make
a
> > --enable-atomic ./configure switch - that's IMHO the best solution
> > given
> > the current state of affairs.
> >
> > Rainer
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From lorenzo at sancho.ccd.uniroma2.it  Thu Sep 18 11:08:29 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Thu, 18 Sep 2008 11:08:29 +0200 (CEST)
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>

Rainer,
 	I cloned your repo with

$ git clone http://git.adiscon.com/git/rsyslog.git rsyslog.git

now, I'm completely clueless about git, but I'm unable to find the 
helgrind branch with

$ git branch -r

I tried doing a git pull, but all I got was an "Already up-to-date." 
reply...

Should I simply wait for the helgrind branch to get merged into master, or 
there is some way to pull the new branch here?

Thank you very much, yours

 	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

On Thu, 18 Sep 2008, Rainer Gerhards wrote:

> Yes, looks like it works. This is what I did:
>
> http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123c
> 83383ba256c4e67679c8d
>
> Comments are appreciated.
>
> Rainer
>
>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
>> Sent: Thursday, September 18, 2008 10:35 AM
>> To: rsyslog-users
>> Subject: Re: [rsyslog] autoconf support for atomic operations
>>
>> Hold on... I should have searched first, then asked. Looks like I
> found
>> a solution. Will post more later.
>>
>> Rainer
>>
>>> -----Original Message-----
>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
>>> Sent: Thursday, September 18, 2008 10:15 AM
>>> To: rsyslog-users
>>> Subject: [rsyslog] autoconf support for atomic operations
>>>
>>> Hi all,
>>>
>>> in my effort to get a clean helgrind output (and to solve the
>> stability
>>> problems that recently showed up, I am going to re-enable support
> for
>>> atomic operations). Unfortunately, the following post is still
>> correct
>>> and I do not know how to use autotools to check for the ability of
>>> atomic operations:
>>>
>>> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
>>>
>>> While the post contains a potentially good pointer to a solution, I
>> do
>>> not know how to apply it to rsyslog ;) If anyone could lend me a
>>> helping
>>> hand, that would be great. In the meantime, I'll simply go and make
> a
>>> --enable-atomic ./configure switch - that's IMHO the best solution
>>> given
>>> the current state of affairs.
>>>
>>> Rainer
>>> _______________________________________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>

From rgerhards at hq.adiscon.com  Thu Sep 18 11:10:13 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 11:10:13 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F175@grfint2.intern.adiscon.com>

Hi Lorenzo,

I pushed the helgrind branch only a few minutes ago. It may be worth retrying

$ git pull
$ git branch -r

In any case, I expect that I merge the helgrind branch into master as soon as possible (which may mean quite a while, though).

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Lorenzo M. Catucci
> Sent: Thursday, September 18, 2008 11:08 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] autoconf support for atomic operations
> 
> Rainer,
>  	I cloned your repo with
> 
> $ git clone http://git.adiscon.com/git/rsyslog.git rsyslog.git
> 
> now, I'm completely clueless about git, but I'm unable to find the
> helgrind branch with
> 
> $ git branch -r
> 
> I tried doing a git pull, but all I got was an "Already up-to-date."
> reply...
> 
> Should I simply wait for the helgrind branch to get merged into master,
> or
> there is some way to pull the new branch here?
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+
> 
> On Thu, 18 Sep 2008, Rainer Gerhards wrote:
> 
> > Yes, looks like it works. This is what I did:
> >
> >
> http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123
> c
> > 83383ba256c4e67679c8d
> >
> > Comments are appreciated.
> >
> > Rainer
> >
> >> -----Original Message-----
> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >> Sent: Thursday, September 18, 2008 10:35 AM
> >> To: rsyslog-users
> >> Subject: Re: [rsyslog] autoconf support for atomic operations
> >>
> >> Hold on... I should have searched first, then asked. Looks like I
> > found
> >> a solution. Will post more later.
> >>
> >> Rainer
> >>
> >>> -----Original Message-----
> >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >>> Sent: Thursday, September 18, 2008 10:15 AM
> >>> To: rsyslog-users
> >>> Subject: [rsyslog] autoconf support for atomic operations
> >>>
> >>> Hi all,
> >>>
> >>> in my effort to get a clean helgrind output (and to solve the
> >> stability
> >>> problems that recently showed up, I am going to re-enable support
> > for
> >>> atomic operations). Unfortunately, the following post is still
> >> correct
> >>> and I do not know how to use autotools to check for the ability of
> >>> atomic operations:
> >>>
> >>> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> >>>
> >>> While the post contains a potentially good pointer to a solution, I
> >> do
> >>> not know how to apply it to rsyslog ;) If anyone could lend me a
> >>> helping
> >>> hand, that would be great. In the meantime, I'll simply go and make
> > a
> >>> --enable-atomic ./configure switch - that's IMHO the best solution
> >>> given
> >>> the current state of affairs.
> >>>
> >>> Rainer
> >>> _______________________________________________
> >>> rsyslog mailing list
> >>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> >


From rgerhards at hq.adiscon.com  Thu Sep 18 12:24:29 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 12:24:29 +0200
Subject: [rsyslog] autoconf support for atomic operations
In-Reply-To: <alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F171@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F172@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F174@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181059430.4060@ronzinante.ccd.uniroma2.it>
Message-ID: <1221733469.2682.146.camel@rgf9dev.intern.adiscon.com>

Lorenzo and all,

much quicker than I expected, I found one quirk that could - though very
unlikely - be at the root of all these problems. I have done a first
fix, which can be found here:

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=4c96ebdcfe075e80810b01257cf21ea1c9b3ec0e

I'd appreciate if you could pull the helgrind branch and see if
something changes. If you can't pull it for whatever reason, a snapshot
is available via the gitweb:

http://git.adiscon.com/?p=rsyslog.git;a=snapshot;h=4c96ebdcfe075e80810b01257cf21ea1c9b3ec0e;sf=tgz

Rainer

On Thu, 2008-09-18 at 11:08 +0200, Lorenzo M. Catucci wrote:
> Rainer,
>  	I cloned your repo with
> 
> $ git clone http://git.adiscon.com/git/rsyslog.git rsyslog.git
> 
> now, I'm completely clueless about git, but I'm unable to find the 
> helgrind branch with
> 
> $ git branch -r
> 
> I tried doing a git pull, but all I got was an "Already up-to-date." 
> reply...
> 
> Should I simply wait for the helgrind branch to get merged into master, or 
> there is some way to pull the new branch here?
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> 
> +-------------------------+----------------------------------------------+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
> +-------------------------+----------------------------------------------+
> 
> On Thu, 18 Sep 2008, Rainer Gerhards wrote:
> 
> > Yes, looks like it works. This is what I did:
> >
> > http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=988989e49ef8639123c
> > 83383ba256c4e67679c8d
> >
> > Comments are appreciated.
> >
> > Rainer
> >
> >> -----Original Message-----
> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >> Sent: Thursday, September 18, 2008 10:35 AM
> >> To: rsyslog-users
> >> Subject: Re: [rsyslog] autoconf support for atomic operations
> >>
> >> Hold on... I should have searched first, then asked. Looks like I
> > found
> >> a solution. Will post more later.
> >>
> >> Rainer
> >>
> >>> -----Original Message-----
> >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >>> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> >>> Sent: Thursday, September 18, 2008 10:15 AM
> >>> To: rsyslog-users
> >>> Subject: [rsyslog] autoconf support for atomic operations
> >>>
> >>> Hi all,
> >>>
> >>> in my effort to get a clean helgrind output (and to solve the
> >> stability
> >>> problems that recently showed up, I am going to re-enable support
> > for
> >>> atomic operations). Unfortunately, the following post is still
> >> correct
> >>> and I do not know how to use autotools to check for the ability of
> >>> atomic operations:
> >>>
> >>> http://lists.adiscon.net/pipermail/rsyslog/2008-April/000728.html
> >>>
> >>> While the post contains a potentially good pointer to a solution, I
> >> do
> >>> not know how to apply it to rsyslog ;) If anyone could lend me a
> >>> helping
> >>> hand, that would be great. In the meantime, I'll simply go and make
> > a
> >>> --enable-atomic ./configure switch - that's IMHO the best solution
> >>> given
> >>> the current state of affairs.
> >>>
> >>> Rainer
> >>> _______________________________________________
> >>> rsyslog mailing list
> >>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> >
> _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Thu Sep 18 12:55:23 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 12:55:23 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>

Please also read this:

http://kb.monitorware.com/post13847.html#p13847

It has some other interesting findings which leads me to believe I have
really found the culprit (or at least one of them ;)).

Feedback appreciated.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Thursday, September 18, 2008 9:35 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] abort cases
> 
> > Please let me know if I can help more, since
> > I'm somewhat in the hope this dreaded shared memory 8 way system
> could
> > very well shake the races... As a matter of fact, the destination
> server
> > is a twin-brother of the source one, and is running (and logging to
> > postgresql) without any hiccup since started-up.
> 
> Oh, I forgot, there is one thing you could actually do: I do not
intend
> to do any threading changes to the current stable. This may sound
> silly,
> because it looks like a bug, but I expect that a lot of changes need
to
> be done, especially to make helgrind happy (so that it can be used).
> The
> amount of changes I expect are far too intrusive for the stable. After
> all, the majority of folks do not experience the bug. So the "fix"
will
> become part of the current devel.
> 
> As such, it would be very useful for me if you could try out the
latest
> devel versions as I modify them. It would be really great if you could
> pull them from my git archive at git.adiscon.com/git/rsyslog.git
> 
> The same to everyone else interested in this work ;)
> 
> Rainer
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From r.bhatia at ipax.at  Thu Sep 18 13:46:28 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 18 Sep 2008 13:46:28 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
Message-ID: <48D23F94.9060904@ipax.at>

hi,

as i am quite frequently using gossamer-threads to search mailinglists
such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
could too move to gossamer-threads.

from the bottom of [1] i take:
> 
> Interested in having your list archived? Contact lists at gossamer-threads.com 
> 

rainer, any objections to sign up there?

cheers,
raoul

[1] http://www.gossamer-threads.com/lists
-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep 18 13:52:10 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 13:52:10 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <48D23F94.9060904@ipax.at>
References: <48D23F94.9060904@ipax.at>
Message-ID: <1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>

On Thu, 2008-09-18 at 13:46 +0200, Raoul Bhatia [IPAX] wrote:
> hi,
> 
> as i am quite frequently using gossamer-threads to search mailinglists
> such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
> could too move to gossamer-threads.

"move" implies that the current solution goes away... I hope that's
wrong understanding. I guess it is more like www.mail-archive.com, which
simply subscribes to the list, archives posts and indexes them.
> 
> from the bottom of [1] i take:
> > 
> > Interested in having your list archived? Contact lists at gossamer-threads.com 
> > 
> 
> rainer, any objections to sign up there?

If it is like mail-archive and I do not need to do anything than to say
"OK", that's fine with me. If it is more work, I quite honestly do not
see why I should want that ;)

Rainer
> 
> cheers,
> raoul
> 
> [1] http://www.gossamer-threads.com/lists



From r.bhatia at ipax.at  Thu Sep 18 13:54:40 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 18 Sep 2008 13:54:40 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>
References: <48D23F94.9060904@ipax.at>
	<1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>
Message-ID: <48D24180.7030409@ipax.at>

Rainer Gerhards wrote:
> On Thu, 2008-09-18 at 13:46 +0200, Raoul Bhatia [IPAX] wrote:
>> hi,
>>
>> as i am quite frequently using gossamer-threads to search mailinglists
>> such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
>> could too move to gossamer-threads.
> 
> "move" implies that the current solution goes away... I hope that's
> wrong understanding. I guess it is more like www.mail-archive.com, which
> simply subscribes to the list, archives posts and indexes them.
>> from the bottom of [1] i take:
>>> Interested in having your list archived? Contact lists at gossamer-threads.com 
>>>
>> rainer, any objections to sign up there?
> 
> If it is like mail-archive and I do not need to do anything than to say
> "OK", that's fine with me. If it is more work, I quite honestly do not
> see why I should want that ;)

to my understanding, it indeed is archiving only. and thats the sole
reason i suggested that. so let me rephrase it without the wrong term
"move":

i was wondering whether rsyslog could also be archived via
gossamer-threads.

;)

cheers,
raoul
-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep 18 13:58:05 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 13:58:05 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <48D24180.7030409@ipax.at>
References: <48D23F94.9060904@ipax.at><1221738730.2682.150.camel@rgf9dev.intern.adiscon.com>
	<48D24180.7030409@ipax.at>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F177@grfint2.intern.adiscon.com>

Hi there,

it was suggested from users of the rsyslog project, that we have the
rsyslog mailing list added to Gossamer threads (see below). It is a
mailman mailing list hosted at 

http://lists.adiscon.net/mailman/listinfo/rsyslog

I was pointed to this mail address. Please let us know what needs to be
done or whatever information you may need.

Many thanks for looking into this.

Rainer Gerhards
rsyslog project admin

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX]
> Sent: Thursday, September 18, 2008 1:55 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] archiving rsyslog list via gossamer-threads
> 
> Rainer Gerhards wrote:
> > On Thu, 2008-09-18 at 13:46 +0200, Raoul Bhatia [IPAX] wrote:
> >> hi,
> >>
> >> as i am quite frequently using gossamer-threads to search
> mailinglists
> >> such as linux-ha/pacemaker/etc., i was wondering weather rsyslogd
> >> could too move to gossamer-threads.
> >
> > "move" implies that the current solution goes away... I hope that's
> > wrong understanding. I guess it is more like www.mail-archive.com,
> which
> > simply subscribes to the list, archives posts and indexes them.
> >> from the bottom of [1] i take:
> >>> Interested in having your list archived? Contact lists at gossamer-
> threads.com
> >>>
> >> rainer, any objections to sign up there?
> >
> > If it is like mail-archive and I do not need to do anything than to
> say
> > "OK", that's fine with me. If it is more work, I quite honestly do
> not
> > see why I should want that ;)
> 
> to my understanding, it indeed is archiving only. and thats the sole
> reason i suggested that. so let me rephrase it without the wrong term
> "move":
> 
> i was wondering whether rsyslog could also be archived via
> gossamer-threads.


From r.bhatia at ipax.at  Thu Sep 18 14:43:17 2008
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Thu, 18 Sep 2008 14:43:17 +0200
Subject: [rsyslog] news and download link for 3.18.4
Message-ID: <48D24CE5.6030605@ipax.at>

hi,

somehow, i think that either something is messed up with the website
cms or that the news/download has not been altered yet.

	http://www.rsyslog.com/Downloads-index-req-viewdownload-cid-1-orderby-dateD.phtml
-> no download link

http://www.rsyslog.com/index.php?name=News -> no news.

cheers,
raoul
-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG         web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________


From rgerhards at hq.adiscon.com  Thu Sep 18 14:44:55 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 14:44:55 +0200
Subject: [rsyslog] news and download link for 3.18.4
In-Reply-To: <48D24CE5.6030605@ipax.at>
References: <48D24CE5.6030605@ipax.at>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F178@grfint2.intern.adiscon.com>

> somehow, i think that either something is messed up with the website
> cms or that the news/download has not been altered yet.
> 
> 	http://www.rsyslog.com/Downloads-index-req-viewdownload-cid-1-
> orderby-dateD.phtml
> -> no download link

This is the instable branch. I have to admit this is not well visible,
but there is a link to the stable releases on the top of that page, this
one:

http://www.rsyslog.com/Downloads-req-viewsdownload-sid-1.phtml

> http://www.rsyslog.com/index.php?name=News -> no news.

This, indeed, I have forgotten :) -- thx

Rainer


From lorenzo at sancho.ccd.uniroma2.it  Thu Sep 18 19:13:01 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Thu, 18 Sep 2008 19:13:01 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>

I just tried compiling and running the helgrind branch. To let configure 
finish its work, I've had to delete the PKG_CHECK_MODULES lines for RELP 
and LIBLOGGING.

Worst thing is that the daemon crashed once more; I'm enclosing the whole 
backtrace, that I've got via:

$ gdb /usr/sbin/rsyslogd /var/core-dumps/rsyslogd.core. > rsyslog_helgrind.bt << __eoc__
thread apply all bt
__eoc__

I don't know if the last line of failover.log could be of any help:

syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*) 
(pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.

Time for helgrind or valgrind?

Thank you, yours

 	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /usr/lib/rsyslog/lmnetstrms.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnetstrms.so
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/lmnsd_ptcp.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnsd_ptcp.so
Core was generated by `rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 2747]
[New process 2749]
[New process 2748]
[New process 2746]
[New process 2745]
#0  0x00002ad35493eef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 2745):
#0  0x00002ad3549d5f12 in select () from /lib/libc.so.6
#1  0x000000000040db33 in mainThread () at syslogd.c:2585
#2  0x000000000040ed0c in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:3483
#3  0x00002ad35492b1a6 in __libc_start_main () from /lib/libc.so.6
#4  0x0000000000409f79 in _start ()

Thread 4 (process 2746):
#0  0x00002ad3549c4d17 in sched_yield () from /lib/libc.so.6
#1  0x0000000000431844 in wtiWorker (pThis=0x685200) at wti.c:371
#2  0x00000000004301da in wtpWorker (arg=0x685200) at wtp.c:419
#3  0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 3 (process 2748):
#0  0x00002ad3549d5f12 in select () from /lib/libc.so.6
#1  0x00002ad35507b9dd in runInput (pThrd=<value optimized out>)
    at imuxsock.c:278
#2  0x0000000000441eef in thrdStarter (arg=0x6a6700) at ../threads.c:139
#3  0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 2 (process 2749):
#0  0x00002ad3542f07eb in read () from /lib/libpthread.so.0
#1  0x00002ad3552801bf in klogLogKMsg () at linux.c:449
#2  0x00002ad35527f554 in runInput (pThrd=0x6a7b90) at imklog.c:214
#3  0x0000000000441eef in thrdStarter (arg=0x6a7b90) at ../threads.c:139
#4  0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#5  0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (process 2747):
#0  0x00002ad35493eef5 in raise () from /lib/libc.so.6
#1  0x00002ad354940413 in abort () from /lib/libc.so.6
#2  0x0000000000422019 in sigsegvHdlr (signum=6) at debug.c:758
#3  <signal handler called>
#4  0x00002ad35493eef5 in raise () from /lib/libc.so.6
#5  0x00002ad354940413 in abort () from /lib/libc.so.6
#6  0x00002ad354937dc9 in __assert_fail () from /lib/libc.so.6
#7  0x000000000041bad6 in msgDestruct (ppThis=0x6905f8) at msg.c:274
#8  0x0000000000441824 in actionCallAction (pAction=0x690580, pMsg=0x6aeb70)
    at ../action.c:741
#9  0x000000000040afb7 in processMsgDoActions (pData=0x690580, 
    pParam=0x41000e90) at syslogd.c:1117
#10 0x000000000041c938 in llExecFunc (pThis=0x6903e0, 
    pFunc=0x40af60 <processMsgDoActions>, pParam=0x41000e90)
    at linkedlist.c:391
#11 0x000000000040ab19 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x6aeb70) at syslogd.c:1160
#12 0x000000000043ae97 in queueConsumerReg (pThis=0x690980, pWti=0x6a4600, 
    iCancelStateSave=<value optimized out>) at queue.c:1574
#13 0x0000000000431970 in wtiWorker (pThis=0x6a4600) at wti.c:413
#14 0x00000000004301da in wtpWorker (arg=0x6a4600) at wtp.c:419
#15 0x00002ad3542e9fc7 in start_thread () from /lib/libpthread.so.0
#16 0x00002ad3549dc7cd in clone () from /lib/libc.so.6
#17 0x0000000000000000 in ?? ()
(gdb) quit

From rgerhards at hq.adiscon.com  Thu Sep 18 21:12:05 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 18 Sep 2008 21:12:05 +0200
Subject: [rsyslog] archiving rsyslog list via gossamer-threads
In-Reply-To: <20080918114004.A0E4.80590B96@gossamer-threads.com>
References: <48D24180.7030409@ipax.at>
	<577465F99B41C842AAFBE9ED71E70ABA44F177@grfint2.intern.adiscon.com>
	<20080918114004.A0E4.80590B96@gossamer-threads.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F182@grfint2.intern.adiscon.com>

Hi Alex,

Thanks a lot for your fast and efficient help. Much appreciated.

Rainer 

> -----Original Message-----
> From: Alex Krohn [mailto:alex at gossamer-threads.com] 
> Sent: Thursday, September 18, 2008 8:42 PM
> To: Rainer Gerhards
> Subject: Re: [rsyslog] archiving rsyslog list via gossamer-threads
> 
> Hi Rainer,
> 
> > it was suggested from users of the rsyslog project, that we have the
> > rsyslog mailing list added to Gossamer threads (see below). It is a
> > mailman mailing list hosted at 
> > 
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > 
> > I was pointed to this mail address. Please let us know what 
> needs to be
> > done or whatever information you may need.
> 
> Sure, I've added it in:
> 
>     http://www.gossamer-threads.com/lists/rsyslog/users/
> 
> Please feel free to pass this on to the rsyslog list as I'm not
> subscribed. 
> 
> Cheers,
> 
> Alex
> 
> --
> Alex Krohn <alex at gossamer-threads.com>
> Gossamer Threads Inc. http://www.gossamer-threads.com/
> Tel: (604) 687-5804 Fax: (604) 687-5806
> 
> 


From rgerhards at hq.adiscon.com  Fri Sep 19 08:50:16 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 19 Sep 2008 08:50:16 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F186@grfint2.intern.adiscon.com>

> I don't know if the last line of failover.log could be of any help:
> 
> syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*)
> (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.
> 
Interesting...

> Time for helgrind or valgrind?

Could you run it in debug mode (-dn) and send me the log file? Maybe it
has some interesting findings in it.

On valgrind and helgrind: both is fine. If the problem is reproducible,
first run it under the memory checker and then the thread checker.
Helgrind will report a couple (20 or so) exceptions at the END of
program run, that is fine. Any other exception - in either of both - is
interesting and probably helpful.

Rainer


From rgerhards at hq.adiscon.com  Fri Sep 19 15:59:42 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 19 Sep 2008 15:59:42 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it>
	<1221723317.2682.142.camel@rgf9dev.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com>
	<alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>

OK, I (thankfully) was able to see a potential race in my test environment that actually fits very well to the assert message you see. In my environment, it happens very (very!) seldom, even helgrind didn't notice until now. Please wait until I create a patch for it, I do NOT need any further info in the meantime.

Rainer

> -----Original Message-----
> From: Lorenzo M. Catucci [mailto:lorenzo at sancho.ccd.uniroma2.it]
> Sent: Thursday, September 18, 2008 7:13 PM
> To: Rainer Gerhards
> Cc: rsyslog-users
> Subject: Re: [rsyslog] abort cases
> 
> I just tried compiling and running the helgrind branch. To let
> configure
> finish its work, I've had to delete the PKG_CHECK_MODULES lines for
> RELP
> and LIBLOGGING.
> 
> Worst thing is that the daemon crashed once more; I'm enclosing the
> whole
> backtrace, that I've got via:
> 
> $ gdb /usr/sbin/rsyslogd /var/core-dumps/rsyslogd.core. >
> rsyslog_helgrind.bt << __eoc__
> thread apply all bt
> __eoc__
> 
> I don't know if the last line of failover.log could be of any help:
> 
> syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*)
> (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.
> 
> Time for helgrind or valgrind?
> 
> Thank you, yours
> 
>  	lorenzo
> 
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From rgerhards at hq.adiscon.com  Fri Sep 19 17:55:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 19 Sep 2008 17:55:14 +0200
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it><1221723317.2682.142.camel@rgf9dev.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F199@grfint2.intern.adiscon.com>

Lorenzo,

I would appreciate if you could run the latest code from "helgrind" branch. I have created one patch. It is probably not a 100% solution, but I won't manage to do much more today. And so it would be very helpful for me to know if something changes in your environment.

Thanks,
Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Friday, September 19, 2008 4:00 PM
> To: Lorenzo M. Catucci
> Cc: rsyslog-users
> Subject: Re: [rsyslog] abort cases
> 
> OK, I (thankfully) was able to see a potential race in my test
> environment that actually fits very well to the assert message you see.
> In my environment, it happens very (very!) seldom, even helgrind didn't
> notice until now. Please wait until I create a patch for it, I do NOT
> need any further info in the meantime.
> 
> Rainer
> 
> > -----Original Message-----
> > From: Lorenzo M. Catucci [mailto:lorenzo at sancho.ccd.uniroma2.it]
> > Sent: Thursday, September 18, 2008 7:13 PM
> > To: Rainer Gerhards
> > Cc: rsyslog-users
> > Subject: Re: [rsyslog] abort cases
> >
> > I just tried compiling and running the helgrind branch. To let
> > configure
> > finish its work, I've had to delete the PKG_CHECK_MODULES lines for
> > RELP
> > and LIBLOGGING.
> >
> > Worst thing is that the daemon crashed once more; I'm enclosing the
> > whole
> > backtrace, that I've got via:
> >
> > $ gdb /usr/sbin/rsyslogd /var/core-dumps/rsyslogd.core. >
> > rsyslog_helgrind.bt << __eoc__
> > thread apply all bt
> > __eoc__
> >
> > I don't know if the last line of failover.log could be of any help:
> >
> > syslogd: msg.c:274: msgDestruct: Assertion `(unsigned) ((obj_t*)
> > (pThis))->iObjCooCKiE == (unsigned) 0xBADEFEE' failed.
> >
> > Time for helgrind or valgrind?
> >
> > Thank you, yours
> >
> >  	lorenzo
> >
> >
> > +-------------------------+------------------------------------------
> --
> > --+
> > |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> > |
> > | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> > Vergata" |
> > |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> > ITALY |
> > |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> > |
> > +-------------------------+------------------------------------------
> --
> > --+
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From lorenzo at sancho.ccd.uniroma2.it  Fri Sep 19 23:37:31 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Fri, 19 Sep 2008 23:37:31 +0200 (CEST)
Subject: [rsyslog] abort cases
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F199@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F16C@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171825550.11101@ronzinante.ccd.uniroma2.it><577465F99B41C842AAFBE9ED71E70ABA44F16D@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809171906210.12280@ronzinante.ccd.uniroma2.it><1221723317.2682.142.camel@rgf9dev.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44F176@grfint2.intern.adiscon.com><alpine.DEB.1.10.0809181859310.25074@ronzinante.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F198@grfint2.intern.adiscon.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F199@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809192331410.19819@sancho.ccd.uniroma2.it>

As promised, I've just logged in to the server, to check if the daemon was 
still on. I found a 33M core dump; I'm enclosing the backtrace here.

Have a nice week-end,

 	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /usr/lib/rsyslog/lmnetstrms.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnetstrms.so
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/lmnsd_ptcp.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnsd_ptcp.so
Core was generated by `rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 31084]
[New process 31086]
[New process 31085]
[New process 31083]
[New process 31082]
#0  0x00002b67305cdef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 31082):
#0  0x00002b6730664f12 in select () from /lib/libc.so.6
#1  0x000000000040db33 in mainThread () at syslogd.c:2585
#2  0x000000000040ed0c in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:3483
#3  0x00002b67305ba1a6 in __libc_start_main () from /lib/libc.so.6
#4  0x0000000000409f79 in _start ()

Thread 4 (process 31083):
#0  0x00002b672ff7cfad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#1  0x0000000000431a13 in wtiWorker (pThis=0x685200) at wti.c:403
#2  0x00000000004301da in wtpWorker (arg=0x685200) at wtp.c:419
#3  0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b673066b7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 3 (process 31085):
#0  0x00002b6730664f12 in select () from /lib/libc.so.6
#1  0x00002b6730d0a9dd in runInput (pThrd=<value optimized out>)
    at imuxsock.c:278
#2  0x0000000000441eef in thrdStarter (arg=0x6a4830) at ../threads.c:139
#3  0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b673066b7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 2 (process 31086):
#0  0x00002b672ff7f7eb in read () from /lib/libpthread.so.0
#1  0x00002b6730f0f1bf in klogLogKMsg () at linux.c:449
#2  0x00002b6730f0e554 in runInput (pThrd=0x6a8340) at imklog.c:214
#3  0x0000000000441eef in thrdStarter (arg=0x6a8340) at ../threads.c:139
#4  0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#5  0x00002b673066b7cd in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (process 31084):
#0  0x00002b67305cdef5 in raise () from /lib/libc.so.6
#1  0x00002b67305cf413 in abort () from /lib/libc.so.6
#2  0x0000000000422019 in sigsegvHdlr (signum=6) at debug.c:758
#3  <signal handler called>
#4  0x00002b67305cdef5 in raise () from /lib/libc.so.6
#5  0x00002b67305cf413 in abort () from /lib/libc.so.6
#6  0x00002b67305c6dc9 in __assert_fail () from /lib/libc.so.6
#7  0x000000000041bad6 in msgDestruct (ppThis=0x68e728) at msg.c:274
#8  0x0000000000441824 in actionCallAction (pAction=0x68e6b0, 
    pMsg=0x2aaaac0014c0) at ../action.c:741
#9  0x000000000040afb7 in processMsgDoActions (pData=0x68e6b0, 
    pParam=0x41000e90) at syslogd.c:1117
#10 0x000000000041c938 in llExecFunc (pThis=0x68e510, 
    pFunc=0x40af60 <processMsgDoActions>, pParam=0x41000e90)
    at linkedlist.c:391
#11 0x000000000040ab19 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x2aaaac0014c0) at syslogd.c:1160
#12 0x000000000043ae97 in queueConsumerReg (pThis=0x68eab0, pWti=0x6a2730, 
    iCancelStateSave=<value optimized out>) at queue.c:1574
#13 0x0000000000431970 in wtiWorker (pThis=0x6a2730) at wti.c:413
#14 0x00000000004301da in wtpWorker (arg=0x6a2730) at wtp.c:419
#15 0x00002b672ff78fc7 in start_thread () from /lib/libpthread.so.0
#16 0x00002b673066b7cd in clone () from /lib/libc.so.6
#17 0x0000000000000000 in ?? ()
(gdb) quit

From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 14:48:55 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 14:48:55 +0200 (CEST)
Subject: [rsyslog] problems with autoconf and configuration examples
Message-ID: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>

Last week, I referred in a very terse way to configure problems; to have 
configure finish its job, I have to remove both PKG_CHECK_MODULES from 
configure.ac:

  ./configure: line 26534: syntax error near unexpected token `RELP,'
  ./configure: line 26534: `      PKG_CHECK_MODULES(RELP, relp >= 0.1.1)'

and, after removing the RELP line group:

  ./configure: line 26560: syntax error near unexpected token `LIBLOGGING,'
  ./configure: line 26560: `      PKG_CHECK_MODULES(LIBLOGGING, liblogging >= 0.7.1)'

As for the configuration examples, I still find references to
$ActionExecOnlyIfPreviousIsSuspended both on-line and in the sample
section of ./doc/rsconf1_actionexeconlywhenpreviousissuspended.html.

If there is no way to keep the previous syntax running and spewing a
deprecation warning, please do correct all the google reachable
pages showing the wrong syntax... and add a note like
"in the past, rsyslogd supported the now removed syntax 
$ActionExecOnlyIfPreviousIsSuspended"

Thank you very much, yours

 	lorenzo


From rgerhards at hq.adiscon.com  Mon Sep 22 14:52:01 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 14:52:01 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
Message-ID: <1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>

Hi all,

On Mon, 2008-09-22 at 14:48 +0200, Lorenzo M. Catucci wrote:
> Last week, I referred in a very terse way to configure problems; to have 
> configure finish its job, I have to remove both PKG_CHECK_MODULES from 
> configure.ac:
> 
>   ./configure: line 26534: syntax error near unexpected token `RELP,'
>   ./configure: line 26534: `      PKG_CHECK_MODULES(RELP, relp >= 0.1.1)'
> 
> and, after removing the RELP line group:
> 
>   ./configure: line 26560: syntax error near unexpected token `LIBLOGGING,'
>   ./configure: line 26560: `      PKG_CHECK_MODULES(LIBLOGGING, liblogging >= 0.7.1)'
> 

I unfortunately have no idea what this problem may be caused by. Can
someone with a better understanding of autotools help out?

> As for the configuration examples, I still find references to
> $ActionExecOnlyIfPreviousIsSuspended both on-line and in the sample
> section of ./doc/rsconf1_actionexeconlywhenpreviousissuspended.html.
> 
> If there is no way to keep the previous syntax running and spewing a
> deprecation warning, please do correct all the google reachable
> pages showing the wrong syntax... and add a note like
> "in the past, rsyslogd supported the now removed syntax 
> $ActionExecOnlyIfPreviousIsSuspended"
> 

Sorry if I am missing the obvious here (I am probably ;)), but I do not
get what exactly you are refering to. Please elaborate a bit.

Thanks,
Rainer

> Thank you very much, yours
> 
>  	lorenzo
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From mbiebl at gmail.com  Mon Sep 22 14:55:00 2008
From: mbiebl at gmail.com (Michael Biebl)
Date: Mon, 22 Sep 2008 14:55:00 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
Message-ID: <aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>

2008/9/22 Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:
> Last week, I referred in a very terse way to configure problems; to have
> configure finish its job, I have to remove both PKG_CHECK_MODULES from
> configure.ac:
>
>  ./configure: line 26534: syntax error near unexpected token `RELP,'
>  ./configure: line 26534: `      PKG_CHECK_MODULES(RELP, relp >= 0.1.1)'
>
> and, after removing the RELP line group:
>
>  ./configure: line 26560: syntax error near unexpected token `LIBLOGGING,'
>  ./configure: line 26560: `      PKG_CHECK_MODULES(LIBLOGGING, liblogging >= 0.7.1)'

Please install the pkg-config package and re-run
autoreconf -vfi


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


From rgerhards at hq.adiscon.com  Mon Sep 22 15:02:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 15:02:14 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1A4@grfint2.intern.adiscon.com>

Me again ;)

I have done some further testing today. I begin to think that the issue
left is only related to HUPing rsyslogd. Can you confirm this? Do
problems happen before the first HUP is sent?

Thanks,
Rainer


From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 16:03:46 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 16:03:46 +0200 (CEST)
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0809221550120.1580@sancho.ccd.uniroma2.it>

On Mon, 22 Sep 2008, Michael Biebl wrote:

MB> 
MB> Please install the pkg-config package and re-run
MB> autoreconf -vfi
MB> 

Did do the trick; still, I'm unsure if the requirement for pkg-config is 
really justified just for two non-mandatory libraries.

Thank you very much, yours

	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 16:18:14 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 16:18:14 +0200 (CEST)
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809221607540.1580@sancho.ccd.uniroma2.it>

RG> 
RG> Sorry if I am missing the obvious here (I am probably ;)), but I do not
RG> get what exactly you are refering to. Please elaborate a bit.
RG> 
RG> 

The misleading documentation is available, both online at
  http://kb.monitorware.com/problem-in-failover-syslogserver-t8465.html
  http://wiki.rsyslog.com/index.php/FailoverSyslogServer 

There is a talk-back item for the wiki page at
  http://wiki.rsyslog.com/index.php/Talk:FailoverSyslogServer

Whats strange is that the same error is repeated at 
./doc/rsconf1_actionexeconlywhenpreviousissuspended.html  

and that the $ActionExecOnlyWhenPreviousIsSuspended is undocumented.


Thank you very much, yours,

	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From rgerhards at hq.adiscon.com  Mon Sep 22 16:32:45 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 16:32:45 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221607540.1580@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<1222087921.2682.163.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809221607540.1580@sancho.ccd.uniroma2.it>
Message-ID: <1222093965.2682.165.camel@rgf9dev.intern.adiscon.com>

Thanks for letting me know. It's fixed now.

Rainer

On Mon, 2008-09-22 at 16:18 +0200, Lorenzo M. Catucci wrote:
> RG> 
> RG> Sorry if I am missing the obvious here (I am probably ;)), but I do not
> RG> get what exactly you are refering to. Please elaborate a bit.
> RG> 
> RG> 
> 
> The misleading documentation is available, both online at
>   http://kb.monitorware.com/problem-in-failover-syslogserver-t8465.html
>   http://wiki.rsyslog.com/index.php/FailoverSyslogServer 
> 
> There is a talk-back item for the wiki page at
>   http://wiki.rsyslog.com/index.php/Talk:FailoverSyslogServer
> 
> Whats strange is that the same error is repeated at 
> ./doc/rsconf1_actionexeconlywhenpreviousissuspended.html  
> 
> and that the $ActionExecOnlyWhenPreviousIsSuspended is undocumented.
> 
> 
> Thank you very much, yours,
> 
> 	lorenzo
> 
> +-------------------------+----------------------------------------------+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
> +-------------------------+----------------------------------------------+
> _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Mon Sep 22 16:42:51 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 16:42:51 +0200
Subject: [rsyslog] someone with experience in DejaGNU on this list?
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1A7@grfint2.intern.adiscon.com>

Hi,

I am looking for ways to improve the rsyslog test suites. I have written
a handful few via custom programs, but turning them into a full blow (or
at least somewhat sufficiently full blow ;)) test suite is far from
being trivial. I am looking for a suite that can be executed as part of
make distcheck and look at all the important things.

I know that there is DejaGNU out, which promises to ease creating
testsuites, but I have never used it. So before I invest any time in
looking at it, is there some wisdom about it, or another open source
testing tool, available on this list?

If you know something, please comment.

Thanks,
Rainer


From mbiebl at gmail.com  Mon Sep 22 17:00:02 2008
From: mbiebl at gmail.com (Michael Biebl)
Date: Mon, 22 Sep 2008 17:00:02 +0200
Subject: [rsyslog] problems with autoconf and configuration examples
In-Reply-To: <alpine.DEB.1.10.0809221550120.1580@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221439560.1011@sancho.ccd.uniroma2.it>
	<aa76cdac0809220555w777f6666s5dfd16722159cf4c@mail.gmail.com>
	<alpine.DEB.1.10.0809221550120.1580@sancho.ccd.uniroma2.it>
Message-ID: <aa76cdac0809220800w18aab7fs4d9f7c3db819a303@mail.gmail.com>

2008/9/22 Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:
> On Mon, 22 Sep 2008, Michael Biebl wrote:
>
> MB>
> MB> Please install the pkg-config package and re-run
> MB> autoreconf -vfi
> MB>
>
> Did do the trick; still, I'm unsure if the requirement for pkg-config is
> really justified just for two non-mandatory libraries.
>
> Thank you very much, yours

pkg-config is *so* widely used nowadays, I was actually pretty
surprised you hadn't installed it by default.

Cheers,
Michael


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


From rgerhards at hq.adiscon.com  Mon Sep 22 17:23:41 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 17:23:41 +0200
Subject: [rsyslog] Another helgrind log
In-Reply-To: <alpine.DEB.1.10.0809221653340.2559@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221653340.2559@sancho.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1AE@grfint2.intern.adiscon.com>

Hi all,

just a quick wrap-up. Lorenzo sent me a couple of traces privately (on my request to keep the list free of the big attachments). I have reviewed them and I have to admit I am a bit puzzled by the traces. This just made me post a question on the valgrind mailing list. I hope to get some feedback from there soon.

Other than that, I have run a number of new tests today, during one I detected a problem inside imuxsock, but this one is probably unrelated as it isn't loaded. I will continue testing. Any more feedback is welcome. As soon as I have new news, I'll post.

Rainer

> This time I'm sure no HUP has been delivered to the daemon before
> helgrind
> did terminate it.
> 
> I'm restarting the "free-running" daemon and will wait till a SEGV
> comes
> to it.
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 17:30:18 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 17:30:18 +0200 (CEST)
Subject: [rsyslog] Another gdb backtrace
Message-ID: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>

Now I'm sure no HUP could have been deilivered to the daemon while 
running. This is a backtrace from a standard

$ rsyslogd -c3

run inside a screen session...

Thank you very much, yours

 	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-2.7.so...done.
done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.7.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.7.so...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.7.so...done.
done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/rsyslog/lmnet.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnet.so
Reading symbols from /lib/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/libnss_files-2.7.so...done.
done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/rsyslog/imuxsock.so...done.
Loaded symbols for /usr/lib/rsyslog/imuxsock.so
Reading symbols from /usr/lib/rsyslog/imklog.so...done.
Loaded symbols for /usr/lib/rsyslog/imklog.so
Reading symbols from /lib/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/libnss_compat-2.7.so...done.
done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/libnsl-2.7.so...done.
done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/libnss_nis-2.7.so...done.
done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /usr/lib/rsyslog/lmnetstrms.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnetstrms.so
Reading symbols from /usr/lib/rsyslog/lmtcpclt.so...done.
Loaded symbols for /usr/lib/rsyslog/lmtcpclt.so
Reading symbols from /usr/lib/rsyslog/lmnsd_ptcp.so...done.
Loaded symbols for /usr/lib/rsyslog/lmnsd_ptcp.so
Core was generated by `rsyslogd -c3'.
Program terminated with signal 6, Aborted.
[New process 27165]
[New process 27167]
[New process 27166]
[New process 27164]
[New process 27163]
#0  0x00002b6f58c7fef5 in raise () from /lib/libc.so.6
(gdb) 
Thread 5 (process 27163):
#0  0x00002b6f58d16f12 in select () from /lib/libc.so.6
#1  0x000000000040db33 in mainThread () at syslogd.c:2585
#2  0x000000000040ed0c in realMain (argc=<value optimized out>, 
    argv=<value optimized out>) at syslogd.c:3483
#3  0x00002b6f58c6c1a6 in __libc_start_main () from /lib/libc.so.6
#4  0x0000000000409f79 in _start ()

Thread 4 (process 27164):
#0  0x00002b6f5862efad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#1  0x0000000000431a13 in wtiWorker (pThis=0x685200) at wti.c:403
#2  0x00000000004301da in wtpWorker (arg=0x685200) at wtp.c:419
#3  0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 3 (process 27166):
#0  0x00002b6f58d16f12 in select () from /lib/libc.so.6
#1  0x00002b6f593bc9dd in runInput (pThrd=<value optimized out>)
    at imuxsock.c:278
#2  0x0000000000441eef in thrdStarter (arg=0x6a5b30) at ../threads.c:139
#3  0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#4  0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 2 (process 27167):
#0  0x00002b6f586317eb in read () from /lib/libpthread.so.0
#1  0x00002b6f595c11bf in klogLogKMsg () at linux.c:449
#2  0x00002b6f595c0554 in runInput (pThrd=0x6a8c60) at imklog.c:214
#3  0x0000000000441eef in thrdStarter (arg=0x6a8c60) at ../threads.c:139
#4  0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#5  0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (process 27165):
#0  0x00002b6f58c7fef5 in raise () from /lib/libc.so.6
#1  0x00002b6f58c81413 in abort () from /lib/libc.so.6
#2  0x0000000000422019 in sigsegvHdlr (signum=6) at debug.c:758
#3  <signal handler called>
#4  0x00002b6f58c7fef5 in raise () from /lib/libc.so.6
#5  0x00002b6f58c81413 in abort () from /lib/libc.so.6
#6  0x00002b6f58c78dc9 in __assert_fail () from /lib/libc.so.6
#7  0x000000000041bad6 in msgDestruct (ppThis=0x68fa28) at msg.c:274
#8  0x0000000000441824 in actionCallAction (pAction=0x68f9b0, pMsg=0x6b1ce0)
    at ../action.c:741
#9  0x000000000040afb7 in processMsgDoActions (pData=0x68f9b0, 
    pParam=0x41000e90) at syslogd.c:1117
#10 0x000000000041c938 in llExecFunc (pThis=0x68e510, 
    pFunc=0x40af60 <processMsgDoActions>, pParam=0x41000e90)
    at linkedlist.c:391
#11 0x000000000040ab19 in msgConsumer (notNeeded=<value optimized out>, 
    pUsr=0x6b1ce0) at syslogd.c:1160
#12 0x000000000043ae97 in queueConsumerReg (pThis=0x68fdb0, pWti=0x6a3a30, 
    iCancelStateSave=<value optimized out>) at queue.c:1574
#13 0x0000000000431970 in wtiWorker (pThis=0x6a3a30) at wti.c:413
#14 0x00000000004301da in wtpWorker (arg=0x6a3a30) at wtp.c:419
#15 0x00002b6f5862afc7 in start_thread () from /lib/libpthread.so.0
#16 0x00002b6f58d1d7cd in clone () from /lib/libc.so.6
#17 0x0000000000000000 in ?? ()
(gdb) quit

From rgerhards at hq.adiscon.com  Mon Sep 22 17:33:54 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 22 Sep 2008 17:33:54 +0200
Subject: [rsyslog] Another gdb backtrace
In-Reply-To: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>
References: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1B0@grfint2.intern.adiscon.com>

Just to double-check: does the abort happen

a) immediately
b) relatively soon after start
c) some time after start, probably late

I think it is b). Reason for question: I would eventually like to add some instrumentation, but that makes sense only if we do not need to wade through several GB of debug log...

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Lorenzo M. Catucci
> Sent: Monday, September 22, 2008 5:30 PM
> To: rsyslog-users
> Subject: [rsyslog] Another gdb backtrace
> 
> Now I'm sure no HUP could have been deilivered to the daemon while
> running. This is a backtrace from a standard
> 
> $ rsyslogd -c3
> 
> run inside a screen session...
> 
> Thank you very much, yours
> 
>  	lorenzo
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From lorenzo at sancho.ccd.uniroma2.it  Mon Sep 22 17:52:43 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Mon, 22 Sep 2008 17:52:43 +0200 (CEST)
Subject: [rsyslog] Another gdb backtrace
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1B0@grfint2.intern.adiscon.com>
References: <alpine.DEB.1.10.0809221727340.2559@sancho.ccd.uniroma2.it>
	<577465F99B41C842AAFBE9ED71E70ABA44F1B0@grfint2.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809221738520.2559@sancho.ccd.uniroma2.it>

On Mon, 22 Sep 2008, Rainer Gerhards wrote:

RG> Just to double-check: does the abort happen
RG> 
RG> a) immediately
RG> b) relatively soon after start
RG> c) some time after start, probably late
RG> 
RG> I think it is b). Reason for question: I would eventually like to add 
RG> some instrumentation, but that makes sense only if we do not need to 
RG> wade through several GB of debug log...
RG> 

The free-running doesn't survive more than a couple of hours; I still 
haven't tried a free-running with -dn appended; let me know if you'd 
prefer for me to try starting the daemon now, or if it's better if 
I wait for some more commits.

As for testing, in as much as I understand, to reproduce the problem we 
are going after there would be a need for a load-test harness, and some 
patience, since, in my case, the "writer" server does work without any 
problem, and the crashes do happen on one of my loaded mail gateways, 
which get some thousand messages per hour, and do antispam and antivirus 
work, with sendmail, mailscanner and clamav each spewing a lot of messages 
to filter and dispose of.

See you later, yours

	lorenzo


+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From aoz.syn at gmail.com  Tue Sep 23 05:31:29 2008
From: aoz.syn at gmail.com (RB)
Date: Mon, 22 Sep 2008 21:31:29 -0600
Subject: [rsyslog] RPM spec file
Message-ID: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>

I was building a virtual host the other day and noticed only
rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
rather disappointed and immediately whipped up something based on the
2.0.0 specfile.

Attached is a spec file for 3.21.4, but should be usable for most of
the 3.x series.  YMMV, this has not been tested too terribly much.
I'd appreciate a callback if anyone uses it or has a problem - I've
done plenty of packaging, just not for RPM-based distros.


RB

From rgerhards at hq.adiscon.com  Tue Sep 23 08:54:55 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 08:54:55 +0200
Subject: [rsyslog] cisco router config and plain TCP syslog
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>

Hi list,

is there someone on the list successfully using plain TCP syslog
logging? I have one problem case inside the forum where the router does
not properly terminate messages with LF, the required framing:

http://kb.monitorware.com/tcp-syslog-fill-s-up-buffer-and-doesn-t-log-si
ngle-events-t8705.html

I am not an IOS guy, so I would appreciate if someone could drop me the
right configuration for the routers. Actually, I wonder that they do not
seem to do that by default. As far as I remember, this has never been an
issue. I have limited personal experience with PIX, which terminated
messages correct by default.

Any pointer would be appreciated,
Rainer


From rgerhards at hq.adiscon.com  Tue Sep 23 10:31:59 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 10:31:59 +0200
Subject: [rsyslog] FW: [Valgrind-users] helgrind points to race in
	pthread_mutex_lock?
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1B9@grfint2.intern.adiscon.com>

Hi all,

An update on the abort case bug.

Below is one of the responses I got from the valgrind mailing list about
my inquiry. In short, the helgrind log I received seems not to be
absolutely correct and thus is unfortunately of very limited use for
troubleshooting.

There are new versions out and I will ask Lorenzo if it is possible to
run one of those. I'll do that via private mail as I need to forward
some more messages (unfortunately the valgrind mailing list archive
lacks behind several days, so I can not yet refer to the archive...).

Rainer

> ---------- Forwarded message ----------
> From: Julian Seward < >
> Date: Mon, Sep 22, 2008 at 8:54 PM
> Subject: Re: [Valgrind-users] helgrind points to race in
> pthread_mutex_lock?
> To: valgrind-users at lists.sourceforge.net
> Cc: Konstantin Serebryany < >, Rainer
> Gerhards < m>
> 
> 
> 
> On Monday 22 September 2008, Konstantin Serebryany wrote:
> 
> > helgrind is under active development now in two separate branches
> > (HGDEV & YARD).
> > The version in trunk is outdated. Please try YARD first:
> > svn co svn://svn.valgrind.org/valgrind/branches/YARD YARD
> 
> Yes, do try YARD; you might like it more than the 3.3.1 helgrind.
> 
> Nevertheless, the error you show:
> 
> > > ==31831== Possible data race during read of size 4 at 0x6622E8
> > > ==31831==    at 0x50464FE: pthread_mutex_lock
> (pthread_mutex_lock.c:87)
> > > ==31831==    by 0x4C2217B: pthread_mutex_lock
(hg_intercepts.c:400)
> > > ==31831==    by 0x420AFC: dbgGetThrdInfo (debug.c:604)
> > [...]
> 
> should have been suppressed, so you should not see it.  It is due to
an
> internal implementation limitation which is hard to avoid, so in some
> cases we suppress errors which we know cannot be from end-user code.
> 
> I think the relevant suppression in glibc-2.34567-NPTL-helgrind.supp
> is:
> 
>  {
>     helgrind-glibc25-101
>     Helgrind:Race
>     obj:/lib*/libpthread-2.5.*so
>     fun:pthread_*
>  }
> 
> (or corresponding other versions for glibc > 2.5, in the same file)
> 
> One possible reason it did not suppress the error is that you have
> debug information on/for your libpthread, which is an unusual setup
> that
> Helgrind has not been properly tested against.
> 
> But I am not 100% sure about that.
> 
> * if you uninstall the libc debuginfo rpm/deb, does that change
> anything?
> 
> * what glibc version are you using?
> 
> J


From mic at npgx.com.au  Tue Sep 23 11:07:02 2008
From: mic at npgx.com.au (Michael Mansour)
Date: Tue, 23 Sep 2008 20:07:02 +1100
Subject: [rsyslog] RPM spec file
In-Reply-To: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
Message-ID: <20080923090507.M89321@npgx.com.au>

Hi,

> I was building a virtual host the other day and noticed only
> rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> rather disappointed and immediately whipped up something based on the
> 2.0.0 specfile.
> 
> Attached is a spec file for 3.21.4, but should be usable for most of
> the 3.x series.  YMMV, this has not been tested too terribly much.
> I'd appreciate a callback if anyone uses it or has a problem - I've
> done plenty of packaging, just not for RPM-based distros.

I'd love to test this so could you attach the spec or make it available?

I published mine in the rsyslog wiki.

Thanks.

Michael.

> RB
------- End of Original Message -------



From rgerhards at hq.adiscon.com  Tue Sep 23 11:24:05 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 11:24:05 +0200
Subject: [rsyslog] RPM spec file
In-Reply-To: <20080923090507.M89321@npgx.com.au>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<20080923090507.M89321@npgx.com.au>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1BF@grfint2.intern.adiscon.com>

[listadmin speaking]
Ah, I didn't notice. The list processor removes almost all attachments
in order to keep message sizes reasonable and block spread of viruses
should such files be able to go past the first line of defense. Sorry
for the inconvenience this causes...

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Michael Mansour
> Sent: Tuesday, September 23, 2008 11:07 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] RPM spec file
> 
> Hi,
> 
> > I was building a virtual host the other day and noticed only
> > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > rather disappointed and immediately whipped up something based on
the
> > 2.0.0 specfile.
> >
> > Attached is a spec file for 3.21.4, but should be usable for most of
> > the 3.x series.  YMMV, this has not been tested too terribly much.
> > I'd appreciate a callback if anyone uses it or has a problem - I've
> > done plenty of packaging, just not for RPM-based distros.
> 
> I'd love to test this so could you attach the spec or make it
> available?
> 
> I published mine in the rsyslog wiki.
> 
> Thanks.
> 
> Michael.
> 
> > RB
> ------- End of Original Message -------
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From mic at npgx.com.au  Tue Sep 23 12:16:41 2008
From: mic at npgx.com.au (Michael Mansour)
Date: Tue, 23 Sep 2008 21:16:41 +1100
Subject: [rsyslog] [Spam?DateIssue] Re:  RPM spec file
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1BF@grfint2.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<20080923090507.M89321@npgx.com.au>
	<577465F99B41C842AAFBE9ED71E70ABA44F1BF@grfint2.intern.adiscon.com>
Message-ID: <20080923101451.M62228@npgx.com.au>

> [listadmin speaking]
> Ah, I didn't notice. The list processor removes almost all 
> attachments in order to keep message sizes reasonable and block 
> spread of viruses should such files be able to go past the first 
> line of defense. Sorry for the inconvenience this causes...

RB, if you cannot post this to the list could you email it to me directly please?

I'm happy to update the rsyslog wiki page with it so others can download also.

Michael.

> Rainer
> 
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Michael Mansour
> > Sent: Tuesday, September 23, 2008 11:07 AM
> > To: rsyslog-users
> > Subject: Re: [rsyslog] RPM spec file
> > 
> > Hi,
> > 
> > > I was building a virtual host the other day and noticed only
> > > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > > rather disappointed and immediately whipped up something based on
> the
> > > 2.0.0 specfile.
> > >
> > > Attached is a spec file for 3.21.4, but should be usable for most of
> > > the 3.x series.  YMMV, this has not been tested too terribly much.
> > > I'd appreciate a callback if anyone uses it or has a problem - I've
> > > done plenty of packaging, just not for RPM-based distros.
> > 
> > I'd love to test this so could you attach the spec or make it
> > available?
> > 
> > I published mine in the rsyslog wiki.
> > 
> > Thanks.
> > 
> > Michael.
> > 
> > > RB
> > ------- End of Original Message -------
> > 
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
------- End of Original Message -------



From rgerhards at hq.adiscon.com  Tue Sep 23 12:51:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 12:51:14 +0200
Subject: [rsyslog] RPM spec file
In-Reply-To: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>

[oops, forgotten to hit "send" - now a bit outdated, but still useful...]

Hi RB,

I really appreciate the spec file ... but it also creates a bit of a problem for me ;) Let me elaborate: I have stayed away from doing spec files, mostly because I can not ensure they are kept up to date. For that reason, nothing distro-specific is included in the "official source distribution".

If I now include the spec, it may outdate over time plus people come and ask how to work with it, getting us probably down to distro-specific things. I am not sure we want this (or do we want it - I am open to change if there are folks in the community who can commit to support these things [aka "I can not" ;)].

Or is there any other place where such things could be placed (external RPM repositories come to my mind)? I would be more than happy to link to the relevant places.

Again, I really value the contribution, I just do not know how to handle it best.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of RB
> Sent: Tuesday, September 23, 2008 5:31 AM
> To: rsyslog at lists.adiscon.com
> Subject: [rsyslog] RPM spec file
> 
> I was building a virtual host the other day and noticed only
> rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> rather disappointed and immediately whipped up something based on the
> 2.0.0 specfile.
> 
> Attached is a spec file for 3.21.4, but should be usable for most of
> the 3.x series.  YMMV, this has not been tested too terribly much.
> I'd appreciate a callback if anyone uses it or has a problem - I've
> done plenty of packaging, just not for RPM-based distros.
> 
> 
> RB

From mic at npgx.com.au  Tue Sep 23 13:16:00 2008
From: mic at npgx.com.au (Michael Mansour)
Date: Tue, 23 Sep 2008 22:16:00 +1100
Subject: [rsyslog] [Spam?DateIssue] Re:  RPM spec file
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
Message-ID: <20080923110101.M79951@npgx.com.au>

Hi Rainer,

> [oops, forgotten to hit "send" - now a bit outdated, but still useful...]
> 
> Hi RB,
> 
> I really appreciate the spec file ... but it also creates a bit of a 
> problem for me ;) Let me elaborate: I have stayed away from doing 
> spec files, mostly because I can not ensure they are kept up to 
> date. For that reason, nothing distro-specific is included in the 
> "official source distribution".
> 
> If I now include the spec, it may outdate over time plus people come 
> and ask how to work with it, getting us probably down to distro-
> specific things. I am not sure we want this (or do we want it - I am 
> open to change if there are folks in the community who can commit to 
> support these things [aka "I can not" ;)].
> 
> Or is there any other place where such things could be placed 
> (external RPM repositories come to my mind)? I would be more than 
> happy to link to the relevant places.
> 
> Again, I really value the contribution, I just do not know how to 
> handle it best.

My first introduction to rsyslog was via the Dries repository (now part of
RPMforge):

http://dries.ulyssis.org/rpm/packages/rsyslog/info.html

RPMforge have thousands of packages that are maintained for Red Hat based servers.

The problem is, I've asked both Dag and Dries for updated rsyslog versions for
months and they've never replied. I don't know why and they usually reply, but
sometimes they just don't. 

This is why I build my own RPM's on my (and clients) server and why I made my
spec files available on the rsyslog wiki here:

http://wiki.rsyslog.com/index.php/Here_comes_the_first_story

I also provided them for download on my ftp server.

I have since made spec files for 3.18.0-1 but haven't updated since then,
primarily because of lack of time, and haven't updated the wiki with those
updated specs. However I am happy to do this if BR can give me his one, I'll
see if there's anything that's changed first thing.

The other to note, I rarely install anything from source into production
environments. I try to always leave things packaged or I make the specs and
package them myself. 

rpm/deb/etc are just easier to manage, query, update, remove, verify, etc than
from source.

You're not of the minority when packaging for distributions, many developers
don't do it but at the same time, many developers also do. I know one
developer who uses another software package to take his source tarball and
create packages from it for all distro's (deb's, rpm's, tarp's, etc).

But I understand this isn't an argument of whether you should have packages or
not, after all Red Hat will eventually have rsyslog in RPM (but not for
updated versions from you, only what they release and backport fixes for).

So this really comes down to you not being able to so someone/some people just
have to stand up and take responsibility for packaging it. The user/admin
community definately wants it, a web search for the terms "rsyslog repo" or
"rsyslog rpm" will quickly show you this.

Regards,

Michael.

> Rainer
> 
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of RB
> > Sent: Tuesday, September 23, 2008 5:31 AM
> > To: rsyslog at lists.adiscon.com
> > Subject: [rsyslog] RPM spec file
> > 
> > I was building a virtual host the other day and noticed only
> > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > rather disappointed and immediately whipped up something based on the
> > 2.0.0 specfile.
> > 
> > Attached is a spec file for 3.21.4, but should be usable for most of
> > the 3.x series.  YMMV, this has not been tested too terribly much.
> > I'd appreciate a callback if anyone uses it or has a problem - I've
> > done plenty of packaging, just not for RPM-based distros.
> > 
> > 
> > RB
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
------- End of Original Message -------



From aoz.syn at gmail.com  Tue Sep 23 14:11:38 2008
From: aoz.syn at gmail.com (RB)
Date: Tue, 23 Sep 2008 06:11:38 -0600
Subject: [rsyslog] RPM spec file
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
Message-ID: <4255c2570809230511n3453e09ao8caddc895d8cf925@mail.gmail.com>

> I really appreciate the spec file ... but it also creates a bit of a problem for me ;) Let me elaborate: I have stayed away from doing spec files, mostly because I can not ensure they are kept up to date. For that reason, nothing distro-specific is included in the "official source distribution".

Understood; my posting was more for posterity than expecting you to
include it in your distribution.  People looking for a package can
find it now and do with it as they please.  Well, they could if
attachments were allowed through...  :)  My email to Michael should
help that.

> If I now include the spec, it may outdate over time plus people come and ask how to work with it, getting us probably down to distro-specific things. I am not sure we want this (or do we want it - I am open to change if there are folks in the community who can commit to support these things [aka "I can not" ;)].

As a small-time packager, I have to thank you for trying to remain
distro-agnostic.  Few things are more frustrating than trying to
unravel some developer's flavor-specific compile+install+kitchen_sink
script just to get a piece of software packaged for mine.  Much thanks
for staying with the standard autotools approach and letting the
distros sort out how they want to install your software.


RB


From rgerhards at hq.adiscon.com  Tue Sep 23 14:39:03 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 14:39:03 +0200
Subject: [rsyslog] [Spam?DateIssue] Re:  RPM spec file
In-Reply-To: <20080923110101.M79951@npgx.com.au>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<20080923110101.M79951@npgx.com.au>
Message-ID: <1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>

Hi Michael,

great post. Let us see where we come from here...

I know very well that people like to install from packages - actually, I
am one of them ;) So while I try do keep distro-agnostic (thanks RB for
the good words ;)), I would love to see rsyslog packages for all major
distros and and of course for all versions of rsyslog.

Unfortunately, both my knowledge and time is limited. Knowledge can be
expanded, but that takes time, so we are probably down to the "time
limit" problem - which is hard to overcome. I am not justifying me (why
should I?) nor bashing someone (again, why should I?;)) I am just
stating plain, unfortunate facts.

So I need to do a compromise. That currently is that I stay away from
distro-specific things, even in areas where I could join without making
rsyslog distro-specific. Thankfully, people like you, RB, Michael Biebl,
Infofarmer and some more whom I regrettably have not mentioned now join
in and help create great distro-specific things.

But ... sometimes these things are hard to find. The wiki was the first
approach to permit user-created context in an easy to spot and easy to
edit place. The wiki gets around 100 visitors each day and while this is
obviously not a big number, it is one that is constantly growing. So I
think the wiki was a good thing to have (which is also proven by the
fact that we attracted a number of articles).

The mailing list and forum are also good examples. I often do not need
to reply because someone of you did a much better job offering a
solution than I could have done. Excellent.

What is missing is a place to provide things like the rpm package RB
offered. Specific files and such. A quick solution could be that I
collect such material and place it, without any guarantee and whatsoever
support from me, onto the rsyslog download server and offer that
directory as a free resource to the community. That would at least
ensure that there is a single spot where things can be found by anyone
who searches.

Would this make sense? Any more ideas?

Thanks,
Rainer

On Tue, 2008-09-23 at 22:16 +1100, Michael Mansour wrote:
> Hi Rainer,
> 
> > [oops, forgotten to hit "send" - now a bit outdated, but still useful...]
> > 
> > Hi RB,
> > 
> > I really appreciate the spec file ... but it also creates a bit of a 
> > problem for me ;) Let me elaborate: I have stayed away from doing 
> > spec files, mostly because I can not ensure they are kept up to 
> > date. For that reason, nothing distro-specific is included in the 
> > "official source distribution".
> > 
> > If I now include the spec, it may outdate over time plus people come 
> > and ask how to work with it, getting us probably down to distro-
> > specific things. I am not sure we want this (or do we want it - I am 
> > open to change if there are folks in the community who can commit to 
> > support these things [aka "I can not" ;)].
> > 
> > Or is there any other place where such things could be placed 
> > (external RPM repositories come to my mind)? I would be more than 
> > happy to link to the relevant places.
> > 
> > Again, I really value the contribution, I just do not know how to 
> > handle it best.
> 
> My first introduction to rsyslog was via the Dries repository (now part of
> RPMforge):
> 
> http://dries.ulyssis.org/rpm/packages/rsyslog/info.html
> 
> RPMforge have thousands of packages that are maintained for Red Hat based servers.
> 
> The problem is, I've asked both Dag and Dries for updated rsyslog versions for
> months and they've never replied. I don't know why and they usually reply, but
> sometimes they just don't. 
> 
> This is why I build my own RPM's on my (and clients) server and why I made my
> spec files available on the rsyslog wiki here:
> 
> http://wiki.rsyslog.com/index.php/Here_comes_the_first_story
> 
> I also provided them for download on my ftp server.
> 
> I have since made spec files for 3.18.0-1 but haven't updated since then,
> primarily because of lack of time, and haven't updated the wiki with those
> updated specs. However I am happy to do this if BR can give me his one, I'll
> see if there's anything that's changed first thing.
> 
> The other to note, I rarely install anything from source into production
> environments. I try to always leave things packaged or I make the specs and
> package them myself. 
> 
> rpm/deb/etc are just easier to manage, query, update, remove, verify, etc than
> from source.
> 
> You're not of the minority when packaging for distributions, many developers
> don't do it but at the same time, many developers also do. I know one
> developer who uses another software package to take his source tarball and
> create packages from it for all distro's (deb's, rpm's, tarp's, etc).
> 
> But I understand this isn't an argument of whether you should have packages or
> not, after all Red Hat will eventually have rsyslog in RPM (but not for
> updated versions from you, only what they release and backport fixes for).
> 
> So this really comes down to you not being able to so someone/some people just
> have to stand up and take responsibility for packaging it. The user/admin
> community definately wants it, a web search for the terms "rsyslog repo" or
> "rsyslog rpm" will quickly show you this.
> 
> Regards,
> 
> Michael.
> 
> > Rainer
> > 
> > > -----Original Message-----
> > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > > bounces at lists.adiscon.com] On Behalf Of RB
> > > Sent: Tuesday, September 23, 2008 5:31 AM
> > > To: rsyslog at lists.adiscon.com
> > > Subject: [rsyslog] RPM spec file
> > > 
> > > I was building a virtual host the other day and noticed only
> > > rsyslog-2.0.0 is packaged for CentOS et. al.  Needless to say, I was
> > > rather disappointed and immediately whipped up something based on the
> > > 2.0.0 specfile.
> > > 
> > > Attached is a spec file for 3.21.4, but should be usable for most of
> > > the 3.x series.  YMMV, this has not been tested too terribly much.
> > > I'd appreciate a callback if anyone uses it or has a problem - I've
> > > done plenty of packaging, just not for RPM-based distros.
> > > 
> > > 
> > > RB
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> ------- End of Original Message -------
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog



From rgerhards at hq.adiscon.com  Tue Sep 23 14:44:37 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 14:44:37 +0200
Subject: [rsyslog] abort case
In-Reply-To: <dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com>
References: <dc67eef70809220810s1815ff2evce41b096484eb644@mail.gmail.com>
	<59e975c10809221126o37d8919w674f13aee5acc16f@mail.gmail.com>
	<dc67eef70809230133v696f6145r94044ccb30c9cbdc@mail.gmail.com>
	<alpine.DEB.1.10.0809231355450.18598@sancho.ccd.uniroma2.it>
	<dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com>
Message-ID: <1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>

Lorenzo,

I have done a change to the message handler, it is now using an atomic
memory access operation where it previously did not. I have just pushed
that change as part of the helgrind branch.

I would appreciate if you could give it a try and send me (via private
mail) a helgrind log. 

I don't think that this change is sufficient to resolve the issue. But I
would like to take a granular approach so that I can be sure to find the
real root cause.

Thanks,
Rainer

On Tue, 2008-09-23 at 14:04 +0200, Rainer Gerhards wrote:
> ---------- Forwarded message ----------
> From: Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>
> Date: Tue, Sep 23, 2008 at 2:00 PM
> Subject: Re: Fwd: [Valgrind-users] helgrind points to race in
> pthread_mutex_lock?
> To: Rainer Gerhards <rgerhards at gmail.com>
> 
> RG> Lorenzo,
> RG>
> RG> any chance you could do what is described below? (I guess "no", but I
> RG> thought I ask ;)).
> RG>
> 
> It's running! I didn't recompile, since I didn't find anything new within
> the helgrind branch.
> 
> I'm enclosing the very first "race" message, let me know if this does seem
> better.
> 
> Thank you, and keep on course. Yours,
> 
>        lorenzo




From lorenzo at sancho.ccd.uniroma2.it  Tue Sep 23 15:08:34 2008
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Tue, 23 Sep 2008 15:08:34 +0200 (CEST)
Subject: [rsyslog] abort case
In-Reply-To: <1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>
References: <dc67eef70809220810s1815ff2evce41b096484eb644@mail.gmail.com>
	<59e975c10809221126o37d8919w674f13aee5acc16f@mail.gmail.com>
	<dc67eef70809230133v696f6145r94044ccb30c9cbdc@mail.gmail.com>
	<alpine.DEB.1.10.0809231355450.18598@sancho.ccd.uniroma2.it>
	<dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com>
	<1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>
Message-ID: <alpine.DEB.1.10.0809231454200.18598@sancho.ccd.uniroma2.it>

On Tue, 23 Sep 2008, Rainer Gerhards wrote:

RG> Lorenzo,
RG> 
RG> I have done a change to the message handler, it is now using an atomic
RG> memory access operation where it previously did not. I have just pushed
RG> that change as part of the helgrind branch.
RG> 

Recompiled/reinstalled/restarted. make did recompile msg.c, I don't know 
why rsyslogd didn't get relinked, but I forced relink by removing rsyslogd 
from tools. 

This time, the server crashed even though it was being helground...

Find enclosed the full debug log.

Yours,

	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

From rgerhards at hq.adiscon.com  Tue Sep 23 15:18:18 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 23 Sep 2008 15:18:18 +0200
Subject: [rsyslog] RPM spec file
In-Reply-To: <4255c2570809230511n3453e09ao8caddc895d8cf925@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<4255c2570809230511n3453e09ao8caddc895d8cf925@mail.gmail.com>
Message-ID: <1222175898.2682.190.camel@rgf9dev.intern.adiscon.com>

> script just to get a piece of software packaged for mine.  Much thanks
> for staying with the standard autotools approach and letting the
> distros sort out how they want to install your software.

Praise should go to Peter Vrabec and Michael Biebl, which convinced me
of autotools and also greatly helped me setting things up in a useful
way ;)

Rainer



From aoz.syn at gmail.com  Tue Sep 23 15:53:42 2008
From: aoz.syn at gmail.com (RB)
Date: Tue, 23 Sep 2008 07:53:42 -0600
Subject: [rsyslog] [Spam?DateIssue] Re: RPM spec file
In-Reply-To: <1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<20080923110101.M79951@npgx.com.au>
	<1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>
Message-ID: <4255c2570809230653x3ec19b68mad9fea2da8ceb5f6@mail.gmail.com>

> What is missing is a place to provide things like the rpm package RB
> offered. Specific files and such. A quick solution could be that I
> collect such material and place it, without any guarantee and whatsoever
> support from me, onto the rsyslog download server and offer that
> directory as a free resource to the community. That would at least
> ensure that there is a single spot where things can be found by anyone
> who searches.

Sounds like you need a contrib/ directory, either on your download
server or included in the releases (or both - releases could include a
snapshot).  Linking them from explanatory pages in the wiki will only
serve to help search ranks and generally make everyone happy.  They
should come with (as you said) a disclaimer that best-effort support
may be had on the lists/forums, but that they are unofficial and
therefore not warranted or supported directly by Adiscon.

An alternative would be to allow specific users to upload attachments
to the wiki and link them from a semi-protected page; not as efficient
or as easy to moderate/aggregate, but it would certainly be more
instantaneous.  The 'maintainer' of the given file should additionally
link to instructions on using the package.

Once a sane package is created, most packaging systems make scripted
updates rather easy - use sed to update version numbers/checksums, and
it's good to go.  Gentoo's so easy, all you have to do is re-name the
package file.  Only when major functionality changes (added binaries,
configuration options, etc.) should one have to non-trivially touch
the package.  On that note, the spec file I provided only covers
limited rsyslog functionality - GSSAPI, rfc3195, RELP, and the
debugging tools were all left off simply because I didn't have the
time to build/package their prerequisites.

One last bit: coming from the Gentoo mentality, I'm less interested in
binary packages and far more in the meta-files used to generate those.
 Others may differ, but that may help the bitrot concern.


From aoz.syn at gmail.com  Tue Sep 23 17:13:59 2008
From: aoz.syn at gmail.com (RB)
Date: Tue, 23 Sep 2008 09:13:59 -0600
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
Message-ID: <4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>

> http://kb.monitorware.com/tcp-syslog-fill-s-up-buffer-and-doesn-t-log-single-events-t8705.html

It would seem they're using some version of IOS 12.3 or 12.4; the
'transport X' predicate was introduced some time in the prior but not
documented until the latter.  It would be good to know precisely what
version they are running for reference anyway.

For all I can tell (not having set up a test env myself), it would
seem that just because one indicates TCP as the transport, the
underlying engine doesn't change its semantics and remains at the
UDP-esque 'one packet per message'.  For that matter, I see references
specifically to RFC3164 as opposed to 3195.  Leave it to Cisco...

> I am not an IOS guy, so I would appreciate if someone could drop me the
> right configuration for the routers. Actually, I wonder that they do not
> seem to do that by default. As far as I remember, this has never been an
> issue. I have limited personal experience with PIX, which terminated
> messages correct by default.
:)  My primary experience is with PIX as well.  Looks like the two
primary options are to use 'transport beep' [1] (Cisco's reference to
RFC3195) or to use an ESM filter [2] to add newlines.

[1] http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a00807883c3.html
[2] http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gt_esm.html


From david at lang.hm  Tue Sep 23 17:43:55 2008
From: david at lang.hm (david at lang.hm)
Date: Tue, 23 Sep 2008 08:43:55 -0700 (PDT)
Subject: [rsyslog] [Spam?DateIssue] Re: RPM spec file
In-Reply-To: <4255c2570809230653x3ec19b68mad9fea2da8ceb5f6@mail.gmail.com>
References: <4255c2570809222031j39160feh68fe7fbb531ced9e@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F1C1@grfint2.intern.adiscon.com>
	<20080923110101.M79951@npgx.com.au>
	<1222173543.2682.183.camel@rgf9dev.intern.adiscon.com>
	<4255c2570809230653x3ec19b68mad9fea2da8ceb5f6@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0809230840140.31560@asgard.lang.hm>

On Tue, 23 Sep 2008, RB wrote:

>> What is missing is a place to provide things like the rpm package RB
>> offered. Specific files and such. A quick solution could be that I
>> collect such material and place it, without any guarantee and whatsoever
>> support from me, onto the rsyslog download server and offer that
>> directory as a free resource to the community. That would at least
>> ensure that there is a single spot where things can be found by anyone
>> who searches.
>
> Sounds like you need a contrib/ directory, either on your download
> server or included in the releases (or both - releases could include a
> snapshot).  Linking them from explanatory pages in the wiki will only
> serve to help search ranks and generally make everyone happy.  They
> should come with (as you said) a disclaimer that best-effort support
> may be had on the lists/forums, but that they are unofficial and
> therefore not warranted or supported directly by Adiscon.
>
> An alternative would be to allow specific users to upload attachments
> to the wiki and link them from a semi-protected page; not as efficient
> or as easy to moderate/aggregate, but it would certainly be more
> instantaneous.  The 'maintainer' of the given file should additionally
> link to instructions on using the package.
>
> Once a sane package is created, most packaging systems make scripted
> updates rather easy - use sed to update version numbers/checksums, and
> it's good to go.  Gentoo's so easy, all you have to do is re-name the
> package file.  Only when major functionality changes (added binaries,
> configuration options, etc.) should one have to non-trivially touch
> the package.  On that note, the spec file I provided only covers
> limited rsyslog functionality - GSSAPI, rfc3195, RELP, and the
> debugging tools were all left off simply because I didn't have the
> time to build/package their prerequisites.
>
> One last bit: coming from the Gentoo mentality, I'm less interested in
> binary packages and far more in the meta-files used to generate those.
> Others may differ, but that may help the bitrot concern.

I've been using checkinstall to make the packages as I compile them.

it would be handy if rsyslog could include the spec files that it would 
use to create the appropriate packages, but I can understand the 
reluctance to go there.

but if the dependancies are well documented, then creating the appropriate 
file would be pretty easy.

David Lang


From patrick.shen at net-m.de  Wed Sep 24 10:56:30 2008
From: patrick.shen at net-m.de (Patrick Shen)
Date: Wed, 24 Sep 2008 16:56:30 +0800
Subject: [rsyslog] A question about message size
Message-ID: <48DA00BE.2030705@net-m.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Rainer,

Now I am running latest V3 stable (3.18.4) on my company production
machine. We couldn't upgrade to >=3.21.4 to get the benefit of dynamic
setting MESSAGE size due to company policy.

But we need 4K for message size not 2K by default. So I changed MAXLINE
definition in syslogd.h from 2048 to 4096.

Is it correct? And do we have any other solutions with 3.18.4 ?

Many thanks,

- --
Patrick Shen
Operations Engineer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjaAL4ACgkQkHhYtFevC+PhBgCfVnsQU4Zcn9rVgWZIpS5WXqWz
YxMAn3GWCZ2bPvJFthSCb2HECCfIkF7Y
=Rza/
-----END PGP SIGNATURE-----


From rgerhards at hq.adiscon.com  Wed Sep 24 12:39:14 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 24 Sep 2008 12:39:14 +0200
Subject: [rsyslog] A question about message size
In-Reply-To: <48DA00BE.2030705@net-m.de>
References: <48DA00BE.2030705@net-m.de>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F1D4@grfint2.intern.adiscon.com>

Yes, that's right and that's the only solution for v3-stable.

I haven't merged that change into the stable branch because, among all
of the changes done, this one is among those with the greatest potential
to break things. You do not want to have that in v3-stable (just to note
that backporting it is definitely not a good idea ;)).

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Patrick Shen
> Sent: Wednesday, September 24, 2008 10:57 AM
> To: rsyslog-users
> Subject: [rsyslog] A question about message size
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Rainer,
> 
> Now I am running latest V3 stable (3.18.4) on my company production
> machine. We couldn't upgrade to >=3.21.4 to get the benefit of dynamic
> setting MESSAGE size due to company policy.
> 
> But we need 4K for message size not 2K by default. So I changed
MAXLINE
> definition in syslogd.h from 2048 to 4096.
> 
> Is it correct? And do we have any other solutions with 3.18.4 ?
> 
> Many thanks,
> 
> - --
> Patrick Shen
> Operations Engineer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkjaAL4ACgkQkHhYtFevC+PhBgCfVnsQU4Zcn9rVgWZIpS5WXqWz
> YxMAn3GWCZ2bPvJFthSCb2HECCfIkF7Y
> =Rza/
> -----END PGP SIGNATURE-----
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog


From patrick.shen at net-m.de  Wed Sep 24 13:48:04 2008
From: patrick.shen at net-m.de (Patrick Shen)
Date: Wed, 24 Sep 2008 19:48:04 +0800
Subject: [rsyslog] A question about message size
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F1D4@grfint2.intern.adiscon.com>
References: <48DA00BE.2030705@net-m.de>
	<577465F99B41C842AAFBE9ED71E70ABA44F1D4@grfint2.intern.adiscon.com>
Message-ID: <48DA28F4.2070204@net-m.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for your explanation.

Best regards,
Patrick

Rainer Gerhards wrote:
> Yes, that's right and that's the only solution for v3-stable.
> 
> I haven't merged that change into the stable branch because, among all
> of the changes done, this one is among those with the greatest potential
> to break things. You do not want to have that in v3-stable (just to note
> that backporting it is definitely not a good idea ;)).
> 
> Rainer
> 
>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of Patrick Shen
>> Sent: Wednesday, September 24, 2008 10:57 AM
>> To: rsyslog-users
>> Subject: [rsyslog] A question about message size
>>
> Hi Rainer,
> 
> Now I am running latest V3 stable (3.18.4) on my company production
> machine. We couldn't upgrade to >=3.21.4 to get the benefit of dynamic
> setting MESSAGE size due to company policy.
> 
> But we need 4K for message size not 2K by default. So I changed
>> MAXLINE
> definition in syslogd.h from 2048 to 4096.
> 
> Is it correct? And do we have any other solutions with 3.18.4 ?
> 
> Many thanks,
> 
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

- --
Patrick Shen
Operations Engineer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjaKPQACgkQkHhYtFevC+NsSACgiur1TmRgsFmE7qs8ff1c/xGF
ifUAn2miAH8ILxk6KUiT2geoVRYXee/O
=3pVu
-----END PGP SIGNATURE-----


From rgerhards at hq.adiscon.com  Thu Sep 25 16:04:01 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 25 Sep 2008 16:04:01 +0200
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
	<4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>

> > http://kb.monitorware.com/tcp-syslog-fill-s-up-buffer-and-doesn-t-
> log-single-events-t8705.html
> 
> It would seem they're using some version of IOS 12.3 or 12.4; the
> 'transport X' predicate was introduced some time in the prior but not
> documented until the latter.  It would be good to know precisely what
> version they are running for reference anyway.
> 
> For all I can tell (not having set up a test env myself), it would
> seem that just because one indicates TCP as the transport, the
> underlying engine doesn't change its semantics and remains at the
> UDP-esque 'one packet per message'.  For that matter, I see references
> specifically to RFC3164 as opposed to 3195.  Leave it to Cisco...

Quick follow-up: I am working with them, hope to get some results out of
this conversation. As this bug seems to actually exist in IOS and lots
of IOS are rolled out, I'll try to do a work-around, at least if I can
convince myself that it will work in at least many cases ;)

Rainer


From aoz.syn at gmail.com  Thu Sep 25 17:08:44 2008
From: aoz.syn at gmail.com (RB)
Date: Thu, 25 Sep 2008 09:08:44 -0600
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com>
	<4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com>
	<577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>
Message-ID: <4255c2570809250808g2834d6f4k403af11295cdca2e@mail.gmail.com>

> Quick follow-up: I am working with them, hope to get some results out of
> this conversation. As this bug seems to actually exist in IOS and lots
> of IOS are rolled out, I'll try to do a work-around, at least if I can
> convince myself that it will work in at least many cases ;)

I've been watching the thread.  Seems like some people have adopted a
workaround based on the signature at the beginning of the Cisco log
entries, but that's pretty obviously subpar - their switching gear
doesn't seem to add those, at least on the 12.1 2950 I test against.
Sorry I don't have much else to offer here - like the OP noted, all my
logging has been on the LAN, and trusted segments to boot.  I've seen
setups where remote routers logged over IPSEC or GRE tunnels, but
those were still using UDP.


RB


From rgerhards at hq.adiscon.com  Thu Sep 25 17:11:24 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 25 Sep 2008 17:11:24 +0200
Subject: [rsyslog] cisco router config and plain TCP syslog
In-Reply-To: <4255c2570809250808g2834d6f4k403af11295cdca2e@mail.gmail.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F1B2@grfint2.intern.adiscon.com><4255c2570809230813h16c95ba8v6a70983f728cc4af@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44F203@grfint2.intern.adiscon.com>
	<4255c2570809250808g2834d6f4k403af11295cdca2e@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F206@grfint2.intern.adiscon.com>

> > Quick follow-up: I am working with them, hope to get some results
out
> of
> > this conversation. As this bug seems to actually exist in IOS and
> lots
> > of IOS are rolled out, I'll try to do a work-around, at least if I
> can
> > convince myself that it will work in at least many cases ;)
> 
> I've been watching the thread.  Seems like some people have adopted a
> workaround based on the signature at the beginning of the Cisco log
> entries, but that's pretty obviously subpar - their switching gear
> doesn't seem to add those, at least on the 12.1 2950 I test against.
> Sorry I don't have much else to offer here 

You offered a lot. You post helped track down the problem source and
made make go the right direction :) I think the best thing now is to
wait for what the Cisco folks come up with. And if that takes too long,
I'll add an $WorkAroundCrazyTCPBug directive and see if it works out ;)

> - like the OP noted, all my
> logging has been on the LAN, and trusted segments to boot.  I've seen
> setups where remote routers logged over IPSEC or GRE tunnels, but
> those were still using UDP.

Rainer


From rgerhards at hq.adiscon.com  Fri Sep 26 17:12:09 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 26 Sep 2008 17:12:09 +0200
Subject: [rsyslog] abort case
In-Reply-To: <alpine.DEB.1.10.0809231454200.18598@sancho.ccd.uniroma2.it>
References: <dc67eef70809220810s1815ff2evce41b096484eb644@mail.gmail.com><59e975c10809221126o37d8919w674f13aee5acc16f@mail.gmail.com><dc67eef70809230133v696f6145r94044ccb30c9cbdc@mail.gmail.com><alpine.DEB.1.10.0809231355450.18598@sancho.ccd.uniroma2.it><dc67eef70809230504y571e7300p61d43e02e595c927@mail.gmail.com><1222173877.2682.188.camel@rgf9dev.intern.adiscon.com>
	<alpine.DEB.1.10.0809231454200.18598@sancho.ccd.uniroma2.it>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F21A@grfint2.intern.adiscon.com>

Lorenzo,

I have created a new version with one slight change, to be found in the helgrind branch.

There is also a new valgrind tool called drd inside the valgrind development tree. I think you already downloaded that tree. If so, could you please replace

Valgrind --tool=helgrind .. rsyslogd ...

with

Valgrind --tool=drd .. rsyslogd ...

Drd does an even better job than helgrind. I also changed the source to remove some debug-system related warning, which otherwise would clutter up the error message. But unfortunately, in my lab I did not find any more problems, except for the small change I mentioned. But that one affects program termination (and in a very subtle way), so it should not change anything for you. I'd still be interested in a new run, including debug info, from you.

Thanks,
Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Lorenzo M. Catucci
> Sent: Tuesday, September 23, 2008 3:09 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] abort case
> 
> On Tue, 23 Sep 2008, Rainer Gerhards wrote:
> 
> RG> Lorenzo,
> RG>
> RG> I have done a change to the message handler, it is now using an
> atomic
> RG> memory access operation where it previously did not. I have just
> pushed
> RG> that change as part of the helgrind branch.
> RG>
> 
> Recompiled/reinstalled/restarted. make did recompile msg.c, I don't
> know
> why rsyslogd didn't get relinked, but I forced relink by removing
> rsyslogd
> from tools.
> 
> This time, the server crashed even though it was being helground...
> 
> Find enclosed the full debug log.
> 
> Yours,
> 
> 	lorenzo
> 
> +-------------------------+--------------------------------------------
> --+
> |   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione
> |
> | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor
> Vergata" |
> |                         | Via O. Raimondo 18 ** I-00173 ROMA  **
> ITALY |
> |  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125
> |
> +-------------------------+--------------------------------------------
> --+


From friedl at hq.adiscon.com  Tue Sep 30 12:02:14 2008
From: friedl at hq.adiscon.com (Florian Riedl)
Date: Tue, 30 Sep 2008 12:02:14 +0200
Subject: [rsyslog] rsyslog 3.21.5 released
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>

Hi all,

rsyslog 3.21.5, a member of the development branch, has just been
released. It contains new features, improvements and bug fixes. Most
importantly, a bug has been fixed that can cause a segfault on HUP when
using the UDP input. Also, performance has been greatly enhanced
(special thanks to David Lang for his help). Finally, multi-threaded
handling has been improved. This is a recommended update for all
development branch users.

Changelog:

http://www.rsyslog.com/Article279.phtml

Download:

http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-132.phtml

As always, feedback is appreciated.

Florian Riedl
--
Support
=======

Improving rsyslog is costly, but you can help!  We are looking for
organizations that find rsyslog useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for rsyslog are available, and they help
finance continued maintenance.  Adiscon GmbH, a privately held German
company, is currently funding rsyslog development. We are always looking
for interesting development projects. For details on how to help, please
see http://www.rsyslog.com/doc-how2help.html .




From luigi.perroti at googlemail.com  Tue Sep 30 14:20:11 2008
From: luigi.perroti at googlemail.com (Luigi Perroti)
Date: Tue, 30 Sep 2008 14:20:11 +0200
Subject: [rsyslog] rsyslog 3.21.5 released
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>
Message-ID: <d67280e00809300520s625834am9ecbe4ea3d347a42@mail.gmail.com>

On 9/30/08, Florian Riedl <friedl at hq.adiscon.com> wrote:
> Hi all,
>
> rsyslog 3.21.5, a member of the development branch, has just been
> released.

Hi,

I'm eager to switch from the stable to the development branch but
first I'd like to know if the imfile segmentation fix that was shipped
with 3.18.3 has been merged into the development branch.

The changelogs for 3.21.3 - 3.21.5 don't mention this issue so
probably I'll have to wait but I thought I'd ask just in case.

Thanks!

Regards,
Luigi


From rgerhards at hq.adiscon.com  Tue Sep 30 14:28:20 2008
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 30 Sep 2008 14:28:20 +0200
Subject: [rsyslog] rsyslog 3.21.5 released
In-Reply-To: <d67280e00809300520s625834am9ecbe4ea3d347a42@mail.gmail.com>
References: <577465F99B41C842AAFBE9ED71E70ABA44F23A@grfint2.intern.adiscon.com>
	<d67280e00809300520s625834am9ecbe4ea3d347a42@mail.gmail.com>
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F23F@grfint2.intern.adiscon.com>

Hi Luigi,

yes, this has been merged. All fixes have been merged, except for some
doc things. I think this is the one in question:

http://git.adiscon.com/?p=rsyslog.git;a=commit;h=7b456ce548030ff362d3a2b
e04b1e5c2c89e0dcb

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Luigi Perroti
> Sent: Tuesday, September 30, 2008 2:20 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog 3.21.5 released
> 
> On 9/30/08, Florian Riedl <friedl at hq.adiscon.com> wrote:
> > Hi all,
> >
> > rsyslog 3.21.5, a member of the development branch, has just been
> > released.
> 
> Hi,
> 
> I'm eager to switch from the stable to the development branch but
> first I'd like to know if the imfile segmentation fix that was shipped
> with 3.18.3 has been merged into the development branch.
> 
> The changelogs for 3.21.3 - 3.21.5 don't mention this issue so
> probably I'll have to wait but I thought I'd ask just in case.
> 
> Thanks!
> 
> Regards,
> Luigi
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com


From luigi.perroti at googlemail.com  Tue Sep 30 19:29:56 2008
From: luigi.perroti at googlemail.com (Luigi Perroti)
Date: Tue, 30 Sep 2008 19:29:56 +0200
Subject: [rsyslog] MainMsgQueueWorkerThreads and devel branch
Message-ID: <d67280e00809301029q4b96d88sdf29d0d26f357a79@mail.gmail.com>

Hi,

I've upgraded from 3.18.3-Test6 to 3.21.5 and I noticed that I can
only use a value of 1 for $MainMsgQueueWorkerThreads. I had it set to
8 on the stable branch.

If I set its value to something greater than 1 rsyslog writes the pid
file but doesn't start.

1 thread should be enough for my needs and I can stick with it.
Still I'd like to know if this behaviour is known to the developers,
maybe it is since the documentation recommends a value of 1.

Regards,
Luigi