From rgerhards at hq.adiscon.com Tue Jul 1 15:36:11 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 1 Jul 2008 15:36:11 +0200 Subject: [rsyslog] rsyslog 3.19.8 (devel) released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA3092F2@grfint2.intern.adiscon.com> Hi all, I have just released rsyslog 3.19.8, a new release of the development branch. Most importantly, it adds a bugfix for TLS mode. A TLS session was lost if the OS returned a retry request via the API. This happened frequently on some platforms. The situation is now properly handled. Feature-wise error number have been added to most rsyslog messages, making it easier to troubleshoot problems. There are also some other minor improvements and bug fixes. This is a recommended update for all devel branch users. Change Log: http://www.rsyslog.com/Article247.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-116.phtml I hope this release is useful. Feedback is appreciated. Rainer Gerhards From mycleanjunk at gmail.com Wed Jul 2 05:16:41 2008 From: mycleanjunk at gmail.com (Scott Phuong) Date: Tue, 1 Jul 2008 20:16:41 -0700 Subject: [rsyslog] configuration file question and error message question Message-ID: <17945960807012016t753757aaxd0c1add1d3a12bb1@mail.gmail.com> Hi, I am using rsyslog 3.16.2. When I specify the script of command to issue when a log reaches its max size, how do I specify the command with parameters? This is what I did: $outchannel ch_common,/var/log/messages/1048675,\ mv -f /var/log/messages /var/log/messages.0 Do I use a quotation mark or a single quote or something else? Your help says to specify a script but does that line except a single word for the script, meaning it can not take parameters? To clarify, if I have a script that is named rotate and I want to use it for multiple logs, I would like to say "rotate /var/log/message". Is this possible? I am getting this error message: rsyslogd: omfwd.c:318: doTryResume: Assertion `0' failed. What does this mean? Thanks for your help!! I really like how rsyslogd has a lot of configurable properties. Scott From rgerhards at hq.adiscon.com Wed Jul 2 08:28:59 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 2 Jul 2008 08:28:59 +0200 Subject: [rsyslog] configuration file question and error message question In-Reply-To: <17945960807012016t753757aaxd0c1add1d3a12bb1@mail.gmail.com> References: <17945960807012016t753757aaxd0c1add1d3a12bb1@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA3092F7@grfint2.intern.adiscon.com> Hi, > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Scott Phuong > Sent: Wednesday, July 02, 2008 5:17 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] configuration file question and error message > question > > Hi, > > I am using rsyslog 3.16.2. > > When I specify the script of command to issue when a log reaches its > max size, how do I specify the command with parameters? The command can have EXACTLY one parameter. > This is what I > did: > > $outchannel ch_common,/var/log/messages/1048675,\ > mv -f /var/log/messages /var/log/messages.0 > > Do I use a quotation mark or a single quote or something else? Your > help says to specify a script but does that line except a single word > for the script, meaning it can not take parameters? To clarify, if I > have a script that is named rotate and I want to use it for multiple > logs, I would like to say "rotate /var/log/message". Is this possible? Yes, but you can not specify more than one parameter. The outchannel code is scheduled to be superseded by something new that works along the lines of the regular log file (just with an additional parameter). However, until this is done, we need to live with the current restriction. > > > I am getting this error message: > rsyslogd: omfwd.c:318: doTryResume: Assertion `0' failed. > > What does this mean? Something goes really wrong ;) I have checked that assertion and there seems to be some problem with the retry log. Can you reproduce it? If so, can you provide a full debug log (run interactively with -dn option)? > > Thanks for your help!! I really like how rsyslogd has a lot of > configurable properties. :) Rainer > > Scott > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog From mycleanjunk at gmail.com Wed Jul 2 10:15:07 2008 From: mycleanjunk at gmail.com (Scott Phuong) Date: Wed, 2 Jul 2008 01:15:07 -0700 Subject: [rsyslog] rsyslog threads questions Message-ID: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com> Hi, I have 3.16.2 which was recently released. I see that under certain conditions rsyslogd spawns a lot of threads: 5949 root 11216 S rsyslogd 5950 root 11216 S rsyslogd 5951 root 11216 S rsyslogd 5952 root 11216 S rsyslogd 5953 root 11216 S rsyslogd 5954 root 11216 S rsyslogd 5985 root Z [rsyslogd] 6445 root Z [rsyslogd] I had to kill the rsyslogd and restart it. The first invocation had a pid of 219 before it had to be killed. The second invocation of pid which you see above starts with 5949. The difference is the amount of zombie threads that were invoked by rsyslogd before I had to kill the first invocation of it. The question is under what conditions does rsyslogd spawn a new thread/process and why was it a zombie? I am running rsyslogd in an embedded environment and not a regular laptop/desktop. In addition, I am using busybox and I believe the syslog buffer size is set to something very low or perhaps none at all. Would this be a factor? Furthermore, I ran rsyslogd with -c3 and also without -c3 and both cases happen. Are these issues already known and fixed in a later version? Sorry, if I am asking the same questions or have the same issues as previous people but without the ability to search (or at least, I don't know how to) the archive, I don't know if my problem/questions has already been seen and/or resolved. Thank you very much for your support. Scott From rgerhards at hq.adiscon.com Wed Jul 2 10:27:18 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 02 Jul 2008 10:27:18 +0200 Subject: [rsyslog] rsyslog threads questions In-Reply-To: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com> References: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com> Message-ID: <1214987239.7184.13.camel@rgf9dev.intern.adiscon.com> On Wed, 2008-07-02 at 01:15 -0700, Scott Phuong wrote: > Hi, > > I have 3.16.2 which was recently released. I see that under certain > conditions rsyslogd spawns a lot of threads: > 5949 root 11216 S rsyslogd > 5950 root 11216 S rsyslogd > 5951 root 11216 S rsyslogd > 5952 root 11216 S rsyslogd > 5953 root 11216 S rsyslogd > 5954 root 11216 S rsyslogd > 5985 root Z [rsyslogd] > 6445 root Z [rsyslogd] > > I had to kill the rsyslogd and restart it. The first invocation had a > pid of 219 before it had to be killed. The second invocation of pid > which you see above starts with 5949. The difference is the amount of > zombie threads that were invoked by rsyslogd before I had to kill the > first invocation of it. I have no explanation yet for the zombies. They should not happen and so far I have never seen them. We may need to go through a debug log (which will become very large) to find out what's going on. > The question is under what conditions does rsyslogd spawn a new > thread/process and why was it a zombie? Unfortunately, there is no quick answer. A quick one may be: when it needs them, based on queue watermark settings and based on you configuration. But to really understand it, you need to read this doc: http://www.rsyslog.com/doc-queues.html The doc also describes all the knobs that you can use to control thread creation. There are many ;) > I am running rsyslogd in an > embedded environment and not a regular laptop/desktop. Interesting use case... > In addition, I > am using busybox and I believe the syslog buffer size is set to what do yo mean by "syslog buffer size"? The length of a receive buffer? It is 2K, thus single messages up to 2K are supported. It can be changed by modifying the MAXLINE define. Note that stock syslogd (and RFC3164) support only up to 1K. > something very low or perhaps none at all. Would this be a factor? > Furthermore, I ran rsyslogd with -c3 and also without -c3 and both > cases happen. The compatibility modes do not affect queue operation. > Are these issues already known and fixed in a later version? Sorry, if > I am asking the same questions or have the same issues as previous > people but without the ability to search (or at least, I don't know > how to) the archive, I don't know if my problem/questions has already > been seen and/or resolved. If we need to find out about the zombies, we need to move on to the current devel version. So I would give that a try in any case. 3.16.2 will (most probably) be replaced by 3.18.0 (based on the current beta) next week. So I won't touch it any longer. Looking forward to your feedback, Rainer > > Thank you very much for your support. > > Scott > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog From rgerhards at hq.adiscon.com Wed Jul 2 11:07:28 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 2 Jul 2008 11:07:28 +0200 Subject: [rsyslog] rsyslog error message repository Message-ID: <577465F99B41C842AAFBE9ED71E70ABA3092FA@grfint2.intern.adiscon.com> Hi all, starting with 3.19.8, rsyslog finally offers specific error codes as part of the syslog tag. For example, rsyslogd-2040 means that a file could not be found. I have added these tags both to facilitate log parsing as well as easy troubleshooting. But a tag is only as good as the information that it helps to find. Consequently, I have started to describe error cases inside the knowledge base's event repository: http://kb.monitorware.com/kbeventdb-list-1-Adiscon-rsyslog.html So far, there is only a limited set of messages available (to phrase it politely ;)), but I plan to increase it over time. Note that there is an interactive feature where questions to the message can directly be posted to the forum. I hope this is useful. If you run into an error message that is not-yet described, let us know and we'll add an entry. In the long term, the new knowledge base part should be able to solve most problems. Feedback is appreciated, Rainer From mycleanjunk at gmail.com Wed Jul 2 21:04:23 2008 From: mycleanjunk at gmail.com (Scott Phuong) Date: Wed, 2 Jul 2008 12:04:23 -0700 Subject: [rsyslog] rsyslog threads questions In-Reply-To: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com> References: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com> Message-ID: <17945960807021204n38c2e9bfka17e9341035295f3@mail.gmail.com> Hi Rainer, Thanks for your reply. Looking at the default settings (from the online help's configuration page), they are what I wanted. The main messages queue is set to fix sized array with 1 worker thread created at maximum and action queues are direct mode which according to the queue document page, means that there will not be a worker thread created. Is my understanding correct? If yes, how do I quickly check without using the -d option if the defaults are set correctly? Or what do I look for in the debug messages that gets printed out to ensure this? You also mentioned that version 3.18.0 is probably going to be released as the stable version next week. I see on the webpage there is a 3.17.4 and 3.17.5. Are these two versions similiar to 3.18.0? Also, how come I did not get your reply in my email inbox? My account settings look correct. Thanks, Scott Phuong As for the syslog buffer size, that applies to syslogd and does not apply to rsyslog. My configuration files do not change the Action queue or Worker queue parameters at all. Looking at On Wed, 2008-07-02 at 01:15 -0700, Scott Phuong wrote: > Hi, > > I have 3.16.2 which was recently released. I see that under certain > conditions rsyslogd spawns a lot of threads: > 5949 root 11216 S rsyslogd > 5950 root 11216 S rsyslogd > 5951 root 11216 S rsyslogd > 5952 root 11216 S rsyslogd > 5953 root 11216 S rsyslogd > 5954 root 11216 S rsyslogd > 5985 root Z [rsyslogd] > 6445 root Z [rsyslogd] > > I had to kill the rsyslogd and restart it. The first invocation had a > pid of 219 before it had to be killed. The second invocation of pid > which you see above starts with 5949. The difference is the amount of > zombie threads that were invoked by rsyslogd before I had to kill the > first invocation of it. I have no explanation yet for the zombies. They should not happen and so far I have never seen them. We may need to go through a debug log (which will become very large) to find out what's going on. > The question is under what conditions does rsyslogd spawn a new > thread/process and why was it a zombie? Unfortunately, there is no quick answer. A quick one may be: when it needs them, based on queue watermark settings and based on you configuration. But to really understand it, you need to read this doc: http://www.rsyslog.com/doc-queues.html The doc also describes all the knobs that you can use to control thread creation. There are many ;) > I am running rsyslogd in an > embedded environment and not a regular laptop/desktop. Interesting use case... > In addition, I > am using busybox and I believe the syslog buffer size is set to what do yo mean by "syslog buffer size"? The length of a receive buffer? It is 2K, thus single messages up to 2K are supported. It can be changed by modifying the MAXLINE define. Note that stock syslogd (and RFC3164) support only up to 1K. > something very low or perhaps none at all. Would this be a factor? > Furthermore, I ran rsyslogd with -c3 and also without -c3 and both > cases happen. The compatibility modes do not affect queue operation. > Are these issues already known and fixed in a later version? Sorry, if > I am asking the same questions or have the same issues as previous > people but without the ability to search (or at least, I don't know > how to) the archive, I don't know if my problem/questions has already > been seen and/or resolved. If we need to find out about the zombies, we need to move on to the current devel version. So I would give that a try in any case. 3.16.2 will (most probably) be replaced by 3.18.0 (based on the current beta) next week. So I won't touch it any longer. Looking forward to your feedback, Rainer > > Thank you very much for your support. > > Scott > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog From mycleanjunk at gmail.com Thu Jul 3 08:48:02 2008 From: mycleanjunk at gmail.com (Scott Phuong) Date: Wed, 2 Jul 2008 23:48:02 -0700 Subject: [rsyslog] rsyslog threads questions In-Reply-To: <17945960807021757g3a9f8c16le353e03f17b5f18c@mail.gmail.com> References: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com> <17945960807021204n38c2e9bfka17e9341035295f3@mail.gmail.com> <17945960807021749q29f89272w74b8c30d45fba97b@mail.gmail.com> <17945960807021757g3a9f8c16le353e03f17b5f18c@mail.gmail.com> Message-ID: <17945960807022348i50dcb4e9p912059a42c693796@mail.gmail.com> Sorry for sending a lot of emails. I believe I have root-cause the issue in 3.17.5. It appears that when the rsyslog.conf file does something like this: emerg.* *;mytemplate The code executes wallmsg which does forks. This is how I got a lot of processes were being created in my scenario. Although one would hope that a system doesn't misbehave this awful, nonetheless it does happen. First, it seems that the emergency messages should go to all those that are logged in via whatever mechanism (i.e. telnet, console, stty, ssh, etc...), this message should appear on all those "screens". I see that it does not even if I just logged 1 message at this serverity. I believe this is how syslog described setting up a wall message and what it is. Is this a bug? Lastly, when the child of the fork exits, it does not appear to be removed from Linux and still continues to eat up memory and is reported as a zombie. It appears that when the workerthread has been "destroyed/deconstructed" does things clear up. I am not sure if this is a rsyslogd problem or a linux or gcc problem. Any ideas? Thanks, Scott On Wed, Jul 2, 2008 at 5:57 PM, Scott Phuong wrote: > Hi, > > I've attached four files. Two of which are debug dumps, one is the > conf file and the last one is a test case scenario that constantly > fails on my end. I hope this gives a little more information. > Furthermore, the dumps are from 3.17.5 which is the "closest" version > to 3.18.0 that I was able to find. > > Both failed scenarios occur when lots of messages were being flooded > to rsyslogd at a very fast rate (look at logtest.c) The > my_arm_rsyslog_suicide_debug.txt received a sigsegv fault while > my_arm_rsyslog_sh_cannot_fork caused so many "Z [rsyslogd]" threads > that it took up so much memory that executing any command as simple as > 'ls -l' would not work from the command line. I think the number of > threads grew as much as the number of messages. In the latter > scenario, after killing logtest.c, it didn't look like the those > zombies threads went away until I did a CTRL+C to the rsyslogd which > was running in the foreground since I use the "-dn" option. > > This is on an embedded system that runs significantly slower than a > desktop or laptop so maybe it would be harder to reproduce on a > regular computer. I looked at all the parameters that I believe could > affect this and believe for the most part the defaults are more than > adequate. The main message queue never looked like it hit the high > water mark but it did hit the lower one. So, I don't think messages > were being dropped (not sure) or an overflow condition occurred. > > The processor is ARM-based and it is using Linux kernel 2.6.16.12 and > compiled using GCC and the standard GNU C libraries version 3.4.5. > Rsyslog source code is cross-compiled using the following configure > line: > > ./configure --disable-zlib --disable-largefile > --enable-share=yes > --prefix=/ > --host=arm-unknown-linux-gnu > ac_cv_func_malloc_0_nonnull=yes > ac_cv_func_realloc_0_nonnull=yes > ac_cv_func_lstat_dereferences_slashed_symlink=yes > ac_cv_func_stat_empty_string_bug=no > enable_debug=no > enable_rtinst=no > > Lastly, the logtest was executed with just the "-s" parameter. It is a > simple C file that I came up with. > > I took a look at the debug messages and it does not appear that new > threads are created via calls to wtpStartWrkr in wtp.c. > > Any help I can bring to solve this issue, please let me know. I hope I > am not doing anything wrong here. > > Thanks, > > Scott >> >> On Wed, Jul 2, 2008 at 12:04 PM, Scott Phuong wrote: >>> Hi Rainer, >>> >>> Thanks for your reply. Looking at the default settings (from the >>> online help's configuration page), they are what I wanted. The main >>> messages queue is set to fix sized array with 1 worker thread created >>> at maximum and action queues are direct mode which according to the >>> queue document page, means that there will not be a worker thread >>> created. Is my understanding correct? If yes, how do I quickly check >>> without using the -d option if the defaults are set correctly? Or what >>> do I look for in the debug messages that gets printed out to ensure >>> this? >>> >>> You also mentioned that version 3.18.0 is probably going to be >>> released as the stable version next week. I see on the webpage there >>> is a 3.17.4 and 3.17.5. Are these two versions similiar to 3.18.0? >>> >>> Also, how come I did not get your reply in my email inbox? My account >>> settings look correct. >>> >>> Thanks, >>> >>> Scott Phuong >>> >>> As for the syslog buffer size, that applies to syslogd and does not >>> apply to rsyslog. >>> >>> >>> >>> My configuration files do not change the Action queue or Worker queue >>> parameters at all. Looking at >>> On Wed, 2008-07-02 at 01:15 -0700, Scott Phuong wrote: >>>> Hi, >>>> >>>> I have 3.16.2 which was recently released. I see that under certain >>>> conditions rsyslogd spawns a lot of threads: >>>> 5949 root 11216 S rsyslogd >>>> 5950 root 11216 S rsyslogd >>>> 5951 root 11216 S rsyslogd >>>> 5952 root 11216 S rsyslogd >>>> 5953 root 11216 S rsyslogd >>>> 5954 root 11216 S rsyslogd >>>> 5985 root Z [rsyslogd] >>>> 6445 root Z [rsyslogd] >>>> >>>> I had to kill the rsyslogd and restart it. The first invocation had a >>>> pid of 219 before it had to be killed. The second invocation of pid >>>> which you see above starts with 5949. The difference is the amount of >>>> zombie threads that were invoked by rsyslogd before I had to kill the >>>> first invocation of it. >>> >>> I have no explanation yet for the zombies. They should not happen and so >>> far I have never seen them. We may need to go through a debug log (which >>> will become very large) to find out what's going on. >>> >>>> The question is under what conditions does rsyslogd spawn a new >>>> thread/process and why was it a zombie? >>> >>> Unfortunately, there is no quick answer. A quick one may be: when it >>> needs them, based on queue watermark settings and based on you >>> configuration. But to really understand it, you need to read this doc: >>> >>> http://www.rsyslog.com/doc-queues.html >>> >>> The doc also describes all the knobs that you can use to control thread >>> creation. There are many ;) >>> >>>> I am running rsyslogd in an >>>> embedded environment and not a regular laptop/desktop. >>> >>> Interesting use case... >>> >>>> In addition, I >>>> am using busybox and I believe the syslog buffer size is set to >>> >>> what do yo mean by "syslog buffer size"? The length of a receive buffer? >>> It is 2K, thus single messages up to 2K are supported. It can be changed >>> by modifying the MAXLINE define. Note that stock syslogd (and RFC3164) >>> support only up to 1K. >>> >>>> something very low or perhaps none at all. Would this be a factor? >>>> Furthermore, I ran rsyslogd with -c3 and also without -c3 and both >>>> cases happen. >>> >>> The compatibility modes do not affect queue operation. >>> >>>> Are these issues already known and fixed in a later version? Sorry, if >>>> I am asking the same questions or have the same issues as previous >>>> people but without the ability to search (or at least, I don't know >>>> how to) the archive, I don't know if my problem/questions has already >>>> been seen and/or resolved. >>> >>> If we need to find out about the zombies, we need to move on to the >>> current devel version. So I would give that a try in any case. 3.16.2 >>> will (most probably) be replaced by 3.18.0 (based on the current beta) >>> next week. So I won't touch it any longer. >>> >>> Looking forward to your feedback, >>> Rainer >>> >>>> >>>> Thank you very much for your support. >>>> >>>> Scott >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> >> > From rgerhards at hq.adiscon.com Thu Jul 3 08:59:26 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 3 Jul 2008 08:59:26 +0200 Subject: [rsyslog] rsyslog threads questions In-Reply-To: <17945960807022348i50dcb4e9p912059a42c693796@mail.gmail.com> References: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com><17945960807021204n38c2e9bfka17e9341035295f3@mail.gmail.com><17945960807021749q29f89272w74b8c30d45fba97b@mail.gmail.com><17945960807021757g3a9f8c16le353e03f17b5f18c@mail.gmail.com> <17945960807022348i50dcb4e9p912059a42c693796@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309307@grfint2.intern.adiscon.com> Hi Scott, will reply in more detail later today, but one thing quickly. This is very good information. The wall code is ooooooooooold, stems back to sysklogd and has only been slightly modified. I have to admit it is not much on my testing radar. So I assume you found the bug. I think I'll need to re-design it. With the queue engine, forking off should not really be necessary. I need to see if that goes into the v3-stable soon or is kept at the devel tree. I am a bit hesitant to move it to stable, as it involves a good chance for additional bugs... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Scott Phuong > Sent: Thursday, July 03, 2008 8:48 AM > To: rsyslog at lists.adiscon.com > Subject: Re: [rsyslog] rsyslog threads questions > > Sorry for sending a lot of emails. I believe I have root-cause the > issue in 3.17.5. It appears that when the rsyslog.conf file does > something like this: > emerg.* *;mytemplate > > The code executes wallmsg which does forks. This is how I got a lot of > processes were being created in my scenario. Although one would hope > that a system doesn't misbehave this awful, nonetheless it does > happen. First, it seems that the emergency messages should go to all > those that are logged in via whatever mechanism (i.e. telnet, console, > stty, ssh, etc...), this message should appear on all those "screens". > I see that it does not even if I just logged 1 message at this > serverity. I believe this is how syslog described setting up a wall > message and what it is. Is this a bug? > > Lastly, when the child of the fork exits, it does not appear to be > removed from Linux and still continues to eat up memory and is > reported as a zombie. It appears that when the workerthread has been > "destroyed/deconstructed" does things clear up. I am not sure if this > is a rsyslogd problem or a linux or gcc problem. Any ideas? > > Thanks, > > Scott > > > > On Wed, Jul 2, 2008 at 5:57 PM, Scott Phuong > wrote: > > Hi, > > > > I've attached four files. Two of which are debug dumps, one is the > > conf file and the last one is a test case scenario that constantly > > fails on my end. I hope this gives a little more information. > > Furthermore, the dumps are from 3.17.5 which is the "closest" version > > to 3.18.0 that I was able to find. > > > > Both failed scenarios occur when lots of messages were being flooded > > to rsyslogd at a very fast rate (look at logtest.c) The > > my_arm_rsyslog_suicide_debug.txt received a sigsegv fault while > > my_arm_rsyslog_sh_cannot_fork caused so many "Z [rsyslogd]" > threads > > that it took up so much memory that executing any command as simple > as > > 'ls -l' would not work from the command line. I think the number of > > threads grew as much as the number of messages. In the latter > > scenario, after killing logtest.c, it didn't look like the those > > zombies threads went away until I did a CTRL+C to the rsyslogd which > > was running in the foreground since I use the "-dn" option. > > > > This is on an embedded system that runs significantly slower than a > > desktop or laptop so maybe it would be harder to reproduce on a > > regular computer. I looked at all the parameters that I believe could > > affect this and believe for the most part the defaults are more than > > adequate. The main message queue never looked like it hit the high > > water mark but it did hit the lower one. So, I don't think messages > > were being dropped (not sure) or an overflow condition occurred. > > > > The processor is ARM-based and it is using Linux kernel 2.6.16.12 and > > compiled using GCC and the standard GNU C libraries version 3.4.5. > > Rsyslog source code is cross-compiled using the following configure > > line: > > > > ./configure --disable-zlib --disable-largefile > > --enable-share=yes > > --prefix=/ > > --host=arm-unknown-linux-gnu > > ac_cv_func_malloc_0_nonnull=yes > > ac_cv_func_realloc_0_nonnull=yes > > > ac_cv_func_lstat_dereferences_slashed_symlink=yes > > ac_cv_func_stat_empty_string_bug=no > > enable_debug=no > > enable_rtinst=no > > > > Lastly, the logtest was executed with just the "-s" parameter. It is > a > > simple C file that I came up with. > > > > I took a look at the debug messages and it does not appear that new > > threads are created via calls to wtpStartWrkr in wtp.c. > > > > Any help I can bring to solve this issue, please let me know. I hope > I > > am not doing anything wrong here. > > > > Thanks, > > > > Scott > >> > >> On Wed, Jul 2, 2008 at 12:04 PM, Scott Phuong > wrote: > >>> Hi Rainer, > >>> > >>> Thanks for your reply. Looking at the default settings (from the > >>> online help's configuration page), they are what I wanted. The main > >>> messages queue is set to fix sized array with 1 worker thread > created > >>> at maximum and action queues are direct mode which according to the > >>> queue document page, means that there will not be a worker thread > >>> created. Is my understanding correct? If yes, how do I quickly > check > >>> without using the -d option if the defaults are set correctly? Or > what > >>> do I look for in the debug messages that gets printed out to ensure > >>> this? > >>> > >>> You also mentioned that version 3.18.0 is probably going to be > >>> released as the stable version next week. I see on the webpage > there > >>> is a 3.17.4 and 3.17.5. Are these two versions similiar to 3.18.0? > >>> > >>> Also, how come I did not get your reply in my email inbox? My > account > >>> settings look correct. > >>> > >>> Thanks, > >>> > >>> Scott Phuong > >>> > >>> As for the syslog buffer size, that applies to syslogd and does not > >>> apply to rsyslog. > >>> > >>> > >>> > >>> My configuration files do not change the Action queue or Worker > queue > >>> parameters at all. Looking at > >>> On Wed, 2008-07-02 at 01:15 -0700, Scott Phuong wrote: > >>>> Hi, > >>>> > >>>> I have 3.16.2 which was recently released. I see that under > certain > >>>> conditions rsyslogd spawns a lot of threads: > >>>> 5949 root 11216 S rsyslogd > >>>> 5950 root 11216 S rsyslogd > >>>> 5951 root 11216 S rsyslogd > >>>> 5952 root 11216 S rsyslogd > >>>> 5953 root 11216 S rsyslogd > >>>> 5954 root 11216 S rsyslogd > >>>> 5985 root Z [rsyslogd] > >>>> 6445 root Z [rsyslogd] > >>>> > >>>> I had to kill the rsyslogd and restart it. The first invocation > had a > >>>> pid of 219 before it had to be killed. The second invocation of > pid > >>>> which you see above starts with 5949. The difference is the amount > of > >>>> zombie threads that were invoked by rsyslogd before I had to kill > the > >>>> first invocation of it. > >>> > >>> I have no explanation yet for the zombies. They should not happen > and so > >>> far I have never seen them. We may need to go through a debug log > (which > >>> will become very large) to find out what's going on. > >>> > >>>> The question is under what conditions does rsyslogd spawn a new > >>>> thread/process and why was it a zombie? > >>> > >>> Unfortunately, there is no quick answer. A quick one may be: when > it > >>> needs them, based on queue watermark settings and based on you > >>> configuration. But to really understand it, you need to read this > doc: > >>> > >>> http://www.rsyslog.com/doc-queues.html > >>> > >>> The doc also describes all the knobs that you can use to control > thread > >>> creation. There are many ;) > >>> > >>>> I am running rsyslogd in an > >>>> embedded environment and not a regular laptop/desktop. > >>> > >>> Interesting use case... > >>> > >>>> In addition, I > >>>> am using busybox and I believe the syslog buffer size is set to > >>> > >>> what do yo mean by "syslog buffer size"? The length of a receive > buffer? > >>> It is 2K, thus single messages up to 2K are supported. It can be > changed > >>> by modifying the MAXLINE define. Note that stock syslogd (and > RFC3164) > >>> support only up to 1K. > >>> > >>>> something very low or perhaps none at all. Would this be a factor? > >>>> Furthermore, I ran rsyslogd with -c3 and also without -c3 and both > >>>> cases happen. > >>> > >>> The compatibility modes do not affect queue operation. > >>> > >>>> Are these issues already known and fixed in a later version? > Sorry, if > >>>> I am asking the same questions or have the same issues as previous > >>>> people but without the ability to search (or at least, I don't > know > >>>> how to) the archive, I don't know if my problem/questions has > already > >>>> been seen and/or resolved. > >>> > >>> If we need to find out about the zombies, we need to move on to the > >>> current devel version. So I would give that a try in any case. > 3.16.2 > >>> will (most probably) be replaced by 3.18.0 (based on the current > beta) > >>> next week. So I won't touch it any longer. > >>> > >>> Looking forward to your feedback, > >>> Rainer > >>> > >>>> > >>>> Thank you very much for your support. > >>>> > >>>> Scott > >>>> _______________________________________________ > >>>> rsyslog mailing list > >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>> > >> > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog From mycleanjunk at gmail.com Thu Jul 3 02:57:39 2008 From: mycleanjunk at gmail.com (Scott Phuong) Date: Wed, 2 Jul 2008 17:57:39 -0700 Subject: [rsyslog] rsyslog threads questions In-Reply-To: <17945960807021749q29f89272w74b8c30d45fba97b@mail.gmail.com> References: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com> <17945960807021204n38c2e9bfka17e9341035295f3@mail.gmail.com> <17945960807021749q29f89272w74b8c30d45fba97b@mail.gmail.com> Message-ID: <17945960807021757g3a9f8c16le353e03f17b5f18c@mail.gmail.com> Hi, I've attached four files. Two of which are debug dumps, one is the conf file and the last one is a test case scenario that constantly fails on my end. I hope this gives a little more information. Furthermore, the dumps are from 3.17.5 which is the "closest" version to 3.18.0 that I was able to find. Both failed scenarios occur when lots of messages were being flooded to rsyslogd at a very fast rate (look at logtest.c) The my_arm_rsyslog_suicide_debug.txt received a sigsegv fault while my_arm_rsyslog_sh_cannot_fork caused so many "Z [rsyslogd]" threads that it took up so much memory that executing any command as simple as 'ls -l' would not work from the command line. I think the number of threads grew as much as the number of messages. In the latter scenario, after killing logtest.c, it didn't look like the those zombies threads went away until I did a CTRL+C to the rsyslogd which was running in the foreground since I use the "-dn" option. This is on an embedded system that runs significantly slower than a desktop or laptop so maybe it would be harder to reproduce on a regular computer. I looked at all the parameters that I believe could affect this and believe for the most part the defaults are more than adequate. The main message queue never looked like it hit the high water mark but it did hit the lower one. So, I don't think messages were being dropped (not sure) or an overflow condition occurred. The processor is ARM-based and it is using Linux kernel 2.6.16.12 and compiled using GCC and the standard GNU C libraries version 3.4.5. Rsyslog source code is cross-compiled using the following configure line: ./configure --disable-zlib --disable-largefile --enable-share=yes --prefix=/ --host=arm-unknown-linux-gnu ac_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes ac_cv_func_lstat_dereferences_slashed_symlink=yes ac_cv_func_stat_empty_string_bug=no enable_debug=no enable_rtinst=no Lastly, the logtest was executed with just the "-s" parameter. It is a simple C file that I came up with. I took a look at the debug messages and it does not appear that new threads are created via calls to wtpStartWrkr in wtp.c. Any help I can bring to solve this issue, please let me know. I hope I am not doing anything wrong here. Thanks, Scott > > On Wed, Jul 2, 2008 at 12:04 PM, Scott Phuong wrote: >> Hi Rainer, >> >> Thanks for your reply. Looking at the default settings (from the >> online help's configuration page), they are what I wanted. The main >> messages queue is set to fix sized array with 1 worker thread created >> at maximum and action queues are direct mode which according to the >> queue document page, means that there will not be a worker thread >> created. Is my understanding correct? If yes, how do I quickly check >> without using the -d option if the defaults are set correctly? Or what >> do I look for in the debug messages that gets printed out to ensure >> this? >> >> You also mentioned that version 3.18.0 is probably going to be >> released as the stable version next week. I see on the webpage there >> is a 3.17.4 and 3.17.5. Are these two versions similiar to 3.18.0? >> >> Also, how come I did not get your reply in my email inbox? My account >> settings look correct. >> >> Thanks, >> >> Scott Phuong >> >> As for the syslog buffer size, that applies to syslogd and does not >> apply to rsyslog. >> >> >> >> My configuration files do not change the Action queue or Worker queue >> parameters at all. Looking at >> On Wed, 2008-07-02 at 01:15 -0700, Scott Phuong wrote: >>> Hi, >>> >>> I have 3.16.2 which was recently released. I see that under certain >>> conditions rsyslogd spawns a lot of threads: >>> 5949 root 11216 S rsyslogd >>> 5950 root 11216 S rsyslogd >>> 5951 root 11216 S rsyslogd >>> 5952 root 11216 S rsyslogd >>> 5953 root 11216 S rsyslogd >>> 5954 root 11216 S rsyslogd >>> 5985 root Z [rsyslogd] >>> 6445 root Z [rsyslogd] >>> >>> I had to kill the rsyslogd and restart it. The first invocation had a >>> pid of 219 before it had to be killed. The second invocation of pid >>> which you see above starts with 5949. The difference is the amount of >>> zombie threads that were invoked by rsyslogd before I had to kill the >>> first invocation of it. >> >> I have no explanation yet for the zombies. They should not happen and so >> far I have never seen them. We may need to go through a debug log (which >> will become very large) to find out what's going on. >> >>> The question is under what conditions does rsyslogd spawn a new >>> thread/process and why was it a zombie? >> >> Unfortunately, there is no quick answer. A quick one may be: when it >> needs them, based on queue watermark settings and based on you >> configuration. But to really understand it, you need to read this doc: >> >> http://www.rsyslog.com/doc-queues.html >> >> The doc also describes all the knobs that you can use to control thread >> creation. There are many ;) >> >>> I am running rsyslogd in an >>> embedded environment and not a regular laptop/desktop. >> >> Interesting use case... >> >>> In addition, I >>> am using busybox and I believe the syslog buffer size is set to >> >> what do yo mean by "syslog buffer size"? The length of a receive buffer? >> It is 2K, thus single messages up to 2K are supported. It can be changed >> by modifying the MAXLINE define. Note that stock syslogd (and RFC3164) >> support only up to 1K. >> >>> something very low or perhaps none at all. Would this be a factor? >>> Furthermore, I ran rsyslogd with -c3 and also without -c3 and both >>> cases happen. >> >> The compatibility modes do not affect queue operation. >> >>> Are these issues already known and fixed in a later version? Sorry, if >>> I am asking the same questions or have the same issues as previous >>> people but without the ability to search (or at least, I don't know >>> how to) the archive, I don't know if my problem/questions has already >>> been seen and/or resolved. >> >> If we need to find out about the zombies, we need to move on to the >> current devel version. So I would give that a try in any case. 3.16.2 >> will (most probably) be replaced by 3.18.0 (based on the current beta) >> next week. So I won't touch it any longer. >> >> Looking forward to your feedback, >> Rainer >> >>> >>> Thank you very much for your support. >>> >>> Scott >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >> > From niallel at gmail.com Thu Jul 3 23:59:53 2008 From: niallel at gmail.com (niall el-assaad) Date: Thu, 3 Jul 2008 22:59:53 +0100 Subject: [rsyslog] Problem matching localhost Message-ID: Hi, I'm running 2.0.0-11 (version included with redhat 5.2) I want to filter all the messages from external syslog devices to one file and all messages from the localhost to another file. However even with the -x option turned on when a local service (such as crond) sends a message to the log the hostname is set to the domain name of the server. So I can't use the following to match: :HOSTNAME, isequal, "localhost" /var/log/messages :HOSTNAME, !isequal, "localhost" /var/log/externalsyslog I could replace "localhost" with "dnsname" to get it to work, but I would like a generic method that will work on all the syslog servers I have. Is there some switch that will cause rsyslog to report the local services as sending from localhost or 127.0.0.1 rather than the hostname of the localhost. thanks, niall From rgerhards at hq.adiscon.com Fri Jul 4 08:12:39 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 4 Jul 2008 08:12:39 +0200 Subject: [rsyslog] Problem matching localhost In-Reply-To: References: Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30932A@grfint2.intern.adiscon.com> I replied to your forum post: http://kb.monitorware.com/post13018.html#p13018 I suggest we keep discussing it in the forum to reduce double work. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of niall el-assaad > Sent: Friday, July 04, 2008 12:00 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Problem matching localhost > > Hi, > > I'm running 2.0.0-11 (version included with redhat 5.2) > > I want to filter all the messages from external syslog devices to one > file > and all messages from the localhost to another file. > > However even with the -x option turned on when a local service (such as > crond) sends a message to the log the hostname is set to the domain > name of > the server. > > So I can't use the following to match: > :HOSTNAME, isequal, "localhost" /var/log/messages > :HOSTNAME, !isequal, "localhost" /var/log/externalsyslog > > I could replace "localhost" with "dnsname" to get it to work, but I > would > like a generic method that will work on all the syslog servers I have. > Is there some switch that will cause rsyslog to report the local > services as > sending from localhost or 127.0.0.1 rather than the hostname of the > localhost. > > thanks, > > niall > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog From rgerhards at hq.adiscon.com Fri Jul 4 10:31:08 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 4 Jul 2008 10:31:08 +0200 Subject: [rsyslog] rsyslog threads questions In-Reply-To: <17945960807021757g3a9f8c16le353e03f17b5f18c@mail.gmail.com> References: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com><17945960807021204n38c2e9bfka17e9341035295f3@mail.gmail.com><17945960807021749q29f89272w74b8c30d45fba97b@mail.gmail.com> <17945960807021757g3a9f8c16le353e03f17b5f18c@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309331@grfint2.intern.adiscon.com> Scott, I have rewritten the omusrmsg plugin. This is currently part of the development tree, but will become part of the (new) beta when we do a version number shift next week. I'd appreciate if you could give it a try. It is available here: http://download.rsyslog.com/download/rsyslog-3.19.9-pre1.tar.gz I am hesitant to put this in the upcoming new v3-stable. There were lots of changes and one rule for a stable is that there should be no non-fix type of changes for at least 4 weeks before it turns into a stable. It of course is debatable if the change I made is a fix or not. In some sense it is, but on the other hand it is a rewrite that changed a lot. So given the fact that nobody on a "regular" machine saw an issue the past year, I would not like to bring the new code directly into the stable. If that causes problems for you, you may want to try simply using the omusrmsg.c code together with the v3-stable. I haven't tried it, but it should work well. All changes were just to that file, and there are no dependencies to anything external. OK... but now let's see first if it fixes the issue ;) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Scott Phuong > Sent: Thursday, July 03, 2008 2:58 AM > To: rsyslog at lists.adiscon.com > Subject: Re: [rsyslog] rsyslog threads questions > > Hi, > > I've attached four files. Two of which are debug dumps, one is the > conf file and the last one is a test case scenario that constantly > fails on my end. I hope this gives a little more information. > Furthermore, the dumps are from 3.17.5 which is the "closest" version > to 3.18.0 that I was able to find. > > Both failed scenarios occur when lots of messages were being flooded > to rsyslogd at a very fast rate (look at logtest.c) The > my_arm_rsyslog_suicide_debug.txt received a sigsegv fault while > my_arm_rsyslog_sh_cannot_fork caused so many "Z [rsyslogd]" threads > that it took up so much memory that executing any command as simple as > 'ls -l' would not work from the command line. I think the number of > threads grew as much as the number of messages. In the latter > scenario, after killing logtest.c, it didn't look like the those > zombies threads went away until I did a CTRL+C to the rsyslogd which > was running in the foreground since I use the "-dn" option. > > This is on an embedded system that runs significantly slower than a > desktop or laptop so maybe it would be harder to reproduce on a > regular computer. I looked at all the parameters that I believe could > affect this and believe for the most part the defaults are more than > adequate. The main message queue never looked like it hit the high > water mark but it did hit the lower one. So, I don't think messages > were being dropped (not sure) or an overflow condition occurred. > > The processor is ARM-based and it is using Linux kernel 2.6.16.12 and > compiled using GCC and the standard GNU C libraries version 3.4.5. > Rsyslog source code is cross-compiled using the following configure > line: > > ./configure --disable-zlib --disable-largefile > --enable-share=yes > --prefix=/ > --host=arm-unknown-linux-gnu > ac_cv_func_malloc_0_nonnull=yes > ac_cv_func_realloc_0_nonnull=yes > > ac_cv_func_lstat_dereferences_slashed_symlink=yes > ac_cv_func_stat_empty_string_bug=no > enable_debug=no > enable_rtinst=no > > Lastly, the logtest was executed with just the "-s" parameter. It is a > simple C file that I came up with. > > I took a look at the debug messages and it does not appear that new > threads are created via calls to wtpStartWrkr in wtp.c. > > Any help I can bring to solve this issue, please let me know. I hope I > am not doing anything wrong here. > > Thanks, > > Scott > > > > On Wed, Jul 2, 2008 at 12:04 PM, Scott Phuong > wrote: > >> Hi Rainer, > >> > >> Thanks for your reply. Looking at the default settings (from the > >> online help's configuration page), they are what I wanted. The main > >> messages queue is set to fix sized array with 1 worker thread > created > >> at maximum and action queues are direct mode which according to the > >> queue document page, means that there will not be a worker thread > >> created. Is my understanding correct? If yes, how do I quickly > check > >> without using the -d option if the defaults are set correctly? Or > what > >> do I look for in the debug messages that gets printed out to ensure > >> this? > >> > >> You also mentioned that version 3.18.0 is probably going to be > >> released as the stable version next week. I see on the webpage there > >> is a 3.17.4 and 3.17.5. Are these two versions similiar to 3.18.0? > >> > >> Also, how come I did not get your reply in my email inbox? My > account > >> settings look correct. > >> > >> Thanks, > >> > >> Scott Phuong > >> > >> As for the syslog buffer size, that applies to syslogd and does not > >> apply to rsyslog. > >> > >> > >> > >> My configuration files do not change the Action queue or Worker > queue > >> parameters at all. Looking at > >> On Wed, 2008-07-02 at 01:15 -0700, Scott Phuong wrote: > >>> Hi, > >>> > >>> I have 3.16.2 which was recently released. I see that under certain > >>> conditions rsyslogd spawns a lot of threads: > >>> 5949 root 11216 S rsyslogd > >>> 5950 root 11216 S rsyslogd > >>> 5951 root 11216 S rsyslogd > >>> 5952 root 11216 S rsyslogd > >>> 5953 root 11216 S rsyslogd > >>> 5954 root 11216 S rsyslogd > >>> 5985 root Z [rsyslogd] > >>> 6445 root Z [rsyslogd] > >>> > >>> I had to kill the rsyslogd and restart it. The first invocation had > a > >>> pid of 219 before it had to be killed. The second invocation of pid > >>> which you see above starts with 5949. The difference is the amount > of > >>> zombie threads that were invoked by rsyslogd before I had to kill > the > >>> first invocation of it. > >> > >> I have no explanation yet for the zombies. They should not happen > and so > >> far I have never seen them. We may need to go through a debug log > (which > >> will become very large) to find out what's going on. > >> > >>> The question is under what conditions does rsyslogd spawn a new > >>> thread/process and why was it a zombie? > >> > >> Unfortunately, there is no quick answer. A quick one may be: when it > >> needs them, based on queue watermark settings and based on you > >> configuration. But to really understand it, you need to read this > doc: > >> > >> http://www.rsyslog.com/doc-queues.html > >> > >> The doc also describes all the knobs that you can use to control > thread > >> creation. There are many ;) > >> > >>> I am running rsyslogd in an > >>> embedded environment and not a regular laptop/desktop. > >> > >> Interesting use case... > >> > >>> In addition, I > >>> am using busybox and I believe the syslog buffer size is set to > >> > >> what do yo mean by "syslog buffer size"? The length of a receive > buffer? > >> It is 2K, thus single messages up to 2K are supported. It can be > changed > >> by modifying the MAXLINE define. Note that stock syslogd (and > RFC3164) > >> support only up to 1K. > >> > >>> something very low or perhaps none at all. Would this be a factor? > >>> Furthermore, I ran rsyslogd with -c3 and also without -c3 and both > >>> cases happen. > >> > >> The compatibility modes do not affect queue operation. > >> > >>> Are these issues already known and fixed in a later version? Sorry, > if > >>> I am asking the same questions or have the same issues as previous > >>> people but without the ability to search (or at least, I don't know > >>> how to) the archive, I don't know if my problem/questions has > already > >>> been seen and/or resolved. > >> > >> If we need to find out about the zombies, we need to move on to the > >> current devel version. So I would give that a try in any case. > 3.16.2 > >> will (most probably) be replaced by 3.18.0 (based on the current > beta) > >> next week. So I won't touch it any longer. > >> > >> Looking forward to your feedback, > >> Rainer > >> > >>> > >>> Thank you very much for your support. > >>> > >>> Scott > >>> _______________________________________________ > >>> rsyslog mailing list > >>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> > > From rgerhards at hq.adiscon.com Fri Jul 4 11:24:29 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 4 Jul 2008 11:24:29 +0200 Subject: [rsyslog] struct alignment problem - who can help? ;) Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309336@grfint2.intern.adiscon.com> Hi list, I am posting a question here in the hope that some of the subscribers may be able to lend me a helping hand. Recently, I have begun to add a testbench to rsyslog. The idea is that over time the project should have canned tests which are easy to run on each version (as part of make distcheck at latest), increasing the overall code quality. "All" (so far two ;)) tests are located in the tests subdirectory. One test fails if compiled in release mode, that is rscript-parse.c. I have tracked down the failure cause and it is different struct member alignment in the ctok_token_t structure. The alignment is different in the rsyslog runtime and this test tool (I have compared the offsets computed for pToken->tok and they are different). So far, so good. But I do not find the cause of this misalignment. I checked the make output, and as it looks both the runtime as well as the tool are compiled with the same compiler options. Also, in debug mode it works OK, but in release mode (--disable-debug) it fails. I am sure the problem is something quite simple, but I have run out of ideas of what it may be (or, more probable, I simply overlook something). Any help would be deeply appreciated. Thanks, Rainer From mycleanjunk at gmail.com Fri Jul 4 12:28:58 2008 From: mycleanjunk at gmail.com (Scott Phuong) Date: Fri, 4 Jul 2008 03:28:58 -0700 Subject: [rsyslog] struct alignment problem - who can help? ;) In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309336@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA309336@grfint2.intern.adiscon.com> Message-ID: <17945960807040328o4841e26dv37828465534ab49d@mail.gmail.com> Here is my analysis: In ctok_teken_t, there is a BEGINobjInstance. BEGINobjInstance is a #define and is defined to obj_t objData which is the same for both NDEBUG defined and not defined. But obj_t is a typedef of struct obj_s. In the structure definition for obj_s in obj-types.h are the following lines: #ifndef NDEBUG unsigned int iObjCooCKiE; #endif NDEBUG is defined in config.h which was included in the runtime for rsyslog but not for test-parse.c I didn't compile the code to test my theory. I just did a quick check. Hope that solved your problem. Scott I think this may be why the you are getting this structure misalignment? On Fri, Jul 4, 2008 at 2:24 AM, Rainer Gerhards wrote: > Hi list, > > I am posting a question here in the hope that some of the subscribers > may be able to lend me a helping hand. > > Recently, I have begun to add a testbench to rsyslog. The idea is that > over time the project should have canned tests which are easy to run on > each version (as part of make distcheck at latest), increasing the > overall code quality. > > "All" (so far two ;)) tests are located in the tests subdirectory. One > test fails if compiled in release mode, that is rscript-parse.c. I have > tracked down the failure cause and it is different struct member > alignment in the ctok_token_t structure. The alignment is different in > the rsyslog runtime and this test tool (I have compared the offsets > computed for pToken->tok and they are different). So far, so good. But I > do not find the cause of this misalignment. I checked the make output, > and as it looks both the runtime as well as the tool are compiled with > the same compiler options. Also, in debug mode it works OK, but in > release mode (--disable-debug) it fails. > > I am sure the problem is something quite simple, but I have run out of > ideas of what it may be (or, more probable, I simply overlook > something). > > Any help would be deeply appreciated. > > Thanks, > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > From mycleanjunk at gmail.com Fri Jul 4 12:31:45 2008 From: mycleanjunk at gmail.com (Scott Phuong) Date: Fri, 4 Jul 2008 03:31:45 -0700 Subject: [rsyslog] rsyslog threads questions In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309331@grfint2.intern.adiscon.com> References: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com> <17945960807021204n38c2e9bfka17e9341035295f3@mail.gmail.com> <17945960807021749q29f89272w74b8c30d45fba97b@mail.gmail.com> <17945960807021757g3a9f8c16le353e03f17b5f18c@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA309331@grfint2.intern.adiscon.com> Message-ID: <17945960807040331u3c0a3deen3cb9d49bb035e665@mail.gmail.com> Hi Rainer, Thanks!! I'll give this a try next week and let you know the results. If it works, I think it is okay not to include in the upcoming v3 stable since it is due to release very soon. But if it does work, it would be great to have it in the following stable release. Scott On Fri, Jul 4, 2008 at 1:31 AM, Rainer Gerhards wrote: > Scott, > > I have rewritten the omusrmsg plugin. This is currently part of the > development tree, but will become part of the (new) beta when we do a > version number shift next week. I'd appreciate if you could give it a > try. It is available here: > > http://download.rsyslog.com/download/rsyslog-3.19.9-pre1.tar.gz > > I am hesitant to put this in the upcoming new v3-stable. There were lots > of changes and one rule for a stable is that there should be no non-fix > type of changes for at least 4 weeks before it turns into a stable. It > of course is debatable if the change I made is a fix or not. In some > sense it is, but on the other hand it is a rewrite that changed a lot. > So given the fact that nobody on a "regular" machine saw an issue the > past year, I would not like to bring the new code directly into the > stable. If that causes problems for you, you may want to try simply > using the omusrmsg.c code together with the v3-stable. I haven't tried > it, but it should work well. All changes were just to that file, and > there are no dependencies to anything external. > > OK... but now let's see first if it fixes the issue ;) > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Scott Phuong >> Sent: Thursday, July 03, 2008 2:58 AM >> To: rsyslog at lists.adiscon.com >> Subject: Re: [rsyslog] rsyslog threads questions >> >> Hi, >> >> I've attached four files. Two of which are debug dumps, one is the >> conf file and the last one is a test case scenario that constantly >> fails on my end. I hope this gives a little more information. >> Furthermore, the dumps are from 3.17.5 which is the "closest" version >> to 3.18.0 that I was able to find. >> >> Both failed scenarios occur when lots of messages were being flooded >> to rsyslogd at a very fast rate (look at logtest.c) The >> my_arm_rsyslog_suicide_debug.txt received a sigsegv fault while >> my_arm_rsyslog_sh_cannot_fork caused so many "Z [rsyslogd]" threads >> that it took up so much memory that executing any command as simple as >> 'ls -l' would not work from the command line. I think the number of >> threads grew as much as the number of messages. In the latter >> scenario, after killing logtest.c, it didn't look like the those >> zombies threads went away until I did a CTRL+C to the rsyslogd which >> was running in the foreground since I use the "-dn" option. >> >> This is on an embedded system that runs significantly slower than a >> desktop or laptop so maybe it would be harder to reproduce on a >> regular computer. I looked at all the parameters that I believe could >> affect this and believe for the most part the defaults are more than >> adequate. The main message queue never looked like it hit the high >> water mark but it did hit the lower one. So, I don't think messages >> were being dropped (not sure) or an overflow condition occurred. >> >> The processor is ARM-based and it is using Linux kernel 2.6.16.12 and >> compiled using GCC and the standard GNU C libraries version 3.4.5. >> Rsyslog source code is cross-compiled using the following configure >> line: >> >> ./configure --disable-zlib --disable-largefile >> --enable-share=yes >> --prefix=/ >> --host=arm-unknown-linux-gnu >> ac_cv_func_malloc_0_nonnull=yes >> ac_cv_func_realloc_0_nonnull=yes >> >> ac_cv_func_lstat_dereferences_slashed_symlink=yes >> ac_cv_func_stat_empty_string_bug=no >> enable_debug=no >> enable_rtinst=no >> >> Lastly, the logtest was executed with just the "-s" parameter. It is a >> simple C file that I came up with. >> >> I took a look at the debug messages and it does not appear that new >> threads are created via calls to wtpStartWrkr in wtp.c. >> >> Any help I can bring to solve this issue, please let me know. I hope I >> am not doing anything wrong here. >> >> Thanks, >> >> Scott >> > >> > On Wed, Jul 2, 2008 at 12:04 PM, Scott Phuong > >> wrote: >> >> Hi Rainer, >> >> >> >> Thanks for your reply. Looking at the default settings (from the >> >> online help's configuration page), they are what I wanted. The main >> >> messages queue is set to fix sized array with 1 worker thread >> created >> >> at maximum and action queues are direct mode which according to the >> >> queue document page, means that there will not be a worker thread >> >> created. Is my understanding correct? If yes, how do I quickly >> check >> >> without using the -d option if the defaults are set correctly? Or >> what >> >> do I look for in the debug messages that gets printed out to ensure >> >> this? >> >> >> >> You also mentioned that version 3.18.0 is probably going to be >> >> released as the stable version next week. I see on the webpage > there >> >> is a 3.17.4 and 3.17.5. Are these two versions similiar to 3.18.0? >> >> >> >> Also, how come I did not get your reply in my email inbox? My >> account >> >> settings look correct. >> >> >> >> Thanks, >> >> >> >> Scott Phuong >> >> >> >> As for the syslog buffer size, that applies to syslogd and does not >> >> apply to rsyslog. >> >> >> >> >> >> >> >> My configuration files do not change the Action queue or Worker >> queue >> >> parameters at all. Looking at >> >> On Wed, 2008-07-02 at 01:15 -0700, Scott Phuong wrote: >> >>> Hi, >> >>> >> >>> I have 3.16.2 which was recently released. I see that under > certain >> >>> conditions rsyslogd spawns a lot of threads: >> >>> 5949 root 11216 S rsyslogd >> >>> 5950 root 11216 S rsyslogd >> >>> 5951 root 11216 S rsyslogd >> >>> 5952 root 11216 S rsyslogd >> >>> 5953 root 11216 S rsyslogd >> >>> 5954 root 11216 S rsyslogd >> >>> 5985 root Z [rsyslogd] >> >>> 6445 root Z [rsyslogd] >> >>> >> >>> I had to kill the rsyslogd and restart it. The first invocation > had >> a >> >>> pid of 219 before it had to be killed. The second invocation of > pid >> >>> which you see above starts with 5949. The difference is the amount >> of >> >>> zombie threads that were invoked by rsyslogd before I had to kill >> the >> >>> first invocation of it. >> >> >> >> I have no explanation yet for the zombies. They should not happen >> and so >> >> far I have never seen them. We may need to go through a debug log >> (which >> >> will become very large) to find out what's going on. >> >> >> >>> The question is under what conditions does rsyslogd spawn a new >> >>> thread/process and why was it a zombie? >> >> >> >> Unfortunately, there is no quick answer. A quick one may be: when > it >> >> needs them, based on queue watermark settings and based on you >> >> configuration. But to really understand it, you need to read this >> doc: >> >> >> >> http://www.rsyslog.com/doc-queues.html >> >> >> >> The doc also describes all the knobs that you can use to control >> thread >> >> creation. There are many ;) >> >> >> >>> I am running rsyslogd in an >> >>> embedded environment and not a regular laptop/desktop. >> >> >> >> Interesting use case... >> >> >> >>> In addition, I >> >>> am using busybox and I believe the syslog buffer size is set to >> >> >> >> what do yo mean by "syslog buffer size"? The length of a receive >> buffer? >> >> It is 2K, thus single messages up to 2K are supported. It can be >> changed >> >> by modifying the MAXLINE define. Note that stock syslogd (and >> RFC3164) >> >> support only up to 1K. >> >> >> >>> something very low or perhaps none at all. Would this be a factor? >> >>> Furthermore, I ran rsyslogd with -c3 and also without -c3 and both >> >>> cases happen. >> >> >> >> The compatibility modes do not affect queue operation. >> >> >> >>> Are these issues already known and fixed in a later version? > Sorry, >> if >> >>> I am asking the same questions or have the same issues as previous >> >>> people but without the ability to search (or at least, I don't > know >> >>> how to) the archive, I don't know if my problem/questions has >> already >> >>> been seen and/or resolved. >> >> >> >> If we need to find out about the zombies, we need to move on to the >> >> current devel version. So I would give that a try in any case. >> 3.16.2 >> >> will (most probably) be replaced by 3.18.0 (based on the current >> beta) >> >> next week. So I won't touch it any longer. >> >> >> >> Looking forward to your feedback, >> >> Rainer >> >> >> >>> >> >>> Thank you very much for your support. >> >>> >> >>> Scott >> >>> _______________________________________________ >> >>> 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 Fri Jul 4 12:32:03 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 4 Jul 2008 12:32:03 +0200 Subject: [rsyslog] struct alignment problem - who can help? ;) In-Reply-To: <17945960807040328o4841e26dv37828465534ab49d@mail.gmail.com> References: <577465F99B41C842AAFBE9ED71E70ABA309336@grfint2.intern.adiscon.com> <17945960807040328o4841e26dv37828465534ab49d@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30933B@grfint2.intern.adiscon.com> Hi Scott, thanks for the help, I'll further investigate. BUT: both the runtime AND the tool are compiled in non-debug mode. So in this case, neither of them should have the object cookie, thus the alignment should be the same. But, as I said, I am grateful for any clue and will check if there is some issue along these lines :) In any case, it seems to be inconsistent and should be fixed :) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Scott Phuong > Sent: Friday, July 04, 2008 12:29 PM > To: rsyslog-users > Subject: Re: [rsyslog] struct alignment problem - who can help? ;) > > Here is my analysis: > In ctok_teken_t, there is a BEGINobjInstance. BEGINobjInstance is a > #define and is defined to obj_t objData which is the same for both > NDEBUG defined and not defined. But obj_t is a typedef of struct > obj_s. In the structure definition for obj_s in obj-types.h are the > following lines: > #ifndef NDEBUG > unsigned int iObjCooCKiE; > #endif > > NDEBUG is defined in config.h which was included in the runtime for > rsyslog but not for test-parse.c > > I didn't compile the code to test my theory. I just did a quick check. > > Hope that solved your problem. > > Scott > > > I think this may be why the you are getting this structure > misalignment? > > > On Fri, Jul 4, 2008 at 2:24 AM, Rainer Gerhards > wrote: > > Hi list, > > > > I am posting a question here in the hope that some of the subscribers > > may be able to lend me a helping hand. > > > > Recently, I have begun to add a testbench to rsyslog. The idea is > that > > over time the project should have canned tests which are easy to run > on > > each version (as part of make distcheck at latest), increasing the > > overall code quality. > > > > "All" (so far two ;)) tests are located in the tests subdirectory. > One > > test fails if compiled in release mode, that is rscript-parse.c. I > have > > tracked down the failure cause and it is different struct member > > alignment in the ctok_token_t structure. The alignment is different > in > > the rsyslog runtime and this test tool (I have compared the offsets > > computed for pToken->tok and they are different). So far, so good. > But I > > do not find the cause of this misalignment. I checked the make > output, > > and as it looks both the runtime as well as the tool are compiled > with > > the same compiler options. Also, in debug mode it works OK, but in > > release mode (--disable-debug) it fails. > > > > I am sure the problem is something quite simple, but I have run out > of > > ideas of what it may be (or, more probable, I simply overlook > > something). > > > > Any help would be deeply appreciated. > > > > Thanks, > > Rainer > > _______________________________________________ > > 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 Fri Jul 4 12:35:23 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 4 Jul 2008 12:35:23 +0200 Subject: [rsyslog] rsyslog threads questions In-Reply-To: <17945960807040331u3c0a3deen3cb9d49bb035e665@mail.gmail.com> References: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com><17945960807021204n38c2e9bfka17e9341035295f3@mail.gmail.com><17945960807021749q29f89272w74b8c30d45fba97b@mail.gmail.com><17945960807021757g3a9f8c16le353e03f17b5f18c@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA309331@grfint2.intern.adiscon.com> <17945960807040331u3c0a3deen3cb9d49bb035e665@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30933C@grfint2.intern.adiscon.com> Hi Scott, just for your understanding: once a release is stable, it will only receive fixes. So the fix we are looking it needs to become part of the devel, be migrated to beta and then be migrated to stable. In general, one migration step takes between 4 and 12 weeks, depending on what was done. So far, the average seems on the average, that is two month. So two cycles mean roughly four month. HOWEVER, I intend to put it into the next beta, which will bring us to just one cycle. So it would be available in roughly two month. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Scott Phuong > Sent: Friday, July 04, 2008 12:32 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslog threads questions > > Hi Rainer, > > Thanks!! I'll give this a try next week and let you know the results. > If it works, I think it is okay not to include in the upcoming v3 > stable since it is due to release very soon. But if it does work, it > would be great to have it in the following stable release. > > Scott > > On Fri, Jul 4, 2008 at 1:31 AM, Rainer Gerhards > wrote: > > Scott, > > > > I have rewritten the omusrmsg plugin. This is currently part of the > > development tree, but will become part of the (new) beta when we do a > > version number shift next week. I'd appreciate if you could give it a > > try. It is available here: > > > > http://download.rsyslog.com/download/rsyslog-3.19.9-pre1.tar.gz > > > > I am hesitant to put this in the upcoming new v3-stable. There were > lots > > of changes and one rule for a stable is that there should be no non- > fix > > type of changes for at least 4 weeks before it turns into a stable. > It > > of course is debatable if the change I made is a fix or not. In some > > sense it is, but on the other hand it is a rewrite that changed a > lot. > > So given the fact that nobody on a "regular" machine saw an issue the > > past year, I would not like to bring the new code directly into the > > stable. If that causes problems for you, you may want to try simply > > using the omusrmsg.c code together with the v3-stable. I haven't > tried > > it, but it should work well. All changes were just to that file, and > > there are no dependencies to anything external. > > > > OK... but now let's see first if it fixes the issue ;) > > > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of Scott Phuong > >> Sent: Thursday, July 03, 2008 2:58 AM > >> To: rsyslog at lists.adiscon.com > >> Subject: Re: [rsyslog] rsyslog threads questions > >> > >> Hi, > >> > >> I've attached four files. Two of which are debug dumps, one is the > >> conf file and the last one is a test case scenario that constantly > >> fails on my end. I hope this gives a little more information. > >> Furthermore, the dumps are from 3.17.5 which is the "closest" > version > >> to 3.18.0 that I was able to find. > >> > >> Both failed scenarios occur when lots of messages were being flooded > >> to rsyslogd at a very fast rate (look at logtest.c) The > >> my_arm_rsyslog_suicide_debug.txt received a sigsegv fault while > >> my_arm_rsyslog_sh_cannot_fork caused so many "Z [rsyslogd]" > threads > >> that it took up so much memory that executing any command as simple > as > >> 'ls -l' would not work from the command line. I think the number of > >> threads grew as much as the number of messages. In the latter > >> scenario, after killing logtest.c, it didn't look like the those > >> zombies threads went away until I did a CTRL+C to the rsyslogd which > >> was running in the foreground since I use the "-dn" option. > >> > >> This is on an embedded system that runs significantly slower than a > >> desktop or laptop so maybe it would be harder to reproduce on a > >> regular computer. I looked at all the parameters that I believe > could > >> affect this and believe for the most part the defaults are more than > >> adequate. The main message queue never looked like it hit the high > >> water mark but it did hit the lower one. So, I don't think messages > >> were being dropped (not sure) or an overflow condition occurred. > >> > >> The processor is ARM-based and it is using Linux kernel 2.6.16.12 > and > >> compiled using GCC and the standard GNU C libraries version 3.4.5. > >> Rsyslog source code is cross-compiled using the following configure > >> line: > >> > >> ./configure --disable-zlib --disable-largefile > >> --enable-share=yes > >> --prefix=/ > >> --host=arm-unknown-linux-gnu > >> ac_cv_func_malloc_0_nonnull=yes > >> ac_cv_func_realloc_0_nonnull=yes > >> > >> ac_cv_func_lstat_dereferences_slashed_symlink=yes > >> ac_cv_func_stat_empty_string_bug=no > >> enable_debug=no > >> enable_rtinst=no > >> > >> Lastly, the logtest was executed with just the "-s" parameter. It is > a > >> simple C file that I came up with. > >> > >> I took a look at the debug messages and it does not appear that new > >> threads are created via calls to wtpStartWrkr in wtp.c. > >> > >> Any help I can bring to solve this issue, please let me know. I hope > I > >> am not doing anything wrong here. > >> > >> Thanks, > >> > >> Scott > >> > > >> > On Wed, Jul 2, 2008 at 12:04 PM, Scott Phuong > > > >> wrote: > >> >> Hi Rainer, > >> >> > >> >> Thanks for your reply. Looking at the default settings (from the > >> >> online help's configuration page), they are what I wanted. The > main > >> >> messages queue is set to fix sized array with 1 worker thread > >> created > >> >> at maximum and action queues are direct mode which according to > the > >> >> queue document page, means that there will not be a worker thread > >> >> created. Is my understanding correct? If yes, how do I quickly > >> check > >> >> without using the -d option if the defaults are set correctly? Or > >> what > >> >> do I look for in the debug messages that gets printed out to > ensure > >> >> this? > >> >> > >> >> You also mentioned that version 3.18.0 is probably going to be > >> >> released as the stable version next week. I see on the webpage > > there > >> >> is a 3.17.4 and 3.17.5. Are these two versions similiar to > 3.18.0? > >> >> > >> >> Also, how come I did not get your reply in my email inbox? My > >> account > >> >> settings look correct. > >> >> > >> >> Thanks, > >> >> > >> >> Scott Phuong > >> >> > >> >> As for the syslog buffer size, that applies to syslogd and does > not > >> >> apply to rsyslog. > >> >> > >> >> > >> >> > >> >> My configuration files do not change the Action queue or Worker > >> queue > >> >> parameters at all. Looking at > >> >> On Wed, 2008-07-02 at 01:15 -0700, Scott Phuong wrote: > >> >>> Hi, > >> >>> > >> >>> I have 3.16.2 which was recently released. I see that under > > certain > >> >>> conditions rsyslogd spawns a lot of threads: > >> >>> 5949 root 11216 S rsyslogd > >> >>> 5950 root 11216 S rsyslogd > >> >>> 5951 root 11216 S rsyslogd > >> >>> 5952 root 11216 S rsyslogd > >> >>> 5953 root 11216 S rsyslogd > >> >>> 5954 root 11216 S rsyslogd > >> >>> 5985 root Z [rsyslogd] > >> >>> 6445 root Z [rsyslogd] > >> >>> > >> >>> I had to kill the rsyslogd and restart it. The first invocation > > had > >> a > >> >>> pid of 219 before it had to be killed. The second invocation of > > pid > >> >>> which you see above starts with 5949. The difference is the > amount > >> of > >> >>> zombie threads that were invoked by rsyslogd before I had to > kill > >> the > >> >>> first invocation of it. > >> >> > >> >> I have no explanation yet for the zombies. They should not happen > >> and so > >> >> far I have never seen them. We may need to go through a debug log > >> (which > >> >> will become very large) to find out what's going on. > >> >> > >> >>> The question is under what conditions does rsyslogd spawn a new > >> >>> thread/process and why was it a zombie? > >> >> > >> >> Unfortunately, there is no quick answer. A quick one may be: when > > it > >> >> needs them, based on queue watermark settings and based on you > >> >> configuration. But to really understand it, you need to read this > >> doc: > >> >> > >> >> http://www.rsyslog.com/doc-queues.html > >> >> > >> >> The doc also describes all the knobs that you can use to control > >> thread > >> >> creation. There are many ;) > >> >> > >> >>> I am running rsyslogd in an > >> >>> embedded environment and not a regular laptop/desktop. > >> >> > >> >> Interesting use case... > >> >> > >> >>> In addition, I > >> >>> am using busybox and I believe the syslog buffer size is set to > >> >> > >> >> what do yo mean by "syslog buffer size"? The length of a receive > >> buffer? > >> >> It is 2K, thus single messages up to 2K are supported. It can be > >> changed > >> >> by modifying the MAXLINE define. Note that stock syslogd (and > >> RFC3164) > >> >> support only up to 1K. > >> >> > >> >>> something very low or perhaps none at all. Would this be a > factor? > >> >>> Furthermore, I ran rsyslogd with -c3 and also without -c3 and > both > >> >>> cases happen. > >> >> > >> >> The compatibility modes do not affect queue operation. > >> >> > >> >>> Are these issues already known and fixed in a later version? > > Sorry, > >> if > >> >>> I am asking the same questions or have the same issues as > previous > >> >>> people but without the ability to search (or at least, I don't > > know > >> >>> how to) the archive, I don't know if my problem/questions has > >> already > >> >>> been seen and/or resolved. > >> >> > >> >> If we need to find out about the zombies, we need to move on to > the > >> >> current devel version. So I would give that a try in any case. > >> 3.16.2 > >> >> will (most probably) be replaced by 3.18.0 (based on the current > >> beta) > >> >> next week. So I won't touch it any longer. > >> >> > >> >> Looking forward to your feedback, > >> >> Rainer > >> >> > >> >>> > >> >>> Thank you very much for your support. > >> >>> > >> >>> Scott > >> >>> _______________________________________________ > >> >>> 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 mycleanjunk at gmail.com Fri Jul 4 12:38:12 2008 From: mycleanjunk at gmail.com (Scott Phuong) Date: Fri, 4 Jul 2008 03:38:12 -0700 Subject: [rsyslog] struct alignment problem - who can help? ;) In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA30933B@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA309336@grfint2.intern.adiscon.com> <17945960807040328o4841e26dv37828465534ab49d@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA30933B@grfint2.intern.adiscon.com> Message-ID: <17945960807040338u1ebc94cfh1a5754696cc2a2a@mail.gmail.com> Hi Rainer, But in release mode, NDEBUG is intentionally defined in the config.h. This is what I recalled from looking at 3.16.1 and 3.17.5. So from the perspective of rsyslog, NDEBUG is defined and the opposite for the test-parse.c (because config.h is not included). Scott On Fri, Jul 4, 2008 at 3:32 AM, Rainer Gerhards wrote: > Hi Scott, > > thanks for the help, I'll further investigate. BUT: both the runtime AND > the tool are compiled in non-debug mode. So in this case, neither of > them should have the object cookie, thus the alignment should be the > same. But, as I said, I am grateful for any clue and will check if there > is some issue along these lines :) In any case, it seems to be > inconsistent and should be fixed :) > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Scott Phuong >> Sent: Friday, July 04, 2008 12:29 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] struct alignment problem - who can help? ;) >> >> Here is my analysis: >> In ctok_teken_t, there is a BEGINobjInstance. BEGINobjInstance is a >> #define and is defined to obj_t objData which is the same for both >> NDEBUG defined and not defined. But obj_t is a typedef of struct >> obj_s. In the structure definition for obj_s in obj-types.h are the >> following lines: >> #ifndef NDEBUG >> unsigned int iObjCooCKiE; >> #endif >> >> NDEBUG is defined in config.h which was included in the runtime for >> rsyslog but not for test-parse.c >> >> I didn't compile the code to test my theory. I just did a quick check. >> >> Hope that solved your problem. >> >> Scott >> >> >> I think this may be why the you are getting this structure >> misalignment? >> >> >> On Fri, Jul 4, 2008 at 2:24 AM, Rainer Gerhards >> wrote: >> > Hi list, >> > >> > I am posting a question here in the hope that some of the > subscribers >> > may be able to lend me a helping hand. >> > >> > Recently, I have begun to add a testbench to rsyslog. The idea is >> that >> > over time the project should have canned tests which are easy to run >> on >> > each version (as part of make distcheck at latest), increasing the >> > overall code quality. >> > >> > "All" (so far two ;)) tests are located in the tests subdirectory. >> One >> > test fails if compiled in release mode, that is rscript-parse.c. I >> have >> > tracked down the failure cause and it is different struct member >> > alignment in the ctok_token_t structure. The alignment is different >> in >> > the rsyslog runtime and this test tool (I have compared the offsets >> > computed for pToken->tok and they are different). So far, so good. >> But I >> > do not find the cause of this misalignment. I checked the make >> output, >> > and as it looks both the runtime as well as the tool are compiled >> with >> > the same compiler options. Also, in debug mode it works OK, but in >> > release mode (--disable-debug) it fails. >> > >> > I am sure the problem is something quite simple, but I have run out >> of >> > ideas of what it may be (or, more probable, I simply overlook >> > something). >> > >> > Any help would be deeply appreciated. >> > >> > Thanks, >> > 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 mycleanjunk at gmail.com Fri Jul 4 12:39:32 2008 From: mycleanjunk at gmail.com (Scott Phuong) Date: Fri, 4 Jul 2008 03:39:32 -0700 Subject: [rsyslog] rsyslog threads questions In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA30933C@grfint2.intern.adiscon.com> References: <17945960807020115y7ba1d72bp485080214ced80c2@mail.gmail.com> <17945960807021204n38c2e9bfka17e9341035295f3@mail.gmail.com> <17945960807021749q29f89272w74b8c30d45fba97b@mail.gmail.com> <17945960807021757g3a9f8c16le353e03f17b5f18c@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA309331@grfint2.intern.adiscon.com> <17945960807040331u3c0a3deen3cb9d49bb035e665@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA30933C@grfint2.intern.adiscon.com> Message-ID: <17945960807040339y44e5f75cgde6b4593e5c99584@mail.gmail.com> Hi Rainer, Thanks for the information. I didn't know that. Scott On Fri, Jul 4, 2008 at 3:35 AM, Rainer Gerhards wrote: > Hi Scott, > > just for your understanding: once a release is stable, it will only > receive fixes. So the fix we are looking it needs to become part of the > devel, be migrated to beta and then be migrated to stable. In general, > one migration step takes between 4 and 12 weeks, depending on what was > done. So far, the average seems on the average, that is two month. So > two cycles mean roughly four month. HOWEVER, I intend to put it into the > next beta, which will bring us to just one cycle. So it would be > available in roughly two month. > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Scott Phuong >> Sent: Friday, July 04, 2008 12:32 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] rsyslog threads questions >> >> Hi Rainer, >> >> Thanks!! I'll give this a try next week and let you know the results. >> If it works, I think it is okay not to include in the upcoming v3 >> stable since it is due to release very soon. But if it does work, it >> would be great to have it in the following stable release. >> >> Scott >> >> On Fri, Jul 4, 2008 at 1:31 AM, Rainer Gerhards >> wrote: >> > Scott, >> > >> > I have rewritten the omusrmsg plugin. This is currently part of the >> > development tree, but will become part of the (new) beta when we do > a >> > version number shift next week. I'd appreciate if you could give it > a >> > try. It is available here: >> > >> > http://download.rsyslog.com/download/rsyslog-3.19.9-pre1.tar.gz >> > >> > I am hesitant to put this in the upcoming new v3-stable. There were >> lots >> > of changes and one rule for a stable is that there should be no non- >> fix >> > type of changes for at least 4 weeks before it turns into a stable. >> It >> > of course is debatable if the change I made is a fix or not. In some >> > sense it is, but on the other hand it is a rewrite that changed a >> lot. >> > So given the fact that nobody on a "regular" machine saw an issue > the >> > past year, I would not like to bring the new code directly into the >> > stable. If that causes problems for you, you may want to try simply >> > using the omusrmsg.c code together with the v3-stable. I haven't >> tried >> > it, but it should work well. All changes were just to that file, and >> > there are no dependencies to anything external. >> > >> > OK... but now let's see first if it fixes the issue ;) >> > >> > Rainer >> > >> >> -----Original Message----- >> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> >> bounces at lists.adiscon.com] On Behalf Of Scott Phuong >> >> Sent: Thursday, July 03, 2008 2:58 AM >> >> To: rsyslog at lists.adiscon.com >> >> Subject: Re: [rsyslog] rsyslog threads questions >> >> >> >> Hi, >> >> >> >> I've attached four files. Two of which are debug dumps, one is the >> >> conf file and the last one is a test case scenario that constantly >> >> fails on my end. I hope this gives a little more information. >> >> Furthermore, the dumps are from 3.17.5 which is the "closest" >> version >> >> to 3.18.0 that I was able to find. >> >> >> >> Both failed scenarios occur when lots of messages were being > flooded >> >> to rsyslogd at a very fast rate (look at logtest.c) The >> >> my_arm_rsyslog_suicide_debug.txt received a sigsegv fault while >> >> my_arm_rsyslog_sh_cannot_fork caused so many "Z [rsyslogd]" >> threads >> >> that it took up so much memory that executing any command as simple >> as >> >> 'ls -l' would not work from the command line. I think the number of >> >> threads grew as much as the number of messages. In the latter >> >> scenario, after killing logtest.c, it didn't look like the those >> >> zombies threads went away until I did a CTRL+C to the rsyslogd > which >> >> was running in the foreground since I use the "-dn" option. >> >> >> >> This is on an embedded system that runs significantly slower than a >> >> desktop or laptop so maybe it would be harder to reproduce on a >> >> regular computer. I looked at all the parameters that I believe >> could >> >> affect this and believe for the most part the defaults are more > than >> >> adequate. The main message queue never looked like it hit the high >> >> water mark but it did hit the lower one. So, I don't think messages >> >> were being dropped (not sure) or an overflow condition occurred. >> >> >> >> The processor is ARM-based and it is using Linux kernel 2.6.16.12 >> and >> >> compiled using GCC and the standard GNU C libraries version 3.4.5. >> >> Rsyslog source code is cross-compiled using the following configure >> >> line: >> >> >> >> ./configure --disable-zlib --disable-largefile >> >> --enable-share=yes >> >> --prefix=/ >> >> --host=arm-unknown-linux-gnu >> >> ac_cv_func_malloc_0_nonnull=yes >> >> ac_cv_func_realloc_0_nonnull=yes >> >> >> >> ac_cv_func_lstat_dereferences_slashed_symlink=yes >> >> ac_cv_func_stat_empty_string_bug=no >> >> enable_debug=no >> >> enable_rtinst=no >> >> >> >> Lastly, the logtest was executed with just the "-s" parameter. It > is >> a >> >> simple C file that I came up with. >> >> >> >> I took a look at the debug messages and it does not appear that new >> >> threads are created via calls to wtpStartWrkr in wtp.c. >> >> >> >> Any help I can bring to solve this issue, please let me know. I > hope >> I >> >> am not doing anything wrong here. >> >> >> >> Thanks, >> >> >> >> Scott >> >> > >> >> > On Wed, Jul 2, 2008 at 12:04 PM, Scott Phuong >> > >> >> wrote: >> >> >> Hi Rainer, >> >> >> >> >> >> Thanks for your reply. Looking at the default settings (from > the >> >> >> online help's configuration page), they are what I wanted. The >> main >> >> >> messages queue is set to fix sized array with 1 worker thread >> >> created >> >> >> at maximum and action queues are direct mode which according to >> the >> >> >> queue document page, means that there will not be a worker > thread >> >> >> created. Is my understanding correct? If yes, how do I quickly >> >> check >> >> >> without using the -d option if the defaults are set correctly? > Or >> >> what >> >> >> do I look for in the debug messages that gets printed out to >> ensure >> >> >> this? >> >> >> >> >> >> You also mentioned that version 3.18.0 is probably going to be >> >> >> released as the stable version next week. I see on the webpage >> > there >> >> >> is a 3.17.4 and 3.17.5. Are these two versions similiar to >> 3.18.0? >> >> >> >> >> >> Also, how come I did not get your reply in my email inbox? My >> >> account >> >> >> settings look correct. >> >> >> >> >> >> Thanks, >> >> >> >> >> >> Scott Phuong >> >> >> >> >> >> As for the syslog buffer size, that applies to syslogd and does >> not >> >> >> apply to rsyslog. >> >> >> >> >> >> >> >> >> >> >> >> My configuration files do not change the Action queue or Worker >> >> queue >> >> >> parameters at all. Looking at >> >> >> On Wed, 2008-07-02 at 01:15 -0700, Scott Phuong wrote: >> >> >>> Hi, >> >> >>> >> >> >>> I have 3.16.2 which was recently released. I see that under >> > certain >> >> >>> conditions rsyslogd spawns a lot of threads: >> >> >>> 5949 root 11216 S rsyslogd >> >> >>> 5950 root 11216 S rsyslogd >> >> >>> 5951 root 11216 S rsyslogd >> >> >>> 5952 root 11216 S rsyslogd >> >> >>> 5953 root 11216 S rsyslogd >> >> >>> 5954 root 11216 S rsyslogd >> >> >>> 5985 root Z [rsyslogd] >> >> >>> 6445 root Z [rsyslogd] >> >> >>> >> >> >>> I had to kill the rsyslogd and restart it. The first invocation >> > had >> >> a >> >> >>> pid of 219 before it had to be killed. The second invocation of >> > pid >> >> >>> which you see above starts with 5949. The difference is the >> amount >> >> of >> >> >>> zombie threads that were invoked by rsyslogd before I had to >> kill >> >> the >> >> >>> first invocation of it. >> >> >> >> >> >> I have no explanation yet for the zombies. They should not > happen >> >> and so >> >> >> far I have never seen them. We may need to go through a debug > log >> >> (which >> >> >> will become very large) to find out what's going on. >> >> >> >> >> >>> The question is under what conditions does rsyslogd spawn a new >> >> >>> thread/process and why was it a zombie? >> >> >> >> >> >> Unfortunately, there is no quick answer. A quick one may be: > when >> > it >> >> >> needs them, based on queue watermark settings and based on you >> >> >> configuration. But to really understand it, you need to read > this >> >> doc: >> >> >> >> >> >> http://www.rsyslog.com/doc-queues.html >> >> >> >> >> >> The doc also describes all the knobs that you can use to control >> >> thread >> >> >> creation. There are many ;) >> >> >> >> >> >>> I am running rsyslogd in an >> >> >>> embedded environment and not a regular laptop/desktop. >> >> >> >> >> >> Interesting use case... >> >> >> >> >> >>> In addition, I >> >> >>> am using busybox and I believe the syslog buffer size is set to >> >> >> >> >> >> what do yo mean by "syslog buffer size"? The length of a receive >> >> buffer? >> >> >> It is 2K, thus single messages up to 2K are supported. It can be >> >> changed >> >> >> by modifying the MAXLINE define. Note that stock syslogd (and >> >> RFC3164) >> >> >> support only up to 1K. >> >> >> >> >> >>> something very low or perhaps none at all. Would this be a >> factor? >> >> >>> Furthermore, I ran rsyslogd with -c3 and also without -c3 and >> both >> >> >>> cases happen. >> >> >> >> >> >> The compatibility modes do not affect queue operation. >> >> >> >> >> >>> Are these issues already known and fixed in a later version? >> > Sorry, >> >> if >> >> >>> I am asking the same questions or have the same issues as >> previous >> >> >>> people but without the ability to search (or at least, I don't >> > know >> >> >>> how to) the archive, I don't know if my problem/questions has >> >> already >> >> >>> been seen and/or resolved. >> >> >> >> >> >> If we need to find out about the zombies, we need to move on to >> the >> >> >> current devel version. So I would give that a try in any case. >> >> 3.16.2 >> >> >> will (most probably) be replaced by 3.18.0 (based on the current >> >> beta) >> >> >> next week. So I won't touch it any longer. >> >> >> >> >> >> Looking forward to your feedback, >> >> >> Rainer >> >> >> >> >> >>> >> >> >>> Thank you very much for your support. >> >> >>> >> >> >>> Scott >> >> >>> _______________________________________________ >> >> >>> 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 Fri Jul 4 12:44:24 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 4 Jul 2008 12:44:24 +0200 Subject: [rsyslog] struct alignment problem - who can help? ;) In-Reply-To: <17945960807040338u1ebc94cfh1a5754696cc2a2a@mail.gmail.com> References: <577465F99B41C842AAFBE9ED71E70ABA309336@grfint2.intern.adiscon.com><17945960807040328o4841e26dv37828465534ab49d@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA30933B@grfint2.intern.adiscon.com> <17945960807040338u1ebc94cfh1a5754696cc2a2a@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30933D@grfint2.intern.adiscon.com> ROFL... you got it! I have forgotten to #include "config.h"! I knew that it must have been something simple. Thanks a lot, you saved me from pulling out the rest of my hair ;) Rainer PS: and, yes, it looks like I need to reevaluate mode-specific structure members now that we aim at a real runtime. Doesn't look so smart any longer... > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Scott Phuong > Sent: Friday, July 04, 2008 12:38 PM > To: rsyslog-users > Subject: Re: [rsyslog] struct alignment problem - who can help? ;) > > Hi Rainer, > > But in release mode, NDEBUG is intentionally defined in the config.h. > This is what I recalled from looking at 3.16.1 and 3.17.5. So from the > perspective of rsyslog, NDEBUG is defined and the opposite for the > test-parse.c (because config.h is not included). > > Scott > > On Fri, Jul 4, 2008 at 3:32 AM, Rainer Gerhards > wrote: > > Hi Scott, > > > > thanks for the help, I'll further investigate. BUT: both the runtime > AND > > the tool are compiled in non-debug mode. So in this case, neither of > > them should have the object cookie, thus the alignment should be the > > same. But, as I said, I am grateful for any clue and will check if > there > > is some issue along these lines :) In any case, it seems to be > > inconsistent and should be fixed :) > > > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of Scott Phuong > >> Sent: Friday, July 04, 2008 12:29 PM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] struct alignment problem - who can help? ;) > >> > >> Here is my analysis: > >> In ctok_teken_t, there is a BEGINobjInstance. BEGINobjInstance is a > >> #define and is defined to obj_t objData which is the same for both > >> NDEBUG defined and not defined. But obj_t is a typedef of struct > >> obj_s. In the structure definition for obj_s in obj-types.h are the > >> following lines: > >> #ifndef NDEBUG > >> unsigned int iObjCooCKiE; > >> #endif > >> > >> NDEBUG is defined in config.h which was included in the runtime for > >> rsyslog but not for test-parse.c > >> > >> I didn't compile the code to test my theory. I just did a quick > check. > >> > >> Hope that solved your problem. > >> > >> Scott > >> > >> > >> I think this may be why the you are getting this structure > >> misalignment? > >> > >> > >> On Fri, Jul 4, 2008 at 2:24 AM, Rainer Gerhards > >> wrote: > >> > Hi list, > >> > > >> > I am posting a question here in the hope that some of the > > subscribers > >> > may be able to lend me a helping hand. > >> > > >> > Recently, I have begun to add a testbench to rsyslog. The idea is > >> that > >> > over time the project should have canned tests which are easy to > run > >> on > >> > each version (as part of make distcheck at latest), increasing the > >> > overall code quality. > >> > > >> > "All" (so far two ;)) tests are located in the tests subdirectory. > >> One > >> > test fails if compiled in release mode, that is rscript-parse.c. I > >> have > >> > tracked down the failure cause and it is different struct member > >> > alignment in the ctok_token_t structure. The alignment is > different > >> in > >> > the rsyslog runtime and this test tool (I have compared the > offsets > >> > computed for pToken->tok and they are different). So far, so good. > >> But I > >> > do not find the cause of this misalignment. I checked the make > >> output, > >> > and as it looks both the runtime as well as the tool are compiled > >> with > >> > the same compiler options. Also, in debug mode it works OK, but in > >> > release mode (--disable-debug) it fails. > >> > > >> > I am sure the problem is something quite simple, but I have run > out > >> of > >> > ideas of what it may be (or, more probable, I simply overlook > >> > something). > >> > > >> > Any help would be deeply appreciated. > >> > > >> > Thanks, > >> > 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 friedl at hq.adiscon.com Mon Jul 7 16:02:21 2008 From: friedl at hq.adiscon.com (Florian Riedl) Date: Mon, 7 Jul 2008 16:02:21 +0200 Subject: [rsyslog] rsyslog 3.19.9 (devel) released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44ED69@grfint2.intern.adiscon.com> Hi all, Rsyslog 3.19.9, a member of the development branch, has been released. Documentation on how to setup TLS syslog has been greatly improved. Also, omusrmsg has been rewritten to utilize rsyslog's threading instead of forking of children to send the messages. This is expected to also solve some issues with zombie processes. Finally, an issue with TLS anonymous mode, which still required client certificates, and a problem with the RainerScript parser, which did not detect every syntax error, was solved. This is a recommended update for all development branch users. Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-117.phtml Changelog: http://www.rsyslog.com/Article250.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 rfujita at redhat.com Wed Jul 9 10:34:27 2008 From: rfujita at redhat.com (Ryo Fujita) Date: Wed, 9 Jul 2008 17:34:27 +0900 Subject: [rsyslog] I'd like to translate documents into Japanese. Message-ID: <0FA4369F-E6CA-4183-842B-751A424A1A0D@redhat.com> Hi List, $subject And I guess that documents are managed with Wiki. Do you have a plan to do i10n/i18n with rsyslog? Best Rio. ######################################################################## Ryo Fujita 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 Wed Jul 9 10:46:34 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 9 Jul 2008 10:46:34 +0200 Subject: [rsyslog] I'd like to translate documents into Japanese. In-Reply-To: <0FA4369F-E6CA-4183-842B-751A424A1A0D@redhat.com> References: <0FA4369F-E6CA-4183-842B-751A424A1A0D@redhat.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44ED84@grfint2.intern.adiscon.com> Hi Rio-san, many thanks for your help! Much appreciated. As far as the documentation goes, there are actually two places. One is the wiki ( http://wiki.rsyslog.com ) , but then there is also a set (called "the core set") of html documentation. The reasoning is as follows: The wiki is a great resource and easy to edit. However, it does not provide the versioning we need. For example, there are changes in the way things can be configured between v2 and v3. In the wiki, version-specifc pages are a bit hard to find. Also, the wiki is only available online. To solve this, we have the core set: html files which document rsyslog's config directives as well as generic use cases. This is contained in git and under version control. An exactly matching version of the documentation is distributed with each source tarball. I think it would be very useful to have a Japanese version of (at least some) documents of the core set. If you are interested in that, I would add your translations to git and the distribution set. > Do you have a plan to do i10n/i18n with rsyslog? Could you elaborate a little bit on this? Unfortunately, I do neither speak Japanse nor any other language with a non-western script. I asked around several times and some folks from Japan told me that rsyslog works well with Japanese characters. But I am always interested in enhancing this support - I just need some guidance what is needed. Looking forward to your relpy, Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Ryo Fujita > Sent: Wednesday, July 09, 2008 10:34 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] I'd like to translate documents into Japanese. > > Hi List, > > $subject > And I guess that documents are managed with Wiki. > Do you have a plan to do i10n/i18n with rsyslog? > > Best Rio. > > ####################################################################### > # > Ryo Fujita > 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 > ####################################################################### > # > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog From rfujita at redhat.com Wed Jul 9 11:33:29 2008 From: rfujita at redhat.com (Ryo Fujita) Date: Wed, 9 Jul 2008 18:33:29 +0900 Subject: [rsyslog] I'd like to translate documents into Japanese. In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44ED84@grfint2.intern.adiscon.com> References: <0FA4369F-E6CA-4183-842B-751A424A1A0D@redhat.com> <577465F99B41C842AAFBE9ED71E70ABA44ED84@grfint2.intern.adiscon.com> Message-ID: <5582994A-7EDB-439F-ACCA-BA66996460F9@redhat.com> Hi Rainer-san, Thank you for your quick response! Too quick, I was surprised. I understand the status of the project and what I should do. #The reason why I asked how the contributors collaborate for rsyslog was that I cloned the repository with git and I couldn't find any docbook or .po files. As soon as possible, I'll start to translate docs into Japanese. BTW, Fedora 9 has the man page, rsyslogd(8) with the version 3.14.0. But I can't find the source file of this version in the git tree and Wiki. Why? Best Rio. On 2008/07/09, at 17:46, Rainer Gerhards wrote: > Hi Rio-san, > > many thanks for your help! Much appreciated. > > As far as the documentation goes, there are actually two places. One > is > the wiki ( http://wiki.rsyslog.com ) , but then there is also a set > (called "the core set") of html documentation. The reasoning is as > follows: The wiki is a great resource and easy to edit. However, it > does > not provide the versioning we need. For example, there are changes in > the way things can be configured between v2 and v3. In the wiki, > version-specifc pages are a bit hard to find. Also, the wiki is only > available online. > > To solve this, we have the core set: html files which document > rsyslog's > config directives as well as generic use cases. This is contained in > git > and under version control. An exactly matching version of the > documentation is distributed with each source tarball. > > I think it would be very useful to have a Japanese version of (at > least > some) documents of the core set. If you are interested in that, I > would > add your translations to git and the distribution set. > >> Do you have a plan to do i10n/i18n with rsyslog? > > Could you elaborate a little bit on this? Unfortunately, I do neither > speak Japanse nor any other language with a non-western script. I > asked > around several times and some folks from Japan told me that rsyslog > works well with Japanese characters. But I am always interested in > enhancing this support - I just need some guidance what is needed. > > Looking forward to your relpy, > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Ryo Fujita >> Sent: Wednesday, July 09, 2008 10:34 AM >> To: rsyslog at lists.adiscon.com >> Subject: [rsyslog] I'd like to translate documents into Japanese. >> >> Hi List, >> >> $subject >> And I guess that documents are managed with Wiki. >> Do you have a plan to do i10n/i18n with rsyslog? >> >> Best Rio. >> >> > ####################################################################### >> # >> Ryo Fujita >> 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 >> > ####################################################################### >> # >> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog ######################################################################## Ryo Fujita 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 Wed Jul 9 11:43:17 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 09 Jul 2008 11:43:17 +0200 Subject: [rsyslog] I'd like to translate documents into Japanese. In-Reply-To: <5582994A-7EDB-439F-ACCA-BA66996460F9@redhat.com> References: <0FA4369F-E6CA-4183-842B-751A424A1A0D@redhat.com> <577465F99B41C842AAFBE9ED71E70ABA44ED84@grfint2.intern.adiscon.com> <5582994A-7EDB-439F-ACCA-BA66996460F9@redhat.com> Message-ID: <1215596597.7184.29.camel@rgf9dev.intern.adiscon.com> Hi Rio-san, On Wed, 2008-07-09 at 18:33 +0900, Ryo Fujita wrote: > Hi Rainer-san, > > Thank you for your quick response! > Too quick, I was surprised. I am trying my best - doesn't always work :) > > I understand the status of the project and what I should do. > > #The reason why I asked how the contributors collaborate for rsyslog > was that I cloned the repository with git and I couldn't find any > docbook or .po files. The doc set is in the ./doc subfolder, with .html files (obviously not what you looked for :)). I think it would be a good time now to create a ./doc/en and ./doc/jp. Do you agree? If so, you could copy over the files and I would integrate them as soon as I have them availalbe. > > As soon as possible, I'll start to translate docs into Japanese. > > BTW, Fedora 9 has the man page, rsyslogd(8) with the version 3.14.0. > But I can't find the source file of this version in the git tree and > Wiki. > Why? I restructured the directory structure a bit in 3.19. It is now in the ./tools directory, because it belongs to the rsyslogd tool. Here is a quick link: http://git.adiscon.com/?p=rsyslog.git;a=tree;f=tools;h=20be95b3073dc891603b489c68f0c4d0fc5b215b;hb=HEAD All the best, Rainer > > Best Rio. > > On 2008/07/09, at 17:46, Rainer Gerhards wrote: > > > Hi Rio-san, > > > > many thanks for your help! Much appreciated. > > > > As far as the documentation goes, there are actually two places. One > > is > > the wiki ( http://wiki.rsyslog.com ) , but then there is also a set > > (called "the core set") of html documentation. The reasoning is as > > follows: The wiki is a great resource and easy to edit. However, it > > does > > not provide the versioning we need. For example, there are changes in > > the way things can be configured between v2 and v3. In the wiki, > > version-specifc pages are a bit hard to find. Also, the wiki is only > > available online. > > > > To solve this, we have the core set: html files which document > > rsyslog's > > config directives as well as generic use cases. This is contained in > > git > > and under version control. An exactly matching version of the > > documentation is distributed with each source tarball. > > > > I think it would be very useful to have a Japanese version of (at > > least > > some) documents of the core set. If you are interested in that, I > > would > > add your translations to git and the distribution set. > > > >> Do you have a plan to do i10n/i18n with rsyslog? > > > > Could you elaborate a little bit on this? Unfortunately, I do neither > > speak Japanse nor any other language with a non-western script. I > > asked > > around several times and some folks from Japan told me that rsyslog > > works well with Japanese characters. But I am always interested in > > enhancing this support - I just need some guidance what is needed. > > > > Looking forward to your relpy, > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of Ryo Fujita > >> Sent: Wednesday, July 09, 2008 10:34 AM > >> To: rsyslog at lists.adiscon.com > >> Subject: [rsyslog] I'd like to translate documents into Japanese. > >> > >> Hi List, > >> > >> $subject > >> And I guess that documents are managed with Wiki. > >> Do you have a plan to do i10n/i18n with rsyslog? > >> > >> Best Rio. > >> > >> > > ####################################################################### > >> # > >> Ryo Fujita > >> 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 > >> > > ####################################################################### > >> # > >> > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > ######################################################################## > Ryo Fujita > 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 > ######################################################################## > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog From rfujita at redhat.com Wed Jul 9 11:59:48 2008 From: rfujita at redhat.com (Ryo Fujita) Date: Wed, 9 Jul 2008 18:59:48 +0900 Subject: [rsyslog] I'd like to translate documents into Japanese. In-Reply-To: <1215596597.7184.29.camel@rgf9dev.intern.adiscon.com> References: <0FA4369F-E6CA-4183-842B-751A424A1A0D@redhat.com> <577465F99B41C842AAFBE9ED71E70ABA44ED84@grfint2.intern.adiscon.com> <5582994A-7EDB-439F-ACCA-BA66996460F9@redhat.com> <1215596597.7184.29.camel@rgf9dev.intern.adiscon.com> Message-ID: Hi Rainer-san, On 2008/07/09, at 18:43, Rainer Gerhards wrote: > I am trying my best - doesn't always work :) I'm working for Red Hat's Tokyo office. Do you live in Germany? If so, we can co-work in the daytime! > The doc set is in the ./doc subfolder, with .html files (obviously not > what you looked for :)). I think it would be a good time now to create > a ./doc/en and ./doc/jp. Do you agree? If so, you could copy over the > files and I would integrate them as soon as I have them availalbe. I agree with you totally. Because Fedora 9 has included rsyslog, lots Japanese and other non English/German speakers have started using it. Sooner or later, we'll need to create ./doc/other_lang directories :) > I restructured the directory structure a bit in 3.19. It is now in > the ./tools directory, because it belongs to the rsyslogd tool. > > Here is a quick link: > > http://git.adiscon.com/?p=rsyslog.git;a=tree;f=tools;h=20be95b3073dc891603b489c68f0c4d0fc5b215b;hb=HEAD Oh, I find the file rsyslogd.8 in tools directory. I'll start translating it first. Best Rio. On 2008/07/09, at 18:43, Rainer Gerhards wrote: > Hi Rio-san, > > On Wed, 2008-07-09 at 18:33 +0900, Ryo Fujita wrote: >> Hi Rainer-san, >> >> Thank you for your quick response! >> Too quick, I was surprised. > > I am trying my best - doesn't always work :) > >> >> I understand the status of the project and what I should do. >> >> #The reason why I asked how the contributors collaborate for rsyslog >> was that I cloned the repository with git and I couldn't find any >> docbook or .po files. > > The doc set is in the ./doc subfolder, with .html files (obviously not > what you looked for :)). I think it would be a good time now to create > a ./doc/en and ./doc/jp. Do you agree? If so, you could copy over the > files and I would integrate them as soon as I have them availalbe. >> >> As soon as possible, I'll start to translate docs into Japanese. >> >> BTW, Fedora 9 has the man page, rsyslogd(8) with the version 3.14.0. >> But I can't find the source file of this version in the git tree and >> Wiki. >> Why? > > I restructured the directory structure a bit in 3.19. It is now in > the ./tools directory, because it belongs to the rsyslogd tool. > > Here is a quick link: > > http://git.adiscon.com/?p=rsyslog.git;a=tree;f=tools;h=20be95b3073dc891603b489c68f0c4d0fc5b215b;hb=HEAD > > > All the best, > Rainer >> >> Best Rio. >> >> On 2008/07/09, at 17:46, Rainer Gerhards wrote: >> >>> Hi Rio-san, >>> >>> many thanks for your help! Much appreciated. >>> >>> As far as the documentation goes, there are actually two places. One >>> is >>> the wiki ( http://wiki.rsyslog.com ) , but then there is also a set >>> (called "the core set") of html documentation. The reasoning is as >>> follows: The wiki is a great resource and easy to edit. However, it >>> does >>> not provide the versioning we need. For example, there are changes >>> in >>> the way things can be configured between v2 and v3. In the wiki, >>> version-specifc pages are a bit hard to find. Also, the wiki is only >>> available online. >>> >>> To solve this, we have the core set: html files which document >>> rsyslog's >>> config directives as well as generic use cases. This is contained in >>> git >>> and under version control. An exactly matching version of the >>> documentation is distributed with each source tarball. >>> >>> I think it would be very useful to have a Japanese version of (at >>> least >>> some) documents of the core set. If you are interested in that, I >>> would >>> add your translations to git and the distribution set. >>> >>>> Do you have a plan to do i10n/i18n with rsyslog? >>> >>> Could you elaborate a little bit on this? Unfortunately, I do >>> neither >>> speak Japanse nor any other language with a non-western script. I >>> asked >>> around several times and some folks from Japan told me that rsyslog >>> works well with Japanese characters. But I am always interested in >>> enhancing this support - I just need some guidance what is needed. >>> >>> Looking forward to your relpy, >>> Rainer >>> >>>> -----Original Message----- >>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>> bounces at lists.adiscon.com] On Behalf Of Ryo Fujita >>>> Sent: Wednesday, July 09, 2008 10:34 AM >>>> To: rsyslog at lists.adiscon.com >>>> Subject: [rsyslog] I'd like to translate documents into Japanese. >>>> >>>> Hi List, >>>> >>>> $subject >>>> And I guess that documents are managed with Wiki. >>>> Do you have a plan to do i10n/i18n with rsyslog? >>>> >>>> Best Rio. >>>> >>>> >>> ####################################################################### >>>> # >>>> Ryo Fujita >>>> 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 >>>> >>> ####################################################################### >>>> # >>>> >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >> >> ######################################################################## >> Ryo Fujita >> 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 >> ######################################################################## >> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog ######################################################################## Ryo Fujita 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 Wed Jul 9 12:06:11 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 09 Jul 2008 12:06:11 +0200 Subject: [rsyslog] I'd like to translate documents into Japanese. In-Reply-To: References: <0FA4369F-E6CA-4183-842B-751A424A1A0D@redhat.com> <577465F99B41C842AAFBE9ED71E70ABA44ED84@grfint2.intern.adiscon.com> <5582994A-7EDB-439F-ACCA-BA66996460F9@redhat.com> <1215596597.7184.29.camel@rgf9dev.intern.adiscon.com> Message-ID: <1215597971.7184.33.camel@rgf9dev.intern.adiscon.com> Hi Rio-san, On Wed, 2008-07-09 at 18:59 +0900, Ryo Fujita wrote: > Hi Rainer-san, > > On 2008/07/09, at 18:43, Rainer Gerhards wrote: > > > I am trying my best - doesn't always work :) > > > I'm working for Red Hat's Tokyo office. > Do you live in Germany? > If so, we can co-work in the daytime! indeed, I do. So we can at least try. > > > The doc set is in the ./doc subfolder, with .html files (obviously not > > what you looked for :)). I think it would be a good time now to create > > a ./doc/en and ./doc/jp. Do you agree? If so, you could copy over the > > files and I would integrate them as soon as I have them availalbe. > > I agree with you totally. > Because Fedora 9 has included rsyslog, > lots Japanese and other non English/German speakers have started using > it. > Sooner or later, we'll need to create ./doc/other_lang directories :) I'll begin this when I start the next devel branch. I scheduled it for this week, but I got a bug report for the beta, which I would like to fix first. But in any case... soon! > > > I restructured the directory structure a bit in 3.19. It is now in > > the ./tools directory, because it belongs to the rsyslogd tool. > > > > Here is a quick link: > > > > http://git.adiscon.com/?p=rsyslog.git;a=tree;f=tools;h=20be95b3073dc891603b489c68f0c4d0fc5b215b;hb=HEAD > > > Oh, I find the file rsyslogd.8 in tools directory. > I'll start translating it first. Excellent. If you go through ./doc, you'll also notice that there is room for improvement. I think the structure is not very good today. Suggestions are welcome :) Rainer > > Best Rio. > > On 2008/07/09, at 18:43, Rainer Gerhards wrote: > > > Hi Rio-san, > > > > On Wed, 2008-07-09 at 18:33 +0900, Ryo Fujita wrote: > >> Hi Rainer-san, > >> > >> Thank you for your quick response! > >> Too quick, I was surprised. > > > > I am trying my best - doesn't always work :) > > > >> > >> I understand the status of the project and what I should do. > >> > >> #The reason why I asked how the contributors collaborate for rsyslog > >> was that I cloned the repository with git and I couldn't find any > >> docbook or .po files. > > > > The doc set is in the ./doc subfolder, with .html files (obviously not > > what you looked for :)). I think it would be a good time now to create > > a ./doc/en and ./doc/jp. Do you agree? If so, you could copy over the > > files and I would integrate them as soon as I have them availalbe. > >> > >> As soon as possible, I'll start to translate docs into Japanese. > >> > >> BTW, Fedora 9 has the man page, rsyslogd(8) with the version 3.14.0. > >> But I can't find the source file of this version in the git tree and > >> Wiki. > >> Why? > > > > I restructured the directory structure a bit in 3.19. It is now in > > the ./tools directory, because it belongs to the rsyslogd tool. > > > > Here is a quick link: > > > > http://git.adiscon.com/?p=rsyslog.git;a=tree;f=tools;h=20be95b3073dc891603b489c68f0c4d0fc5b215b;hb=HEAD > > > > > > All the best, > > Rainer > >> > >> Best Rio. > >> > >> On 2008/07/09, at 17:46, Rainer Gerhards wrote: > >> > >>> Hi Rio-san, > >>> > >>> many thanks for your help! Much appreciated. > >>> > >>> As far as the documentation goes, there are actually two places. One > >>> is > >>> the wiki ( http://wiki.rsyslog.com ) , but then there is also a set > >>> (called "the core set") of html documentation. The reasoning is as > >>> follows: The wiki is a great resource and easy to edit. However, it > >>> does > >>> not provide the versioning we need. For example, there are changes > >>> in > >>> the way things can be configured between v2 and v3. In the wiki, > >>> version-specifc pages are a bit hard to find. Also, the wiki is only > >>> available online. > >>> > >>> To solve this, we have the core set: html files which document > >>> rsyslog's > >>> config directives as well as generic use cases. This is contained in > >>> git > >>> and under version control. An exactly matching version of the > >>> documentation is distributed with each source tarball. > >>> > >>> I think it would be very useful to have a Japanese version of (at > >>> least > >>> some) documents of the core set. If you are interested in that, I > >>> would > >>> add your translations to git and the distribution set. > >>> > >>>> Do you have a plan to do i10n/i18n with rsyslog? > >>> > >>> Could you elaborate a little bit on this? Unfortunately, I do > >>> neither > >>> speak Japanse nor any other language with a non-western script. I > >>> asked > >>> around several times and some folks from Japan told me that rsyslog > >>> works well with Japanese characters. But I am always interested in > >>> enhancing this support - I just need some guidance what is needed. > >>> > >>> Looking forward to your relpy, > >