Bug#1010619: rsyslog: CVE-2022-24903: Potential heap buffer overflow in TCP syslog server (receiver) components

[Rainer Gerhards]

note: 8.2204.1 is 8..2204.0 with just the fix cherry-picked. No other changes.

Rainer

El sáb, 7 may 2022 a las 14:48, Salvatore Bonaccorso
() escribió:
>
> Hi Michael,
>
> [looping in the sec-team for completeness]
>
> On Thu, May 05, 2022 at 10:19:38PM +0200, Michael Biebl wrote:
> > Am 05.05.22 um 17:10 schrieb Salvatore Bonaccorso:
> > > Source: rsyslog
> > > Version: 8.2204.0-1
> > > Severity: grave
> > > Tags: security upstream
> > > Justification: user security hole
> > > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > > 
> > >
> > > Hi,
> > >
> > > The following vulnerability was published for rsyslog. Filling for now
> > > as grave, but we might downgrade. Probably affected configurations are
> > > not that common if I understood correctly, the advisory has some
> > > comments about it as well[1].
> >
> > Yeah, I think this feature is obscure enough (and not enabled by default)
> > that non-RC severity is fine.
>
> Thinking a bit more on it I see two aspects:
>
> * Usually following recommendations one should not expose recievers to
>   public, which makes the risk considerably lower.
> * Though still reciervers enable octed-framing by default.
>
> So I think to leave the severity actually as it is, and consider it RC
> and at earliest point possible for you either do a cherry-picked
> upload on top of 8.2204.0-1 or just upload 8.2204.1 to unstable, I
> htink I would prefer the later.
>
> Secondly, about releasing a DSA, still slight borderline, but I think
> we would be safer to release one. I can help rpepare updates for
> bullseye and buster here if needed and wanted. I the git repository I
> see 8.2102.0-2+deb11u1 as released for bullseye but this change
> actually never landed to bullseye and was not acked by SRM?
>
> Regards,
> Salvatore
>

Bug#720096: marked as pending in rsyslog

[Rainer Gerhards]

Not sure if that helps with the issue, but rsyslog closes and re-opens
all logfiles on HUP.

Rainer

El mié, 19 may 2021 a las 9:45, Vincent Lefevre () escribió:
>
> On 2021-05-19 09:16:00 +0200, Harald Dunkel wrote:
> > The fix is difficult. logrotate has to tell rsyslog *which* logfiles
> > have been rotated. Currently rsyslog has to guess. Probably it assumes
> > that all logfiles have been rotated on the very first signal; thats
> > why your workaround (the single block in logrotate.d/rsyslog) works.
>
> rsyslog could decide that all the log files have possibly been rotated
> and reopen all of them.
>
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>

Bug#929608: pmciscoios can be really helpful

[Rainer Gerhards]

As I thought: it's a very slim module and easy to maintain. There were
not changes in the past couple of years because there was no need.

I would recommend enabling it.

Rainer

El jue, 22 abr 2021 a las 19:57, Rainer Gerhards
() escribió:
>
> I'll check in depth tomorrow, but it's a very small module and I think it's 
> safe. But haven't looked at it for a long time (because it is so simple), I 
> like to double check.
>
> Rainer
>
> Sent from phone, thus brief.
>
> Michael Biebl  schrieb am Do., 22. Apr. 2021, 19:28:
>>
>> Am 21.04.21 um 11:03 schrieb Václav Ovsík:
>> > Fellow maintainer,
>> > please, enable pmciscoios. I can benefit from it too. Our Cisco switches 
>> > log
>> > with double timestamp… :(
>> >
>> > e.g.
>> >   Apr 21 09:16:53 sw-brn02.brn.i.cz 13134: Apr 21 07:16:53.208: 
>> > %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/27, 
>> > changed state to up
>> >
>> > People want to solve this, so I will now have to rebuild the package. :-(
>> >
>>
>>
>> Before enabling this module, I'd still would like to have Rainer's
>> (upstream author) feedback about the state of this module and if he
>> feels it's safe to enable it (i.e. it's solid and properly maintained).
>>
>> I don't feel comfortable enabling modules which are not or only
>> semi-supported by upstream.
>>
>> Regards,
>> Michael
>>

Bug#929608: pmciscoios can be really helpful

[Rainer Gerhards]

I'll check in depth tomorrow, but it's a very small module and I think it's
safe. But haven't looked at it for a long time (because it is so simple), I
like to double check.

Rainer

Sent from phone, thus brief.

Michael Biebl  schrieb am Do., 22. Apr. 2021, 19:28:

> Am 21.04.21 um 11:03 schrieb Václav Ovsík:
> > Fellow maintainer,
> > please, enable pmciscoios. I can benefit from it too. Our Cisco switches
> log
> > with double timestamp… :(
> >
> > e.g.
> >   Apr 21 09:16:53 sw-brn02.brn.i.cz 13134: Apr 21 07:16:53.208:
> %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/27,
> changed state to up
> >
> > People want to solve this, so I will now have to rebuild the package. :-(
> >
>
>
> Before enabling this module, I'd still would like to have Rainer's
> (upstream author) feedback about the state of this module and if he
> feels it's safe to enable it (i.e. it's solid and properly maintained).
>
> I don't feel comfortable enabling modules which are not or only
> semi-supported by upstream.
>
> Regards,
> Michael
>
>

Bug#935300: rsyslog: FTBFS on s390x

[Rainer Gerhards]

I had a look but to me it seems we actually run out file handles. No
failure indication.

Is this run in parallel? If so, how many tasks?

Sent from phone, thus brief.

Michael Biebl  schrieb am Mi., 21. Aug. 2019, 19:10:

> Am 21.08.19 um 17:43 schrieb Sven Joachim:
> > On 2019-08-21 15:43 +0200, Ivo De Decker wrote:
> >
> >> Hi,
> >>
> >> On 8/21/19 3:14 PM, Michael Biebl wrote:
> >>> Am 21.08.19 um 14:39 schrieb Ivo De Decker:
>  package: src:rsyslog
>  version: 8.1908.0-1
>  severity: serious
>  tags: ftbfs
> 
>  Hi,
> 
>  The latest version of rsyslog in unstable fails on s390x:
> 
>  https://buildd.debian.org/status/package.php?p=rsyslog
> >>> It's a test-suite failure. Seems the test-suite ran out-of
> >>> ressources
> >>> rsyslogd: file './rstb_365910_e7e00756.4.log': open error: Too many
> >>> open
> >>> files [v8.1908.0 try https://www.rsyslog.com/e/2433 ]
> >>> Maybe just a temporary issue. Could you give it back?
> >>
> >> I already did that. It failed twice.
> >
> > The same error occurred on powerpc, ppc64 and sparc64, so I suspect
> > it is specific to big endian architectures.
>
> Rainer, can you have a look?
>
> Full build logs are at
> https://buildd.debian.org/status/package.php?p=rsyslog
>
> Regards,
> Michael
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>

Bug#932068: Fwd: Bug#932068: rsyslog FTCBFS: uses mysql_config

[Rainer Gerhards]

looks like it doesn't work out... pls have a look at CI.

Thx,
Rainer

El lun., 15 jul. 2019 a las 18:36, Rainer Gerhards
() escribió:
>
> ah, it was all there, so I applied the patch and created a PR:
>
> https://github.com/rsyslog/rsyslog/pull/3747
>
> Let's see how it goes.
>
> Rainer
>
> El lun., 15 jul. 2019 a las 18:05, Rainer Gerhards
> () escribió:
> >
> > Hi all,
> >
> > thanks for your help! I'll give it a try, but please bear with me a
> > little bit. Hope to get to it this week (if all goes well tomorrow).
> >
> > Rainer
> >
> > El dom., 14 jul. 2019 a las 21:46, Helmut Grohne () 
> > escribió:
> > >
> > > Hi Michael,
> > >
> > > On Sun, Jul 14, 2019 at 09:10:45PM +0200, Michael Biebl wrote:
> > > > can you have a look at this?
> > > > I'd rather not ship this as a downstream patch.
> > >
> > > I tried to write the patch in an upstreamable way. I think that it
> > > should help other cross distributions as well. For instance, yocto
> > > carries
> > > http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/rsyslog/rsyslog/use-pkgconfig-to-check-libgcrypt.patch?h=master
> > > for avoiding libgcrypt-config. This patch could also be upstreamed by
> > > trying pkg-config before libgcrypt-config. ptxdist simply disabled mysql
> > > integration.
> > >
> > > > @Helmut: Is that mysqlclient.pc file provided via a Debian specific 
> > > > patch?
> > >
> > > Prior to the mariadb fork, the standard mysql client library provided
> > > this .pc file. As far as I understand, it is now provided by mariadb as
> > > a compatibility symlink much in the same way as it provides mysql_config
> > > as a compatibility symlink. I think it is pretty safe to assume its
> > > presence, but we can extend the patch to explicitly check for mariadb.pc
> > > if that is preferred. I don't expect mysqlclient.pc (or mysql_config) to
> > > go away anytime soon due to its widespread usage.
> > >
> > > Helmut
>

Bug#932068: Fwd: Bug#932068: rsyslog FTCBFS: uses mysql_config

[Rainer Gerhards]

ah, it was all there, so I applied the patch and created a PR:

https://github.com/rsyslog/rsyslog/pull/3747

Let's see how it goes.

Rainer

El lun., 15 jul. 2019 a las 18:05, Rainer Gerhards
() escribió:
>
> Hi all,
>
> thanks for your help! I'll give it a try, but please bear with me a
> little bit. Hope to get to it this week (if all goes well tomorrow).
>
> Rainer
>
> El dom., 14 jul. 2019 a las 21:46, Helmut Grohne () 
> escribió:
> >
> > Hi Michael,
> >
> > On Sun, Jul 14, 2019 at 09:10:45PM +0200, Michael Biebl wrote:
> > > can you have a look at this?
> > > I'd rather not ship this as a downstream patch.
> >
> > I tried to write the patch in an upstreamable way. I think that it
> > should help other cross distributions as well. For instance, yocto
> > carries
> > http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/rsyslog/rsyslog/use-pkgconfig-to-check-libgcrypt.patch?h=master
> > for avoiding libgcrypt-config. This patch could also be upstreamed by
> > trying pkg-config before libgcrypt-config. ptxdist simply disabled mysql
> > integration.
> >
> > > @Helmut: Is that mysqlclient.pc file provided via a Debian specific patch?
> >
> > Prior to the mariadb fork, the standard mysql client library provided
> > this .pc file. As far as I understand, it is now provided by mariadb as
> > a compatibility symlink much in the same way as it provides mysql_config
> > as a compatibility symlink. I think it is pretty safe to assume its
> > presence, but we can extend the patch to explicitly check for mariadb.pc
> > if that is preferred. I don't expect mysqlclient.pc (or mysql_config) to
> > go away anytime soon due to its widespread usage.
> >
> > Helmut

Bug#932068: Fwd: Bug#932068: rsyslog FTCBFS: uses mysql_config

[Rainer Gerhards]

Hi all,

thanks for your help! I'll give it a try, but please bear with me a
little bit. Hope to get to it this week (if all goes well tomorrow).

Rainer

El dom., 14 jul. 2019 a las 21:46, Helmut Grohne () escribió:
>
> Hi Michael,
>
> On Sun, Jul 14, 2019 at 09:10:45PM +0200, Michael Biebl wrote:
> > can you have a look at this?
> > I'd rather not ship this as a downstream patch.
>
> I tried to write the patch in an upstreamable way. I think that it
> should help other cross distributions as well. For instance, yocto
> carries
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/rsyslog/rsyslog/use-pkgconfig-to-check-libgcrypt.patch?h=master
> for avoiding libgcrypt-config. This patch could also be upstreamed by
> trying pkg-config before libgcrypt-config. ptxdist simply disabled mysql
> integration.
>
> > @Helmut: Is that mysqlclient.pc file provided via a Debian specific patch?
>
> Prior to the mariadb fork, the standard mysql client library provided
> this .pc file. As far as I understand, it is now provided by mariadb as
> a compatibility symlink much in the same way as it provides mysql_config
> as a compatibility symlink. I think it is pretty safe to assume its
> presence, but we can extend the patch to explicitly check for mariadb.pc
> if that is preferred. I don't expect mysqlclient.pc (or mysql_config) to
> go away anytime soon due to its widespread usage.
>
> Helmut

Bug#930816: TLS OpenSSL driver module missing for rsyslog

[Rainer Gerhards]

El vie., 21 jun. 2019 a las 13:36, Michael Biebl () escribió:
>
> Hi Rainer
>
> Am 21.06.19 um 12:36 schrieb Rainer Gerhards:
> > El vie., 21 jun. 2019 a las 12:03, Michael Biebl () 
> > escribió:
> >>
> >> Control: severity -1  wishlist
> >>
> >> Am 21.06.19 um 10:40 schrieb Peter Viskup:
> >>> Package: rsyslog
> >>>
> >>> Would it be possible to provide ossl rsyslog netstream driver as an 
> >>> package?
> >>> It is missing and would be great to have possibilities to choose between
> >>> two TLS drivers available (GnuTLS and OpenSSL).
> >>> Tried to build the package version 8.1901 for Stretch with no issues.
> >>
> >> The important question is why?
> >> What benefits does OpenSSL offer?
> >
> > - much better error messages - on GnuTLS we can usually emit only very
> > generic errors
> > - much less picky in regard to certificate file - we very often had
> > problems with GnuTLS here
> >
> > Our current mainstream recommendation is to use the openssl route as
> > it provides a much better user experience.
>
>
> I see that parts of the code base are still GPL-3 (only) according to
> their license headers.
> And the combination GPL + OpenSSL is problematic afair, see
> https://people.gnome.org/~markmc/openssl-and-the-gpl.html
>
> Which is why avoided the use of OpenSSL where possible.

OK, good argument. It's obviously your (Debian) call.

Rainer

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

Bug#930816: TLS OpenSSL driver module missing for rsyslog

[Rainer Gerhards]

El vie., 21 jun. 2019 a las 12:03, Michael Biebl () escribió:
>
> Control: severity -1  wishlist
>
> Am 21.06.19 um 10:40 schrieb Peter Viskup:
> > Package: rsyslog
> >
> > Would it be possible to provide ossl rsyslog netstream driver as an package?
> > It is missing and would be great to have possibilities to choose between
> > two TLS drivers available (GnuTLS and OpenSSL).
> > Tried to build the package version 8.1901 for Stretch with no issues.
>
> The important question is why?
> What benefits does OpenSSL offer?

- much better error messages - on GnuTLS we can usually emit only very
generic errors
- much less picky in regard to certificate file - we very often had
problems with GnuTLS here

Our current mainstream recommendation is to use the openssl route as
it provides a much better user experience.

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

Bug#927730: Please build with --enable-mmtaghostname

[Rainer Gerhards]

El mar., 23 abr. 2019 a las 10:33, Michael Biebl () escribió:
>
> Am 22.04.19 um 04:12 schrieb Dmitry Smirnov:
> > Source: rsyslog
> > Version: 8.1901.0-1
> > Severity: wishlist
> >
> > https://www.rsyslog.com/doc/v8-stable/configuration/modules/mmtaghostname.html
> >
>
> Rainer, what's your take on this module?

new contributed module

> Is it useful?

don't know myself. From the doc this might be the main use:

"AWS Use case : applications in auto-scaling systems provides logs to
rsyslog through udp/tcp. As a result of auto-scaling, the name of the
host is based on an ephemeral IPs (short term meaning). In this
situation rsyslog local hostname is generally closed to businesss
rule. So replacing hostanme received by the rsyslog local Hostname
provide values to the logs collected."

> Reasonably maintained upstream?
no

HTH
Rainer
>
> Regards,
> Michael
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>

Bug#927736: Please build with --enable-pmnull

[Rainer Gerhards]

El lun., 22 abr. 2019 a las 11:00, Dmitry Smirnov
() escribió:
>
> Hi Rainer,
>
> Thank you sincerely for your excellent work on Rsyslog.
>
> On Monday, 22 April 2019 6:34:27 PM AEST Rainer Gerhards wrote:
> > As upstream maintainer I would be interested in your use case for pmnull.
>
> I'm not sure if I have a case yet. I'm trying to experiment with centralized
> logs processing and forwarding. There are several rsyslogs on various servers
> that forward everything (over RELP) to one Rsyslog instance where messages
> are processed, converted to JSON and forwarded to Elasticsearch.
>
> While working with various types of messages originated from various places
> (Docker containers, sockets, UDP and TCP listeners) I was trying to find out
> the most effective way to process messages and to avoid things like RFC5424
> message inside RFC5424 (from double forwarding a message received by local
> rsyslog, then passed to forwarding rsyslog). At some point I tried disabling
> all parsers in ruleset to pass unmodified message to forwarding Rsyslog
> instance. Unfortunately at that point I've found that "pmnull" is not built
> in hence this bug report...

actually, we have the "rawmsg" property. This is the message as it was
received. All pmnull does is set "msg" to "rawmsg" (and use "" for
many other properties). To forward the original content, you can
simply do:

template(name="raw" type="string" string="%rawmsg%")
action(type="omfwd" target="example.com" template="raw")

That's it. I wrote pmnull because some folks thought it would be nice
to save 0.05% processing time by not unnecessarily parse the message.
I even doubt it's that amount of performance enhancement as the
messages need to be populated in any case...

Rainer

>
> --
> All the best,
>  Dmitry Smirnov.
>
> ---
>
> Truth — Something somehow discreditable to someone.
> -- H. L. Mencken, 1949

Bug#927736: Please build with --enable-pmnull

[Rainer Gerhards]

> Not sure what are you talking about. "pmnull" is a core module (not a
> contributed one) and it does _nothing_ so there are no risks of enabling it.
>
> "pmnull" is needed to disable parsers because Rsyslog do not allow empty
> parsers list...

As upstream maintainer I would be interested in your use case for pmnull.

Rainer

Bug#900718: rsyslog: FTBFS on hurd-i386

[Rainer Gerhards]

Hi,

Rainer from upstream here. Where is the missing lsof causing issues?
That would probably be the right place to fix. I did a grep over the
testbench and do not see any place where it is required (tests skip
via 77 exit code if not available).

Rainer
El dom., 4 nov. 2018 a las 22:57, Samuel Thibault
() escribió:
>
> Michael Biebl, le dim. 04 nov. 2018 21:55:58 +0100, a ecrit:
> > Am 04.11.18 um 18:48 schrieb Samuel Thibault:
> >
> > > Additionally, the attached patch is needed since lsof is non available
> > > on non-linux.
> >
> > Is lsof not available at all or just provided by a different package?
>
> It doesn't seem to be provided by any package on Hurd and kFreeBSD.
>
> Samuel
>

Bug#887637: rsyslog-gnutls: TLS server does not send intermediate certificates, breaking verification

[Rainer Gerhards]

Arne,

Rainer from upstream here. Thanks for the patch. I will see that I can
integrate it into upstream source.

Question, due to GDPR: is it OK for you to be set as the author inside
git? If so, that means we can not remove your personal information at
a later time as this would break the master branch. If you do not like
this, I can commit anonymously.

More info available here:
https://github.com/rsyslog/rsyslog/blob/master/CONTRIBUTING.md

Rainer

2018-01-22 11:25 GMT+01:00 Arne Nordmark :
> On Thu, 18 Jan 2018 16:27:35 +0100 Arne Nordmark 
> wrote:
>>
>> gtlsLoadOurCertKey() uses gnutls_x509_crt_import() on the file data, and
>> this function only handles one cert.
>>
>
> If one uses gnutls_x509_crt_list_import() instead, intermediate certs could
> be supported. With the attached patch,
> the server sends all certificates in the file.
>
> Arne
>
>
>

Bug#861386: [rsyslog] Bug#861386: default configuration puts PID in wrong database column (syslogtag)

[Rainer Gerhards]

2017-04-28 12:25 GMT+02:00 Daniel Pocock :
>
>
> On 28/04/17 12:16, Michael Biebl wrote:
>> Control: tags -1 + moreinfo
>>
>> Am 28.04.2017 um 11:51 schrieb Daniel Pocock:
>>> Package: rsyslog-pgsql Version: 8.24.0-1 Severity: important
>>>
>>> I've observed this problem on both jessie (8.4.2-1+deb8u2) and
>>> stretch (8.24.0-1)
>>>
>>> I installed the package:
>>>
>>> apt-get install postgresql rsyslog-pgsql
>>>
>>> and agreed to let dbconfig-common set up the database.
>>>
>>> I restart the daemon:
>>>
>>> systemctl restart rsyslog
>>>
>>> Then I went to look at the table with loganalyzer[1] and I
>>> noticed the PID values in the tag column in the GUI.
>>>
>>> Looking in the database, I found the data is bad, rsyslog is not
>>> doing the correct INSERT:
>>>
>>>
>>> select distinct syslogtag from SystemEvents;
>>>
>>>
>>>
>>> syslogtag - sshd[9127]: cron[582]:
>>> sshd[15202]: sshd[15298]: sshd[15071]: sshd[15279]: sshd[15116]:
>>> rsyslogd-2007: sshd[15114]: CRON[26002]: CRON[28224]:
>>> sshd[9150]: postfix/smtpd[26154]: sshd[15207]: CRON[11434]:
>>> CRON[28163]: sshd[9398]: CRON[28103]:
>>>
>>
>> I'm not sure that's a bug, see
>> https://www.ietf.org/rfc/rfc3164.txt:
>>
>> 5.3 Originating Process Information
>>
>> It has also been considered to be a good practice to include some
>> information about the process on the device that generated the
>> message - if that concept exists.  This is usually the process
>> name and process id (often known as the "pid") for robust
>> operating systems.  The process name is commonly displayed in the
>> TAG field. Quite often, additional information is included at the
>> beginning of the CONTENT field.  The format of "TAG[pid]:" -
>> without the quote marks - is common.
>>
>
> Using the square brackets for the PID is a clearly documented standard
> and the table has the separate column for it.
>
> Maybe there should be distinct columns for "full" tag and also for the
> extracted process name and PID?
>
> Or should processes reading this table, such as LogAnalyzer, be able
> to extract the PID?
>
> When I was using the MongoDB backend the PID was in a different column.
>
> Can anybody else in the rsyslog mailing list comment on this issue?

Well, syslogtag is syslogtag and so the contents is correct as far as I can see.

I think you can define a custom template for the insert, which
together with a schema modification should give you what you want?

Rainer
>
> Regards,
>
> Daniel
> ___
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
> sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T 
> LIKE THAT.

Bug#844914: rsyslog: FTBFS: Tests failures

[Rainer Gerhards]

2016-11-20 17:45 GMT+01:00 Michael Biebl <bi...@debian.org>:
> Am 20.11.2016 um 16:17 schrieb Rainer Gerhards:
>> Lucas found the right root cause: It looks like the preload lib is not
>> loaded on that platform. See
>> https://github.com/rsyslog/rsyslog/issues/1268
>
> I'm not sure. I can't reproduce the issue with a standard Debian
> /etc/hosts which contains separate lines for localhost and the hostname.

Well, the key point of the override library is that gethostname()
ALWAYS returns "", no matter how the system is configured. So if the
configured name is returned, the preload (or lib) did not work. I'd
outrule that the lib does not work, as it is ultra-small:

https://github.com/rsyslog/rsyslog/blob/master/tests/override_gethostname.c

Any suggestion of what may be wrong with the test tooling is appreciated.

Rainer
>
> I'm able to reproduce the failing test if I modify /etc/hosts to have
> 127.0.0.1 foo localhost
>
> The library seems to be loaded in both cases.
>
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>

Bug#844914: rsyslog: FTBFS: Tests failures

[Rainer Gerhards]

Lucas found the right root cause: It looks like the preload lib is not
loaded on that platform. See
https://github.com/rsyslog/rsyslog/issues/1268

I can modify the test so that it is skipped if the preload fails, but
I wonder why this happens in the first place (and if there is a better
solution that skipping).

Rainer

2016-11-20 14:18 GMT+01:00 Michael Biebl :
> Am 20.11.2016 um 08:50 schrieb Lucas Nussbaum:
>> 
>> Test: ./empty-hostname.sh
>> 
>> rsyslogd started with pid  71369
>> imdiag[13500]: mainqueue empty
>> expected hostname "localhost" not found in logs, rsyslog.out.log is:
>> 2016-11-18T23:01:17.942712+00:00 ip-172-31-8-210 rsyslogd: [origin 
>> software="rsyslogd" swVersion="8.23.0" x-pid="71369" 
>> x-info="http://www.rsyslog.com;] start
>> 2016-11-18T23:01:19.984583+00:00 ip-172-31-8-210 rsyslogd: [origin 
>> software="rsyslogd" swVersion="8.23.0" x-pid="71369" 
>> x-info="http://www.rsyslog.com;] exiting on signal 15.
>> FAIL empty-hostname.sh (exit status: 1)
>>
>> I can still reproduce the problem.
>
> It was hinted on IRC, that this build failure is triggered on AWS as
> /etc/hosts is configured differently there.
> A standard Debian setup has
>
> 127.0.0.1 localhost
> 127.0.1.1 
>
> whereas AWS uses
>
> 127.0.0.1  localhost
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>

Bug#800873: rsyslog: FTBFS due to failing tests

[Rainer Gerhards]

2015-10-05 0:38 GMT+02:00 Michael Biebl :
> Am 04.10.2015 um 14:43 schrieb Hilko Bengen:
>> Source: rsyslog
>> Version: 8.12.0-3
>> Severity: grave
>>
>> Building rsyslog on a freshly created sid chroot on barriere.debian.org
>> fails with two tests failing:
>>
>> FAIL: mmnormalize_variable.sh
>> FAIL: mmnormalize_tokenized.sh
>>
>> The build log (generated using dpkg-buildpackage -uc -us -b 2>&1 | tee
>> build.log) and the list of packages that were installed into the chroot
>> are attached.
>
> that's most likely due to the latest upstream release of liblognorm to 1.1.2

Some more background:

https://github.com/rgerhards/rsyslog/commit/8ed77f62b3a80f3c1863e95e4f2c94d98f8cab28

We are looking into the mmnormalize_variable.sh tests, it's failure
may actually be a rsyslog problem.

Rainer

Bug#745904: rsyslogd-2068: could not load module '/usr/lib/rsyslog/lmnsd_gtls.so', rsyslog error -2078

[Rainer Gerhards]

I have changed the error (message) handling:

https://github.com/rsyslog/rsyslog/commit/20d8a9904e95aff4390d044ab35c4722c8893676

Note the commit comments on why this change may cause problems. As such,
it's done to the development version, only (8.5.0).

Rainer


On Thu, Aug 21, 2014 at 2:52 PM, Edy Corak e...@loenshotel.de wrote:

 On Do, Aug 21, 2014 13:04:48, Michael Biebl wrote:

  Am 21.08.2014 10:28, schrieb Edy Corak:
   I have now found the problem. Sorry, that was my mistake.
  
   The certificate has been updated and because the server was not
 rebooted long time, I got the error not noticed.
   After a reboot, just this error message appears in the log files.
   Perhaps it is possible to specify the error message, so that the error
 is easier to see ?
 
  Have you also tried to run it in debug mode (-d)?
  If you also didn't get a proper error message this way, please file a
  bug upstream [1] and report back with the bug number.
 
 
  Michael
 
 
  [1] http://bugzilla.adiscon.com/
  --
  Why is it that all of the instruments seeking intelligent life in the
  universe are pointed away from Earth?
 
 Hi,

 I have try the debug mode (-d). The path was changed to non existing, to
 see what error message will be shown.
 Only at the start in debug mode (-d) there is following message:

 unexpected GnuTLS error -64 in nsd_gtls.c:583: Error while reading file.
 Called LogError, msg: could not load module
 '/usr/lib/rsyslog/lmnsd_gtls.so', rsyslog error -2078

 And later there is only the last one about could not load module

 Called LogError, msg: could not load module
 '/usr/lib/rsyslog/lmnsd_gtls.so', rsyslog error -2078

 When I start rsyslogd with (-c5 -d) there is only one message

 rsyslogd-2068: could not load module '/usr/lib/rsyslog/lmnsd_gtls.so',
 rsyslog error -2078 [try http://www.rsyslog.com/e/2068 ]

 Maybe this can be changed to show always the complete error message.

 I missed the error message at the beginning in debug mode (-d).

 But now it's ok, everything works like it should.

 Thanks for your help

 Best regards

 Edy Corak

Bug#760372: [Pkg-monitoring-maintainers] Bug#760372: loganalyzer: CVE-2014-6070

[Rainer Gerhards]

Andre just went to vacation, but to the best of my knowledge he worked with
the reporter and has released a new version to address this issue.

Rainer


On Wed, Sep 3, 2014 at 1:11 PM, Daniel Pocock dan...@pocock.pro wrote:



 Hi Rainer, Andre,

 Could you please comment on this security report?

 Is the current Debian package affected?

 Regards,

 Daniel


 On 03/09/14 13:04, Salvatore Bonaccorso wrote:
  Source: loganalyzer
  Version: 3.6.5+dfsg-7
  Severity: important
  Tags: security upstream fixed-upstream
 
  Hi,
 
  the following vulnerability was published for loganalyzer. But I was
  not yet able to verify the vulnerability, but it is said to be fixed
  in 3.6.6 upstream.
 
  CVE-2014-6070[0]:
  Syslog LogAnalyzer persistent XSS injection
 
  If you fix the vulnerability please also make sure to include the
  CVE (Common Vulnerabilities  Exposures) id in your changelog entry.
 
  For further information see:
 
  [0] https://security-tracker.debian.org/tracker/CVE-2014-6070
  [1] http://seclists.org/fulldisclosure/2014/Sep/17
  [2] http://loganalyzer.adiscon.com/downloads/
 
  Regards,
  Salvatore
 
  ___
  Pkg-monitoring-maintainers mailing list
  pkg-monitoring-maintain...@lists.alioth.debian.org
 
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-monitoring-maintainers

Bug#760390: rsyslogd fails to start

[Rainer Gerhards]

FYI: json-c has broken it's API in recent versions. rsyslog does a
configure check and uses the proper API, e.g. here:

https://github.com/rsyslog/rsyslog/blob/master/runtime/msg.c#L4077

So this sounds to me like the version of json-c used for compilation does
not match the version that's present on the system.

Rainer


On Wed, Sep 3, 2014 at 5:25 PM, Michael Biebl bi...@debian.org wrote:

 Am 03.09.2014 17:18, schrieb Daniel Bruce:
  Package: rsyslog
  Version: 8.4.0-2
  Severity: important
 
  rsyslogd fails to start with the following error:
  root@dbruce-desktop:~# /usr/sbin/rsyslogd -c3 -f /etc/rsyslog.alt.conf
 -i /var/run/rsyslog.alt.pid -4
  /usr/sbin/rsyslogd: symbol lookup error: /usr/sbin/rsyslogd: undefined
 symbol: json_tokener_errors

 Can you send me the output of
 ldd /usr/sbin/rsyslogd


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

Bug#630025: rsyslog-mysql: ommysql inserts leading space into 'Message'-column

[Rainer Gerhards]

Sent from phone, thus brief.
Am 20.08.2014 20:27 schrieb Michael Biebl bi...@debian.org:

 Hi Johann,

 Am 10.06.2011 14:25, schrieb Johann Hartwig Hauschild:
  Package: rsyslog-mysql
  Version: 4.6.4-2
  Severity: normal
  Tags: upstream
 
 
  ommysql does not strip leading spaces from the system log.
  This is not really practical as it essentially forces users to select
using
  LIKE '%$SEARCHTERM', making SELECTS somehow more expensive than they
could
  be.

 Sorry for the late reply.
 Can you still reproduce the problem on an up-to-date wheezy or sid system?

I guess so. We do not try to strip leading spaces and most logs have at
least one due to rfc3164 definitions.

So this sounds like a feature request to me.

Rainer

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

Bug#729582: Should recommen 8514 as tls port

[Rainer Gerhards]

On Tue, Mar 18, 2014 at 4:56 PM, Michael Biebl bi...@debian.org wrote:

 Am 14.11.2013 16:23, schrieb Guido Günther:
  Package: rsyslog-gnutls
  Severity: wishlist
 
  Hi,
  It seems we currently doesn't make any recommendations concerning ports
  for syslog-tls usage. RFC 5425 uses 8514 - should we add something like
  this as a (commented out) rsyslog.d/tls snippet?

 Makes sense, I guess. That said, looking at my /etc/services, I get
 syslog-tls  6514/tcp   # Syslog over TLS [RFC5425]


I just checked, 6514 is the iana-assigned one [1]. Where have you seen 8514?


 Rainer, what's your take on this as upstream? Should e.g. [0] be updated
 accordingly? You seem to recommend port 514.


Will check tomorrow. That was probably before the IANA assignment was there
and as such should be corrected.


 So now I'm a bit confused :-)


 Once we have determined, what the actual recommended port is, I might
 consider adding a debian/rsyslog-gnutls.README.Debian.
 Want to help me write a short README how to setup a basic configuration


short and TLS does not play well. Actually [0] you quoted IMHO just has
the bare basic facts, so I think it's the shortest one that can be written
without causing confusion. Especially the cert generation process must be
followed exactly, else there are a myriad of problems.

Maybe someone with better writing skills than me can trim it down...

Rainer
[1]
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=syslog


 and with a recommendation for the port?

 [0] http://www.rsyslog.com/using-tls-with-relp/
 --
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?

Bug#740869: template seems to be mandatory now for ommongodb

[Rainer Gerhards]

I think this was a bug fixed in the last 4 weeks or so...

Rainer

Sent from phone, thus brief.
Am 05.03.2014 18:54 schrieb Daniel Pocock dan...@pocock.pro:

 Package: rsyslog-mongodb
 Version: 7.4.4-1~bpo70+1


 If I try the configuration samples from README.Debian, it just logs an
 error to /var/log/syslog


 rsyslogd-2207: error during parsing file /etc/rsyslog.conf, on or before
 line 124: parameter 'template' required but not specified - fix config
 [try http://www.rsyslog.com/e/2207 ]


 The provided URL is not helpful

 Manually declaring a template and action like this seems to generate
 entries to mongodb:

 # Load the module
 $ModLoad ommongodb

 # declare a template called BSON:
 template(name=BSON type=string string=\sys\ : \%hostname%\,
 \time\ : \%timereported:::rfc3339%\, \time_rcvd\ :
 \%timegenerated:::rfc3339%\, \msg\ : \%msg%\, \syslog_fac\ :
 \%syslogfacility%\, \syslog_sever\ : \%syslogseverity%\,
 \syslog_tag\ : \%syslogtag%\, \procid\ : \%programname%\,
 \pid\ : \%procid%\, \level\ : \%syslogpriority-text%\)

 # declare an action using the BSON template:
 *.*action(type=ommongodb server=127.0.0.1 db=logs
 collection=syslog template=BSON)


 Now I can see entries in mongodb:

 $ mongo
 MongoDB shell version: 2.0.6
 connecting to: test
  use logs
 switched to db logs
  db.syslog.find()

Bug#703429: FTBFS on !Linux: debug.c:309:22: error: 'SYS_gettid' undeclared

[Rainer Gerhards]

On Tue, 2013-03-19 at 15:28 +0100, Michael Biebl wrote:
 Source: rsyslog
 Version: 7.3.8-1
 Severity: serious
 
 Current version of rsyslog from experimental FTBFS on kfreebsd [1]
 
 
 debug.c: In function 'dbgOutputTID':
 debug.c:309:22: error: 'SYS_gettid' undeclared (first use in this function)
 debug.c:309:22: note: each undeclared identifier is reported only once for 
 each function it appears in
 make[3]: *** [librsyslog_la-debug.lo] Error 1
 make[3]: Leaving directory 
 `/build/buildd-rsyslog_7.3.8-1-kfreebsd-amd64-1l58ej/rsyslog-7.3.8/runtime'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory 
 `/build/buildd-rsyslog_7.3.8-1-kfreebsd-amd64-1l58ej/rsyslog-7.3.8'
 make[1]: *** [all] Error 2
 make[1]: Leaving directory 
 `/build/buildd-rsyslog_7.3.8-1-kfreebsd-amd64-1l58ej/rsyslog-7.3.8'
 dh_auto_build: make -j1 returned exit code 2
 make: *** [build-arch] Error 2

I think it is rsyslog's fault here. I probably do no correctly check for
the availablity of gettid. Will look into that soon (it's minor
debug-aid functionality which can be disabled without any issues, even
during debugging).

Rainer

Bug#703429: FTBFS on !Linux: debug.c:309:22: error: 'SYS_gettid' undeclared

[Rainer Gerhards]

Michael,

On Tue, 2013-03-19 at 14:35 +, Rainer Gerhards wrote:
 I think it is rsyslog's fault here. I probably do no correctly check for
 the availablity of gettid. Will look into that soon (it's minor
 debug-aid functionality which can be disabled without any issues, even
 during debugging).
This patch should fix the issue:
http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=aef0be0c1799fbb20955fc1dc014cb9c9772af88

I would appreciate if you could give it a try. Will be included in
7.3.9.

Rainer

Bug#688889: Dropping privileges by default

[Rainer Gerhards]

 As for the implementation, using the same uid/gid as Ubuntu (which has
 been using this feature for while) seems reasonable.

You need to be aware that other packages, most importantly logrotate, need to 
be modified. The Ubuntu setup is notoriously known to break things, especially 
when users work with dynafiles. There is at least one complaint ever two month 
on the rsyslog mailing list and there are some long-standing bugs reported to 
Ubuntu (sorry, I don't have the bug tracker ID at hand).

Note that pre-v6 rsyslog engines do NOT have solid support for dropping 
privileges. So you need to test things very carefully if you use pre-v6.

Rainer


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688889: Dropping privileges by default

[Rainer Gerhards]

  As for the implementation, using the same uid/gid as Ubuntu (which
 has
  been using this feature for while) seems reasonable.
 
  You need to be aware that other packages, most importantly logrotate,
 need to be modified. The Ubuntu setup is notoriously known to break
 things, especially when users work with dynafiles. There is at least
 one complaint ever two month on the rsyslog mailing list and there are
 some long-standing bugs reported to Ubuntu (sorry, I don't have the bug
 tracker ID at hand).
 
 Yeah, as I wrote, logrotate is something which needs to be checked.
 
  Note that pre-v6 rsyslog engines do NOT have solid support for
 dropping privileges. So you need to test things very carefully if you
 use pre-v6.
 
 Good to know.
 I don't plan to have this feature for wheezy anyway (which will contain
 5.8.x) but do that earliest in wheezy+1 where I will update rsyslog to
 a
 more current version, probably 7.x.

That's an excellent idea. V7 fully supports privilege dropping and has the 
necessary design to do it cleanly. With v6, that's also the case, but v6 is 
more or less meant for folks who want a (basically) v5 engine plus the new 
config language. I am working hard to mature v7, which will also include all 
the structured logging support that will become important. Some big users help 
with testing to get it stable quickly.

Rainer

PS: sorry for the line breaks - my company has changed mail backends and the 
admins are still working on fixing this...


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#651529: rsyslog: FTBFS on hurd-i386

[Rainer Gerhards]

 While that could be the easy way out, it would definitely be wrong.
 Such limits can be OS or filesystem specific, if at all. They do not even
 represent reality on GNU/Linux! Try this:

I try to stay out of these politics, but I found it beneficial to remove the
dependency on MAX_PATH. It actually solved two error conditions that
otherwise could occur (not sure if the dlopen call will fail in these cases,
though). At least the code got smaller.

I have enhanced v5-devel, patch is available here:

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=01c7c9ffc6771f73df9ee0bc
18e30534d6c6974c

I would appreciate if you could have a look at it; the pointer arithmetic is
obviously easy to get wrong.

Thanks,
Rainer



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#651529: rsyslog: FTBFS on hurd-i386

[Rainer Gerhards]

 Good that you took the time to change the code, I'm currently working on
 completing the dynamic allocation solution. 

It's important to note that I used the chance to refactor the code a bit, so
the logic is slightly different. When you read the code, note that I use a
stack-based fixed size buffer as long as it is sufficient and go to dyn
alloced memory only if necessary. I guess dyn alloc will never happen in
practice (but I tested under valgrind control and it looks rather well).

 I'll take a look at your changes,
 thank you. If Guillem is happy with your changes, let's settle with your
 solution.
 
 I have some more issues now when the package is building on GNU/Hurd,
 one is the configuration file. Is it OK to submit another bug report to the
 Debian bug data base? Or do you want me to contact the development list (if
 it exists) or you directly?

We have a bugzilla at http://bugzilla.adiscon.com and the mailing list is at
http://lists.adiscon.net/mailman/listinfo/rsyslog 

Which way you use doesn't really matter to me, I am fine with either way.
Just note that anything that is related to the packaging is not touched by
me. I follow the debian bug tracker and try to pull out things that I can
address. Michael does a great job to remind me if I overlook things (what
happens...).  Just be warned that I will soon leave for xmas vacation and I
have a big bunch of things in front of me, so I will probably not be able to
change anything before I leave.

Rainer

Bug#651529: rsyslog: FTBFS on hurd-i386

[Rainer Gerhards]

  We have a bugzilla at http://bugzilla.adiscon.com and the mailing list
  is at http://lists.adiscon.net/mailman/listinfo/rsyslog
 
  Which way you use doesn't really matter to me, I am fine with either way.
  Just note that anything that is related to the packaging is not
  touched by me. I follow the debian bug tracker and try to pull out
  things that I can address. Michael does a great job to remind me if I
  overlook things (what happens...).
 
 Of course, I know packaging issues are not touched by upstream, so the
 configuration/startup scripts are Debian specific, right? 

Yes

 Then, I'll file a Debian
 bug for /etc/init.d/rsyslog. Another issue is about writing a Hurd-specific
 plugin file: plugins/imklog/gnu.c. However, this is not an urgent matter so
it
 can wait until later. Thanks!


Definitely interested in that if the regular one has problems.

 
  Just be warned that I will soon leave for xmas vacation and I have a
  big bunch of things in front of me, so I will probably not be able to
  change anything before I leave.
 
 I wish you a Merry Christmas then :)
Same to you ;)

Rainer

Bug#618828: Processed: Bug#618828 reopen - rsyslog: /etc/rsyslog.d not documented in manual pages

[Rainer Gerhards]

The man pages are actually not well-suited to convey the wealth of
information included in the html doc. However, I would definitely not object
a well-done patch which duplicates some relevant info into the man page.

Rainer

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Tuesday, March 29, 2011 2:45 PM
 To: Jari Aalto; 618...@bugs.debian.org
 Cc: cont...@bugs.debian.org
 Subject: Bug#618828: Processed: Bug#618828 reopen - rsyslog: /etc/rsyslog.d
 not documented in manual pages
 
 severity 618828 wishlist
 thanks
 
 I don't plan to duplicate the existing documentation.
 Feel free though to send a patch (upstream).
 
 
 
 --
 Why is it that all of the instruments seeking intelligent life in the
universe are
 pointed away from Earth?




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#617996: rsyslog: remote syslog messages not logged

[Rainer Gerhards]

Hi Micheal,

thanks for the patch. I'll think a bit more about this. Of course, it seems
only reasonable to merge it. However, it is a very partial fix for a very
specific problem. If, for example, Phil had used TCP syslog instead of UDP
syslog, the patch would not have helped. So it is very specific to one input.
Providing the same for TCP, I think, is quite  more complicated (but I may be
wrong).

I understand you point that we should not try to proactively fix things. On
the other hand, I wonder how realistic it is that we run into the same
situation at all. If it is, and if that really is an issue, then I think we
must evaluate the other obvious cases. We can't simply ignore that problem
potential if there is a real use case behind it.

This is what I am concerned about. Any thoughts?

Rainer

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Monday, March 14, 2011 4:14 AM
 To: Phil Dibowitz; 617...@bugs.debian.org
 Cc: Rainer Gerhards
 Subject: Re: Bug#617996: rsyslog: remote syslog messages not logged
 
 Am 14.03.2011 01:08, schrieb Phil Dibowitz:
  On 03/13/2011 04:15 AM, Michael Biebl wrote:
  Attached is a very simple (though untested) patch, which imho
 doesn't really
  complicate the code.
 
  Phil, could you please try that patch. Compile it using your new
 kernel, test
  rsyslog using your new kernel, the boot the old kernel again and see
 if it still
  works correctly.
 
  Tested, works great, thanks!!
 
 
 Rainer, in case you decide to merge this patch, here is one with a
 proper commit
 header which can be applied using git am.
 
 Cheers,
 Michael
 
 --
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#617996: rsyslog: remote syslog messages not logged

[Rainer Gerhards]

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Monday, March 14, 2011 8:51 AM
 To: Rainer Gerhards
 Cc: Phil Dibowitz; 617...@bugs.debian.org
 Subject: Re: Bug#617996: rsyslog: remote syslog messages not logged


 If you mean the imptcp module, I've updated all occurences of
 epoll_create1() I
 found in the code, that includes imptcp. This particular issue is about
 epoll_create1(), nothing else, so I'm not sure why you think that TCP
 syslog
 would be affected and this is only a partial fix. Could you elaborate?

Let me check the code soon. Imtcp uses the netstream drivers, and the
netstream driver layer uses epoll as well. So the nsdsel_pctp driver should
have issues, too, in this environment.

But I have to admit that I thought we need to fallback to select (maybe I am
bit too much detracted by the development in Japan, which really concerns
me...).

Rainer



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#617996: rsyslog: remote syslog messages not logged

[Rainer Gerhards]

 Nah, it's just about the fallback from epoll_create1 to epoll_create.
 
 epoll_create was introduced in 2.5.44 and finalized in 2.5.66.
 So we can pretty much rely on that :-)

Michael, you are very convincing (plus I seem to be blind, 'cause you already
wrote that in the patch description ;)). I am right now merging...

Rainer



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#617996: rsyslog: remote syslog messages not logged

[Rainer Gerhards]

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Sunday, March 13, 2011 11:22 AM
 To: Phil Dibowitz; 617...@bugs.debian.org; Rainer Gerhards
 Cc: cont...@bugs.debian.org
 Subject: Re: Bug#617996: rsyslog: remote syslog messages not logged
 
 retitle 617996 remote syslog broken on kernels without epoll support
 severity 617996 normal
 thanks
 
 Am 13.03.2011 11:06, schrieb Phil Dibowitz:
  On 03/13/2011 01:51 AM, Michael Biebl wrote:
  Ever since the 5.7 upgrade which I installed on 2/20, my rsyslog
 hasn't been
  logging messages from remote sources. This started on the 5.7.4-1
 package and
  has continued with 5.7.4-2, 5.7.5-1, 5.7.6-1, and 5.7.8-1.
 
  Just to clarify this: What was the last version that you tested and
 that worked
  for you?
 
  The machine runs sid and does an 'apt-get update  apt-get upgrade'
 every
  night. The last version that worked from the dpkg logs was 4.6.4-2.
 
  According to the upstream changelog, epoll support in the netstream
 drivers was
  implemented in 5.5.1, the first v5 version shipped in Debian was
 5.7.1-1
 
  That would make sense, sid skipped straight from 4.6.x to 5.7.x,
 afaict.
 
  OK, machine just finished rebooting - looks like that fixed it.
 Thanks!
 
 So, a combination of lenny kernel + wheezy rsyslog is not correctly
 working,
 whereas squeeze kernel + wheezy rsyslog will.
 2-releases old kernels are not really supported in Debian, we do our
 best to
 support the kernel from the last release.
 
 That said, it is still a bug, but I downgraded it to normal and
 retitled it.
 
 Rainer, the epoll usage in rsyslog should apply runtime checks when
 using epoll
 and fall back gracefully. the following was suggested in a similar
 situation [1]:

Mmm... Is that really something we need to support? I can think of many
other places where the code relies on the outcome of configure. If I need to
redo all (well: some of) the configure checks at runtime, the codebase gets
really complicated and probably hard to maintain.

So far, I assumed that the configure checks are sufficient to build the code.

Wouldn't it then be better to just disable epoll support in the regularly
distributed version and only have it activated for folks that build the code
for a specific environment? That sounds much more clean to me (it has a
price, of course, but if we want to support very old systems at all costs, we
need to pay a price...).

Rainer




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#614061: rsyslog-mysql: You have an error in your SQL syntax; check the manual ...

[Rainer Gerhards]

Just for your information: I have begun to work on this issue and suspect it
is an regression from the imuxsock changes. However, I have unfortunately not
yet been able to reproduce it (but I could not yet try on Debian 6, will do
that shortly). However, I created a new instrumented v5-beta-mysql-test gt
branch and Michael is helping me try it out.

Rainer

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Monday, February 21, 2011 2:04 PM
 To: Rainer Gerhards; 614...@bugs.debian.org
 Cc: cont...@bugs.debian.org; Florian Ernst
 Subject: Re: Bug#614061: rsyslog-mysql: You have an error in your SQL
 syntax; check the manual ...
 
 tags 6144061 confirmed
 thanks
 
 Hi Rainer,
 
 Here's another v5 specific problem.
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614061
 
 Am 20.02.2011 09:06, schrieb Florian Ernst:
  On Sat, Feb 19, 2011 at 10:46:27PM +0100, Michael Biebl wrote:
  Am 19.02.2011 13:14, schrieb Florian Ernst:
  since updating to 5.7.3-1 rsyslog-mysql apparently fails to
  correctly parse / escape some strings.
 
  Could you please post such example strings?
 
  The type of string that led me to noticing this bevavior was included
  in my original report: the spamd line is the triggering line, the
  following line is the rsyslog db error message.
  So far this error only occured on my system with these spamd lines.
 
  Running rsyslog in debug mode might help to track this issue down, too:
  Run
  rsyslogd -c5 -dn
  for this and attach the output to the bug report.
 
  Attached, but I replaced my DB password with ReplacedPassword.
 
 
 
 
 A debug log is at
 http://bugs.debian.org/cgi-
 bin/bugreport.cgi?msg=15;filename=rsyslog.log;att=1;bug=614061
 
 I can reproduce the problem here, so if you need more information/testing,
 just let me know.
 --
 Why is it that all of the instruments seeking intelligent life in the
universe are
 pointed away from Earth?

Bug#614061: rsyslog-mysql: You have an error in your SQL syntax; check the manual ...

[Rainer Gerhards]

Thanks to Michael Biebl, I was able to nail down the problem. Spamd seems to
write NUL-Bytes (0x00, '\0') into the system log. The new imuxsock has a
regression in that it no longer does the escaping (including check for
NUL-Bytes) that previously happened. I'll now re-enable the escaping code. It
may take a little while because I must carefully evaluate how much I would
like to change (a totally clean solution may have a lot of potential for new
regressions, so I may move this effort to a new devel version instead).

As a side-note, one may think if it is valid that spamd writes these
NUL-Bytes. While this is obviously a problem in rsyslogd in the first place,
I wonder if it were wiser not to write them.

Rainer

 -Original Message-
 From: Rainer Gerhards [mailto:rgerha...@hq.adiscon.com]
 Sent: Tuesday, February 22, 2011 9:42 AM
 To: Michael Biebl; 614...@bugs.debian.org
 Cc: cont...@bugs.debian.org; Florian Ernst
 Subject: Bug#614061: rsyslog-mysql: You have an error in your SQL syntax;
 check the manual ...
 
 Just for your information: I have begun to work on this issue and suspect
it is
 an regression from the imuxsock changes. However, I have unfortunately
 not yet been able to reproduce it (but I could not yet try on Debian 6,
will do
 that shortly). However, I created a new instrumented v5-beta-mysql-test gt
 branch and Michael is helping me try it out.
 
 Rainer
 
  -Original Message-
  From: Michael Biebl [mailto:bi...@debian.org]
  Sent: Monday, February 21, 2011 2:04 PM
  To: Rainer Gerhards; 614...@bugs.debian.org
  Cc: cont...@bugs.debian.org; Florian Ernst
  Subject: Re: Bug#614061: rsyslog-mysql: You have an error in your SQL
  syntax; check the manual ...
 
  tags 6144061 confirmed
  thanks
 
  Hi Rainer,
 
  Here's another v5 specific problem.
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614061
 
  Am 20.02.2011 09:06, schrieb Florian Ernst:
   On Sat, Feb 19, 2011 at 10:46:27PM +0100, Michael Biebl wrote:
   Am 19.02.2011 13:14, schrieb Florian Ernst:
   since updating to 5.7.3-1 rsyslog-mysql apparently fails to
   correctly parse / escape some strings.
  
   Could you please post such example strings?
  
   The type of string that led me to noticing this bevavior was
   included in my original report: the spamd line is the triggering
   line, the following line is the rsyslog db error message.
   So far this error only occured on my system with these spamd lines.
  
   Running rsyslog in debug mode might help to track this issue down,
too:
   Run
   rsyslogd -c5 -dn
   for this and attach the output to the bug report.
  
   Attached, but I replaced my DB password with ReplacedPassword.
  
 
 
 
  A debug log is at
  http://bugs.debian.org/cgi-
  bin/bugreport.cgi?msg=15;filename=rsyslog.log;att=1;bug=614061
 
  I can reproduce the problem here, so if you need more
  information/testing, just let me know.
  --
  Why is it that all of the instruments seeking intelligent life in the
 universe are
  pointed away from Earth?

Bug#612829: no longer cleans up trailing whitespace

[Rainer Gerhards]

I just fixed this issue, it was a regression of the recent changes to
imuxsock as I thought.

Fixed with commit 

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;=026f59388a105597c3c6890bb
0c83652cb712903

To be released with 5.7.5, 6.1.5.

Thanks again for reporting this bug. It was a really nasty one.

Rainer

 -Original Message-
 From: Rainer Gerhards
 Sent: Monday, February 21, 2011 8:41 AM
 To: Rainer Gerhards; 612...@bugs.debian.org; Michael Biebl
 Cc: Romain Francoise
 Subject: RE: Bug#612829: no longer cleans up trailing whitespace
 
 I could reproduce the problem. It seems to be a regression of the new
 imuxsock code. TCP and UDP are not affected, but the local log socket.
 
 Rainer
 
  -Original Message-
  From: Rainer Gerhards [mailto:rgerha...@hq.adiscon.com]
  Sent: Monday, February 21, 2011 7:43 AM
  To: Michael Biebl; 612...@bugs.debian.org
  Cc: Romain Francoise
  Subject: Bug#612829: no longer cleans up trailing whitespace
 
  Thanks for the time reporting this bug. This definitely doesn't sound
  correct. Rsyslog shall remove one trailing LF, not many. But given
 the
  new
  appearance of the problem, I assume there is a problem with removing
  that one
  whitespace.
 
  I have added an upstream bug tracker:
 
  http://bugzilla.adiscon.com/show_bug.cgi?id=224
 
   -Original Message-
   From: Michael Biebl [mailto:bi...@debian.org]
   Sent: Saturday, February 12, 2011 3:47 AM
   To: 612...@bugs.debian.org; Rainer Gerhards
   Cc: Romain Francoise
   Subject: Bug#612829: no longer cleans up trailing whitespace
  
   Hi Rainer,
  
   this is the first 5.7.x specfic bug report and I've CCed you as you
   were asking
   for feedback.
  
   Could you please take a look?
  
   Thanks,
   Michael
   On 10.02.2011 23:58, Romain Francoise wrote:
Package: rsyslog
Version: 5.7.3-1
Severity: normal
   
Before version 5.7.3-1 rsyslog used to clean up any extra
  whitespace
present at eol, and it apparently no longer does. For example,
  smartd
   is
one of the few applications which add an extra newline, before
   today's
upgrade my logs looked like this:
   
| Feb 10 12:30:05 silenus smartd[2691]: Device: /dev/sdd [SAT],
  SMART
   Usage Attribute: 194 Temperature_Celsius changed from 28 to 29
| Feb 10 19:00:05 silenus smartd[2691]: Device: /dev/sda [SAT],
  SMART
   Usage Attribute: 194 Temperature_Celsius changed from 30 to 31
| Feb 10 19:00:05 silenus smartd[2691]: Device: /dev/sdb [SAT],
  SMART
   Usage Attribute: 194 Temperature_Celsius changed from 28 to 29
   
and now they look like this:
   
| Feb 10 22:30:05 silenus smartd[2691]: Device: /dev/sdc [SAT],
  SMART
   Usage Attribute: 194 Temperature_Celsius changed from 32 to 31
|
| Feb 10 23:30:05 silenus smartd[2691]: Device: /dev/sda [SAT],
  SMART
   Usage Attribute: 194 Temperature_Celsius changed from 31 to 30
|
| Feb 10 23:30:05 silenus smartd[2691]: Device: /dev/sdb [SAT],
  SMART
   Usage Attribute: 194 Temperature_Celsius changed from 29 to 28
   
This is especially annoying because logcheck messages now include
   wads
of unnecessary blank lines as a result...
   
  
  
  
   --
   Why is it that all of the instruments seeking intelligent life in
 the
   universe are pointed away from Earth?
 
 
 




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#612829: no longer cleans up trailing whitespace

[Rainer Gerhards]

Let me (re)-check...

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Monday, February 21, 2011 10:22 AM
 To: Rainer Gerhards; 612...@bugs.debian.org
 Subject: Re: Bug#612829: no longer cleans up trailing whitespace
 
 Hi Rainer!
 
 Am 21.02.2011 09:15, schrieb Rainer Gerhards:
  I just fixed this issue, it was a regression of the recent changes to
  imuxsock as I thought.
 
  Fixed with commit
 
 
 http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;=026f59388a105597c3c
 6890bb
  0c83652cb712903
 
 
 I cherry-picked 026f59388a105597c3c6890bb0c83652cb712903  but now I
 get:
 
 # logger foobar
 # tail -n1 -f /var/log/messages
 Feb 21 10:13:55 pluto michael: fooba
 
 Note the missing 'r'
 
 --
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#612829: no longer cleans up trailing whitespace

[Rainer Gerhards]

Arghhh... Typo: = where == should be inside the if. I just committed the
fix.

I should really see that I add an automated test for this case to the
testbench...

Rainer

 -Original Message-
 From: Rainer Gerhards [mailto:rgerha...@hq.adiscon.com]
 Sent: Monday, February 21, 2011 11:37 AM
 To: Michael Biebl; 612...@bugs.debian.org
 Subject: Bug#612829: no longer cleans up trailing whitespace
 
 Let me (re)-check...
 
  -Original Message-
  From: Michael Biebl [mailto:bi...@debian.org]
  Sent: Monday, February 21, 2011 10:22 AM
  To: Rainer Gerhards; 612...@bugs.debian.org
  Subject: Re: Bug#612829: no longer cleans up trailing whitespace
 
  Hi Rainer!
 
  Am 21.02.2011 09:15, schrieb Rainer Gerhards:
   I just fixed this issue, it was a regression of the recent changes
 to
   imuxsock as I thought.
  
   Fixed with commit
  
  
 
 http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;=026f59388a105597c3c
  6890bb
   0c83652cb712903
  
 
  I cherry-picked 026f59388a105597c3c6890bb0c83652cb712903  but now I
  get:
 
  # logger foobar
  # tail -n1 -f /var/log/messages
  Feb 21 10:13:55 pluto michael: fooba
 
  Note the missing 'r'
 
  --
  Why is it that all of the instruments seeking intelligent life in the
  universe are pointed away from Earth?
 
 
 




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#612829: no longer cleans up trailing whitespace

[Rainer Gerhards]

Thanks for the time reporting this bug. This definitely doesn't sound
correct. Rsyslog shall remove one trailing LF, not many. But given the new
appearance of the problem, I assume there is a problem with removing that one
whitespace.

I have added an upstream bug tracker:

http://bugzilla.adiscon.com/show_bug.cgi?id=224

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Saturday, February 12, 2011 3:47 AM
 To: 612...@bugs.debian.org; Rainer Gerhards
 Cc: Romain Francoise
 Subject: Bug#612829: no longer cleans up trailing whitespace
 
 Hi Rainer,
 
 this is the first 5.7.x specfic bug report and I've CCed you as you
 were asking
 for feedback.
 
 Could you please take a look?
 
 Thanks,
 Michael
 On 10.02.2011 23:58, Romain Francoise wrote:
  Package: rsyslog
  Version: 5.7.3-1
  Severity: normal
 
  Before version 5.7.3-1 rsyslog used to clean up any extra whitespace
  present at eol, and it apparently no longer does. For example, smartd
 is
  one of the few applications which add an extra newline, before
 today's
  upgrade my logs looked like this:
 
  | Feb 10 12:30:05 silenus smartd[2691]: Device: /dev/sdd [SAT], SMART
 Usage Attribute: 194 Temperature_Celsius changed from 28 to 29
  | Feb 10 19:00:05 silenus smartd[2691]: Device: /dev/sda [SAT], SMART
 Usage Attribute: 194 Temperature_Celsius changed from 30 to 31
  | Feb 10 19:00:05 silenus smartd[2691]: Device: /dev/sdb [SAT], SMART
 Usage Attribute: 194 Temperature_Celsius changed from 28 to 29
 
  and now they look like this:
 
  | Feb 10 22:30:05 silenus smartd[2691]: Device: /dev/sdc [SAT], SMART
 Usage Attribute: 194 Temperature_Celsius changed from 32 to 31
  |
  | Feb 10 23:30:05 silenus smartd[2691]: Device: /dev/sda [SAT], SMART
 Usage Attribute: 194 Temperature_Celsius changed from 31 to 30
  |
  | Feb 10 23:30:05 silenus smartd[2691]: Device: /dev/sdb [SAT], SMART
 Usage Attribute: 194 Temperature_Celsius changed from 29 to 28
 
  This is especially annoying because logcheck messages now include
 wads
  of unnecessary blank lines as a result...
 
 
 
 
 --
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#612829: no longer cleans up trailing whitespace

[Rainer Gerhards]

I could reproduce the problem. It seems to be a regression of the new
imuxsock code. TCP and UDP are not affected, but the local log socket.

Rainer

 -Original Message-
 From: Rainer Gerhards [mailto:rgerha...@hq.adiscon.com]
 Sent: Monday, February 21, 2011 7:43 AM
 To: Michael Biebl; 612...@bugs.debian.org
 Cc: Romain Francoise
 Subject: Bug#612829: no longer cleans up trailing whitespace
 
 Thanks for the time reporting this bug. This definitely doesn't sound
 correct. Rsyslog shall remove one trailing LF, not many. But given the
 new
 appearance of the problem, I assume there is a problem with removing
 that one
 whitespace.
 
 I have added an upstream bug tracker:
 
 http://bugzilla.adiscon.com/show_bug.cgi?id=224
 
  -Original Message-
  From: Michael Biebl [mailto:bi...@debian.org]
  Sent: Saturday, February 12, 2011 3:47 AM
  To: 612...@bugs.debian.org; Rainer Gerhards
  Cc: Romain Francoise
  Subject: Bug#612829: no longer cleans up trailing whitespace
 
  Hi Rainer,
 
  this is the first 5.7.x specfic bug report and I've CCed you as you
  were asking
  for feedback.
 
  Could you please take a look?
 
  Thanks,
  Michael
  On 10.02.2011 23:58, Romain Francoise wrote:
   Package: rsyslog
   Version: 5.7.3-1
   Severity: normal
  
   Before version 5.7.3-1 rsyslog used to clean up any extra
 whitespace
   present at eol, and it apparently no longer does. For example,
 smartd
  is
   one of the few applications which add an extra newline, before
  today's
   upgrade my logs looked like this:
  
   | Feb 10 12:30:05 silenus smartd[2691]: Device: /dev/sdd [SAT],
 SMART
  Usage Attribute: 194 Temperature_Celsius changed from 28 to 29
   | Feb 10 19:00:05 silenus smartd[2691]: Device: /dev/sda [SAT],
 SMART
  Usage Attribute: 194 Temperature_Celsius changed from 30 to 31
   | Feb 10 19:00:05 silenus smartd[2691]: Device: /dev/sdb [SAT],
 SMART
  Usage Attribute: 194 Temperature_Celsius changed from 28 to 29
  
   and now they look like this:
  
   | Feb 10 22:30:05 silenus smartd[2691]: Device: /dev/sdc [SAT],
 SMART
  Usage Attribute: 194 Temperature_Celsius changed from 32 to 31
   |
   | Feb 10 23:30:05 silenus smartd[2691]: Device: /dev/sda [SAT],
 SMART
  Usage Attribute: 194 Temperature_Celsius changed from 31 to 30
   |
   | Feb 10 23:30:05 silenus smartd[2691]: Device: /dev/sdb [SAT],
 SMART
  Usage Attribute: 194 Temperature_Celsius changed from 29 to 28
  
   This is especially annoying because logcheck messages now include
  wads
   of unnecessary blank lines as a result...
  
 
 
 
  --
  Why is it that all of the instruments seeking intelligent life in the
  universe are pointed away from Earth?
 
 
 




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#536432: [rsyslog] Appending a timestamp to all log files

[Rainer Gerhards]

This sounds useful, at least for some use cases. However, this most probably
requires considerable changes to the config engine. And as this engine is
scheduled to be replaced, I don't like to touch it too much.

However, there may be one solution. We could declare something like if the
file name is defined as a template name, then make it a dynafile based on
that template.

Then, you would need to define templates e.g 

$template /var/log/messages,/var/log/messages_%$NoW%

And  those would automatically be converted. That seems to require relatively
few changes.

Would that help?

Rainer

 -Original Message-
 From: rsyslog-boun...@lists.adiscon.com [mailto:rsyslog-
 boun...@lists.adiscon.com] On Behalf Of martin f krafft
 Sent: Tuesday, February 01, 2011 8:36 PM
 To: da...@lang.hm
 Cc: rsyslog-users; 536...@bugs.debian.org
 Subject: Re: [rsyslog] Appending a timestamp to all log files
 
 also sprach da...@lang.hm da...@lang.hm [2011.02.01.1957 +0100]:
  rsyslog already has the include directive to include files (or all
  files in a directory)
 
  does this work for you? if not, what does it lack?
 
 Hello David,
 
 thanks for your time in writing back. Unfortunately, I think I was
 unclear about what I am trying to do.
 
 I am aware of the include directive. It has nothing to do with my
 goals.
 
 I am trying to tell rsyslog: hey, all files that you write, append the
 following suffix to their names!, or hey, all files that you write,
 run their names through this filter and use the output as actual
 filename!.
 
 I want this because it's a cleaner way to replace all hard-coded
 filenames with templated filenames, than to change every instance of a
 hard-coded filename.
 
 Am I making myself clearer now?
 
 --
 martin;  (greetings from the heart of the sun.)
   \ echo mailto: !#^.*|tr * mailto:; net@madduck
 
 logik ist analsadismus: gedanken werden gewaltsam durch einen engen
 gang gepreßt.
 -- frei nach lacan
 
 spamtraps: madduck.bo...@madduck.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#549168: RE: Bug#549168: rsyslog: consumes too much memory

[Rainer Gerhards]

Hi Derek,

have a look at our upstream bug tracker -- the issue finally got solved :)
New releases are being rolled out.

http://bugzilla.adiscon.com/show_bug.cgi?id=194

Rainer

 -Original Message-
 From: Dererk [mailto:der...@debian.org]
 Sent: Monday, November 29, 2010 10:27 PM
 To: Rainer Gerhards
 Cc: Plamen Tonev; 549...@bugs.debian.org
 Subject: Bug#549168: RE: Bug#549168: rsyslog: consumes too much memory
 
 On -10/01/37 16:59, Rainer Gerhards wrote:
  -Original Message-
  From: Plamen Tonev [mailto:pla...@tonev.net]
  Sent: Friday, November 05, 2010 10:45 PM
  To: 549...@bugs.debian.org
  Subject: Bug#549168: rsyslog: consumes too much memory
 
  I'm experiencing the same problem. The rsyslogd with gnutls enabled
 and
  1-2 minutes after start it is starting to use 100% CPU usage - until
  killed. It is some sort of infinite loop...the debug file is REALLY
  bigand obviously
  something is broken with rsyslog+gnutls.
  I was thinking that it was some RBAC restrtiction with my grsec
 kernel,
  but I have compiled clean vanilla 2.6.36 kernel - and surprisingly -
 it
  takes 100% CPU even without grsecurity restrictions.
 
  I am the rsyslog author. I just came across this very useful Debian
 bug
  report. I am tracking this issue for some while now in rsyslog's
 bugzilla
  under
 
  http://bugzilla.adiscon.com/show_bug.cgi?id=194
 
  A big problem is that I seem to be unable to reproduce the issue (but
 I will
  retry with the configs posted here, however, the look extremely
 similar to
  what I already use).
 
  Question now: would those of you who can reproduce it be willing to
 test a
  special version that I modify so that it contains some more
 instrumentation?
 
  From what I have seen so far, it looks that for some reason GnuTLS
 requires
  an operaton retry (something absolutely OK with TLS) but then seems
 to be
  unable to finish it. That leads to a retry loop. But I have very
 little
  insight into the situation and so any help is deeply appreciated.
 
  Thanks,
  Rainer
 
 Hi Rainer, pleased to meet you and thanks for replying on this thread
 :-)
 
 I can offer myself with a demo environment whenever you need it,
 although I must say It's really pretty straight forward to reproduce, I
 came across the same issue in two different times and completely
 different environments.
 
 Just for the sake of any random sailor to arrive at this lands, It
 would
 be much helpful if you don't mind dropping the steps/links required for
 you to debug.
 
 
 Please do let me know if you need anything else I could provide you
 with.
 
 
 Cheers,
 
 Dererk
 
 --
 BOFH excuse #306:
 CPU-angle has to be adjusted because of vibrations coming from the
 nearby road
 

Bug#549168: rsyslog: consumes too much memory

[Rainer Gerhards]

 -Original Message-
 From: Plamen Tonev [mailto:pla...@tonev.net]
 Sent: Friday, November 05, 2010 10:45 PM
 To: 549...@bugs.debian.org
 Subject: Bug#549168: rsyslog: consumes too much memory
 
 I'm experiencing the same problem. The rsyslogd with gnutls enabled and
 1-2 minutes after start it is starting to use 100% CPU usage - until
 killed. It is some sort of infinite loop...the debug file is REALLY
 bigand obviously
 something is broken with rsyslog+gnutls.
 I was thinking that it was some RBAC restrtiction with my grsec kernel,
 but I have compiled clean vanilla 2.6.36 kernel - and surprisingly - it
 takes 100% CPU even without grsecurity restrictions.

I am the rsyslog author. I just came across this very useful Debian bug
report. I am tracking this issue for some while now in rsyslog's bugzilla
under

http://bugzilla.adiscon.com/show_bug.cgi?id=194

A big problem is that I seem to be unable to reproduce the issue (but I will
retry with the configs posted here, however, the look extremely similar to
what I already use).

Question now: would those of you who can reproduce it be willing to test a
special version that I modify so that it contains some more instrumentation? 

From what I have seen so far, it looks that for some reason GnuTLS requires
an operaton retry (something absolutely OK with TLS) but then seems to be
unable to finish it. That leads to a retry loop. But I have very little
insight into the situation and so any help is deeply appreciated.

Thanks,
Rainer 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#540807: rsyslog: program name filter ! in the configuration cannot be reset

[Rainer Gerhards]

Thanks again for the patch, I have now integrated it into all relevant 
versions.


Rainer

On 08/02/2010 01:19 PM, Kiss Gabor (Bitman) wrote:


This patch fixes the bug.

Gabor

--- ../../rsyslog-orig/rsyslog-3.18.6/conf.c2008-12-10 
19:02:24.0 +0100

+++ conf.c  2010-08-02 13:07:50.213850465 +0200
@@ -962,8 +962,7 @@
if(**pline != '\0'  **pline == '*'  *(*pline+1) == '\0') {
dbgprintf(resetting programname filter\n);
if(pDfltProgNameCmp != NULL) {
-   if((iRet = rsCStrSetSzStr(pDfltProgNameCmp, 
NULL)) != RS_RET_OK)

-   return(iRet);
+   rsCStrDestruct(pDfltProgNameCmp);
}
} else {
dbgprintf(setting programname filter to '%s'\n, *pline);

Bug#540807: rsyslog: program name filter ! in the configuration cannot be reset

[Rainer Gerhards]

Thanks for the patch, I'll check if the problem exists in the current
versions and apply the patch if so :)

Rainer

 -Original Message-
 From: Kiss Gabor (Bitman) [mailto:ki...@ssg.ki.iif.hu]
 Sent: Monday, August 02, 2010 1:19 PM
 To: 540...@bugs.debian.org
 Subject: Bug#540807: rsyslog: program name filter ! in the
 configuration cannot be reset
 
 This patch fixes the bug.
 
 Gabor
 
 --- ../../rsyslog-orig/rsyslog-3.18.6/conf.c  2008-12-10
 19:02:24.0 +0100
 +++ conf.c2010-08-02 13:07:50.213850465 +0200
 @@ -962,8 +962,7 @@
   if(**pline != '\0'  **pline == '*'  *(*pline+1) == '\0') {
   dbgprintf(resetting programname filter\n);
   if(pDfltProgNameCmp != NULL) {
 - if((iRet = rsCStrSetSzStr(pDfltProgNameCmp, NULL)) !=
 RS_RET_OK)
 - return(iRet);
 + rsCStrDestruct(pDfltProgNameCmp);
   }
   } else {
   dbgprintf(setting programname filter to '%s'\n, *pline);
 
 




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#571291: Use SQL_ASCII encoding when creating the PostgreSQL database

[Rainer Gerhards]

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Thursday, February 25, 2010 1:15 AM
 To: Debian Bug Tracking System
 Subject: Bug#571291: Use SQL_ASCII encoding when creating the
 PostgreSQL database
 
 Package: rsyslog-pgsql
 Severity: normal
 
 As reference:
 http://lists.adiscon.net/pipermail/rsyslog/2010-January/003360.html
 
 upstream recommends to create the postgresql db with encoding
 'SQL_ASCII'

Please let me add that this decision was driven by some users. I have very
limited knowledge on that topic. Some comment I received later on was that
SQL_ASCII is not a good option for recent postgres releases. I would
appreciate solid arguments on the pro and con of this switch.

Rainer

 
 Determine, if we want to use SQL_ASCII in Debian or stick with the
 default, UTF-8
 
 dbconfig-common's dbc_pgsql_createdb_encoding allows to specify the
 encoding but currently fails to create a db using SQL_ASCII as the
 template db uses UTF-8.
 
 
 -- System Information:
 Debian Release: squeeze/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: i386 (i686)
 
 Kernel: Linux 2.6.33-rc8 (SMP w/1 CPU core)
 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages rsyslog-pgsql depends on:
 ii  dbconfig-common   1.8.45 common framework for
 packaging dat
 ii  debconf [debconf-2.0] 1.5.28 Debian configuration
 management sy
 ii  libc6 2.10.2-5   Embedded GNU C Library:
 Shared lib
 ii  libpq58.4.2-2+b1 PostgreSQL C client
 library
 ii  rsyslog   4.6.0-1enhanced multi-threaded
 syslogd
 ii  ucf   3.0025 Update Configuration File:
 preserv
 
 Versions of packages rsyslog-pgsql recommends:
 pn  postgresql-client none (no description available)
 
 Versions of packages rsyslog-pgsql suggests:
 pn  postgresqlnone (no description available)
 
 




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#571202: Errors in rsyslog.conf(5)

[Rainer Gerhards]

  In manpage I see parameter InputUDPServerRun, but in config file
 there
  is commented out UDPServerRun. The first doesn't work, the second is
 ok.
 
  I suppose, that there are the same problems with tcp and repl
  parameters.
 
 The InputTCPServerRun and InputRELPServerRun parameters are correct.
 So, using
 UDPServerRun for UDP is inconsistent (and afaik due to historical
 reasons).
 Rainer, would it be possible to use InputUDPServerRun and make
 UDPServerRun an
 alias for InputUDPServerRun. So existing config files would remain to
 work.
 UDPServerRun could be marked as deprecated (and rsyslog could warn in
 the
 syslog/stderr). The existing docs should be updated accordingly and
 after some
 time (say 2 years from now), you could remove the old UDPServerRun
 variable.

I can do this and it sounds like the right thing to do. HOWEVER, there are a
number of these inconsistencies inside the configuration language. They were
introduced because the language evolved rather than being designed for that
purpose. So the naming conventions also evolved.

So I am not sure if we should actually duplicate all of these inconsistent
statements. That's a lot of functional duplicates (especially given the fact
that I still hope to be able to revamp the config language some time during
this year).

Thoughts are appreciated.

Rainer



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#571202: Errors in rsyslog.conf(5)

[Rainer Gerhards]

 Well, my idea is to use some kind of aliasing/mapping. Also it should
 be made
 clear when a given config variable has beem marked deprecated in the
 documentation (also, when it was introduced). And a note for how long
 the old,
 deprecated variable will remain working.
 When using deprecated variables, rsyslog should warn in the syslog
 and/or stderr
 about the usage of such deprecated variables, to give users an
 opportunity to
 update their configuration.
 So, after a while, you can get rid of old, deprecated config variables.
 This procedure could also be applied to other config variables/syntax.

Just some more info, I forgot to add this: reviewing all code, implementing a
basic alias functionality, identifying and changing all occurences in the doc
probably takes about a week to do (not counting the web page updates that I
could potentially leave out).

Rainer



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#571202: Errors in rsyslog.conf(5)

[Rainer Gerhards]

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Wednesday, February 24, 2010 6:57 PM
 To: Rainer Gerhards
 Cc: 571...@bugs.debian.org; Alexander Gerasiov
 Subject: Re: Bug#571202: Errors in rsyslog.conf(5)
 
 On 24.02.2010 18:23, Rainer Gerhards wrote:
  In manpage I see parameter InputUDPServerRun, but in config file
  there
  is commented out UDPServerRun. The first doesn't work, the second
 is
  ok.
 
  I suppose, that there are the same problems with tcp and repl
  parameters.
 
  The InputTCPServerRun and InputRELPServerRun parameters are correct.
  So, using
  UDPServerRun for UDP is inconsistent (and afaik due to historical
  reasons).
  Rainer, would it be possible to use InputUDPServerRun and make
  UDPServerRun an
  alias for InputUDPServerRun. So existing config files would remain
 to
  work.
  UDPServerRun could be marked as deprecated (and rsyslog could warn
 in
  the
  syslog/stderr). The existing docs should be updated accordingly and
  after some
  time (say 2 years from now), you could remove the old UDPServerRun
  variable.
 
  I can do this and it sounds like the right thing to do. HOWEVER,
 there are a
  number of these inconsistencies inside the configuration language.
 They were
  introduced because the language evolved rather than being designed
 for that
  purpose. So the naming conventions also evolved.
 
  So I am not sure if we should actually duplicate all of these
 inconsistent
  statements. That's a lot of functional duplicates (especially given
 the fact
  that I still hope to be able to revamp the config language some time
 during
  this year).
 
  Thoughts are appreciated.
 
 Well, my idea is to use some kind of aliasing/mapping. Also it should
 be made
 clear when a given config variable has beem marked deprecated in the
 documentation (also, when it was introduced). And a note for how long
 the old,
 deprecated variable will remain working.
 When using deprecated variables, rsyslog should warn in the syslog
 and/or stderr
 about the usage of such deprecated variables, to give users an
 opportunity to
 update their configuration.
 So, after a while, you can get rid of old, deprecated config variables.
 This procedure could also be applied to other config variables/syntax.

mmhhh.. thinking again, the warning is much more work to do, it requires
larger additions to the config system (plus touching *all* of the config
variables). The issue I see is if that is well spent time. I work on the
assumption that probably in a year from now nobody will use that old config
language any longer. But I need to preserve it for the future, so the extra
code would also remain.

Rainer




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#552095: rsyslog: please configure with --enable-omprog

[Rainer Gerhards]

Hi Helmut,

Michael Biebl talked to me about the state of omprog. The problem is that it
is not thouroughly tested. I created it in result to a feature request, but
the original requestor lost interest. See here:

http://kb.monitorware.com/problem-to-migrate-from-syslog-ng-to-rsyslog-t8982.
html

So if you could give it a try, do some testing in your environment and let us
know that it works well enough (or which bugs to fix), Michael will probably
be happy to include it. I am hesitant to do this myself, as I have no real
application for it and without at least one real life test, it is hard to
judge how good a piece of software is...

Rainer

 -Original Message-
 From: Helmut Grohne [mailto:hel...@subdivi.de]
 Sent: Friday, October 23, 2009 1:29 PM
 To: Debian Bug Tracking System
 Subject: Bug#552095: rsyslog: please configure with --enable-omprog
 
 Package: rsyslog
 Version: 4.4.1-1
 Severity: wishlist
 Tags: patch
 
 Rsyslog provides a nice output plugin to forward logs to a program.
 This
 is already provided by logging to a named pipe in some way. However
 logging to a named pipe has some drawbacks. When there is no reader
 ready the pipe will not accept messages and messages are dropped. This
 can happen when restarting the reader for instance. There also is
 another plugin omshell already available. It however forks for each
 line, which is not very effective. I therefore suggest adding
 --enable-omprog to ./configure in debian/rules.
 
 Other solutions for reliably feeding log messages to a program are
 welcome, of course.
 
 Helmut
 
 




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#550391: /dev/log sometimes disappears upon rsyslog reload

[Rainer Gerhards]

Is $HUPisRestart set to on?

Rainer 

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org] 
 Sent: Thursday, October 22, 2009 12:19 AM
 To: 550...@bugs.debian.org; Rainer Gerhards
 Cc: Brian Groose
 Subject: Re: Bug#550391: /dev/log sometimes disappears upon 
 rsyslog reload
 
 Brian Groose wrote:
  Package: rsyslog
  Version: 3.18.6-4
  Severity: important
  
  Sometimes we see /dev/log disappear for a while when 
 rsyslog reload is invoked, typically by logrotate.
  I've narrowed down steps to reproduce this bug:
  
  1. Start with a standard lenny install with default syslog settings
  2. Modify /etc/rsyslog.conf and uncomment out the following 
 lines to enable TCP logging:
 #$ModLoad imtcp
 #$InputTCPServerRun 514
  3. Restart or reload rsyslog so the TCP setting is in effect.
  4. Put some logging load on rsyslog. This works nicely:
while [ 1 ] ; do logger Test ; done
  5. Call /etc/init.d/rsyslog reload in a loop with a short 
 sleep in between.  Watch
 for /dev/log not appearing very shortly after the reload.
  
  
  In my testing, I reloaded 1000 times with a 0.1s sleep in 
 between, and 10 of the
  reloads resulted in /dev/log going away.  /dev/log came 
 back after exactly one
  minute in every one of those 10 times (I was no longer 
 calling reload while
  waiting for /dev/log to reappear), but during that one 
 minute nothing can write
  log messages because /dev/log is gone. 
  
  Rsyslog appeared to still be listening on port 514, though 
 since this test does
  not used TCP logging, I could not verify if logging to port 
 514 actually worked.
  
  I did not have any issues if TCP logging was disabled or if 
 there was nothing being
  actively logged.
 
 Hi Rainer,
 
 could you take a look at that.
 Shouldn't a simple reload keep /dev/log available?
 Or is rsyslog doing a full restart on reload due to 
 listening on tcp port 514?
 
 Cheers,
 Michael
 
 -- 
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?
 
 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#463793: rsyslogd restarts are not ignored

[Rainer Gerhards]

On Tue, 2009-08-25 at 20:12 +0200, martin f krafft wrote:
 also sprach Rainer Gerhards rgerha...@hq.adiscon.com [2009.08.25.1243 
 +0200]:
  not very hard, almost trivial. There would one switch be required for
  the startup/shutdown message and probably another one for the message
  that is emitted when rsyslogd is HUPed.
  
  Would that be useful? If so, I'd consider to implement it relatively
  soon (but only in the current v5 devel version).
 
 I always think it's useful to turn off verbose log messages. ;)
 I have now added a new configuration directive

$LogRSyslogStatusMessages [on/off]

which you can use to turn those messages off. The default still is on,
because this is traditional behavior and I know that some log analyzers
depend on verbose log messages ;)

It is implemented towards the v4-devel, backport should be fairly easy
if desired. Patch is here:

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=071c9b511a711725537eff386f82a3af3ca930a8

Will be released as part of 4.7.0

I hope this is useful,
Rainer




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#429243: stopped working, SSH stopped logging failures!

[Rainer Gerhards]

On Wed, 2009-09-02 at 16:10 +0200, Gabor Gombas wrote:
 On Wed, Sep 02, 2009 at 02:30:11PM +0100, Colin Watson wrote:
 
   Maybe a better option would be to let rsyslog automatically create the
   directory for the socket if it is missing?
  
  If it created the socket itself as well, then that might do the job.
  We'd need to make sure permissions were consistent.
 
 IMHO there are three cases to consider:
 
 - A package wants to specify a location that is supposed to be
   non-volatile. In this case the directory is owned by the package,
   and there is no need to auto-create. This is the case for e.g.
   postfix.
 
 - A package wants to specify a location that is (probably) volatile. In
   this case the package already has to have code to create the directory
   and fix the permissions if needed. This is the case for openssh.
 
 - The sysadmin wants to add an extra listener location.
 
 For the first two cases, it's not really the job of rsyslog etc. to get
 the permissions right, so always using root:root  mode 755 is enough.
 For the last case, being able to specify the default owner/permissions
 in the syslog config. file would be nice, but it is not in the scope of
 this bug report.

I have added the functionality to v5 and immediately done a backport to
v4-devel, patch is here:

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=5f76568d3707cbbadfa3767558ded52cf5f27f47

A backport, if desired, should be fairly easy to lower versions of
rsyslog. However, I will not do that, because development (and thus
addition of new features) is closed from the rsyslog POV on these older
releases.

See the doc on the new $InputUnixListenSocketCreatePath directive, I
have included a sample for openssh at the bottom of the page:

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

I have not yet provided the capability to specify owner/permissions, but
it would be fairly easy. However, I prefer to get some feedback from the
field before I do so (aka I would like to see that somebody actually
needs it before I spent even little time on this feature ;)).

I have done brief, but not elaborate testing of the new functionality.
Bug reports are very welcome.

I hope this new feature is useful and solves the issue.

Rainer




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#429243: stopped working, SSH stopped logging failures!

[Rainer Gerhards]

On Wed, 2009-09-02 at 10:51 +0100, Colin Watson wrote:
  Unfortunately it won't really help when /var/run is on tmpfs, because
  the syslog daemon is started before the ssh init script has run. The
  only proper solution I can think of right now is to split the ssh init
  script in two:
  
  - the first part runs before any syslog daemon, and does nothing except
creating /var/run/sshd/dev directory if it is missing
  
  - the second part runs after the syslog daemon has started, and does the
rest.
 
 I definitely don't want to do this. Init script multiplication has a
 slow but inexorable effect on boot time.
 
 Michael, is there a standard approach that packages can use to do this?
 postfix doesn't seem to do anything particularly special.

Some time ago, Michael and I briefly discussed the possibility that
rsyslogd would defer some of its configuration statements to solve such
split situations. Actually, what we discussed was more complex, but I
wonder if a somewhat simpler solution might solve a practical need: What
if we could instruct the socket listener to defer getting activated by
some (fixed, but configurable) period. Something along the lines of

$IMUXSockDelayListen 60

to delay listening by 60 seconds after startup. I think I could quickly
implement such a functionality (in v4-devel) if and only if the delay
applies to all sockets. Not sure if that constraints renders the idea
unusable.

Rainer




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#543505: rsyslog: Wrong priority format for remote action

[Rainer Gerhards]

On Tue, 2009-09-01 at 23:48 +0200, Michael Biebl wrote:
 Andreas Barth wrote:

 Rainer asked me, to block rsyslog 4.4.0 as it apparently also had other issues
 (iirc there was also a segfault during udp reception, but Rainer knows the
 details), so it was not this specific bug report which alone was serious.
 
 Rainer, were you already able to nail down these issues and how far away is 
 the
 4.4.1 release?

Quick answer: I feel much better about 4.4.x right now. I will probably
release 4.4.1 today.

In Depth: the segfault is not yet found, but it turns out that it was
present in 4.2.0 as well. Also, only one person reported it so far and
only on one of his (many) systems, this bug seems to be very related to
the environment. I think this is especially true as 4.2.0 was in far
more widespread use and as such I should have heard about the bug
earlier/from more people if it would be likely to occur. So I conclude
it is OK (though not optimal) to do a new release with this bug. I am
still fighting with it. My next step is to try isolate a version where
it was not present (I somewhat think it may even be present in v3 as
well).

To the rest of 4.4.x release, I made a mistake when I handled the beta.
I moved the beta branch to quickly to a new release, without doing a
stable in between. I thought I had sorted this problem out, but when I
made the 4.3.2 beta stable, I obviously missed backporting some bug
fixes that were present in the newer betas. I think all of them have
now been found and sorted out. There still is a chance that I may be
wrong, but git log review plus absence of any more bug reports makes me
think I am right.

So, all in all, it probably is a good time to do a 4.4.1 release.

Rainer




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#429243: stopped working, SSH stopped logging failures!

[Rainer Gerhards]

sorry, looks like I forgot the CCs on my previous message. Context given
in quote...

On Wed, 2009-09-02 at 13:07 +0100, Colin Watson wrote: 
  The problem here is that HUP is either one of the two. So if openssh's
  init needs a restart type HUP, rsyslogd must be configured to use
  restart-type HUPs. This is no longer supported in v5 (and a bad solution
  in v34 for various reasons).
 
 We could just do '/etc/init.d/rsyslog restart', or the equivalent. It's
 not perfect, but it's not that painful if you're restarting openssh too.

OK, that's of course an option - but if others do the same, we may end
up in a kind of restart loop 
 
  I think the wait approach would be preferrable (maybe I can do it on a
  per-socket basis with sufficient easy, need to check, but doubt it).
 
 I'm concerned that this would mean that log messages just vanish until
 some arbitrary time after openssh starts, which will be confusing for
 sysadmins who learn to expect them to be present; and that if some init
 script between rsyslog and openssh blocks for ages on start, it will
 cause a failure, making the whole system less robust. In general we're
 trying to move the init system towards being fully event-driven, and
 arbitrary delays aren't usually compatible with that.

I think the socket will hold some amount of messages, so I would not
expect that they totally disappear. But I may be wrong, in which case
this is no real solution, agreed.

Let me check if I can do something more clever with these sockets that
fits into the time frame I have available...

Rainer




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#543505: rsyslog: Wrong priority format for remote action

[Rainer Gerhards]

 Quick answer: I feel much better about 4.4.x right now. I will probably
 release 4.4.1 today.

FYI: 4.4.1 has been released: http://www.rsyslog.com/Article399.phtml

Rainer



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#429243: stopped working, SSH stopped logging failures!

[Rainer Gerhards]

On Wed, 2009-09-02 at 14:46 +0200, Gabor Gombas wrote:

 Maybe a better option would be to let rsyslog automatically create the
 directory for the socket if it is missing?

ahhh - so trivial :)  If that helps, that would, I think, not be a big
deal. I would still appreciate some feedback on my inotify question (I
prefer to do the right thing over a workaround-like thing if I can fit
it into my schedule).

Thanks,
Rainer




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#429243: stopped working, SSH stopped logging failures!

[Rainer Gerhards]

On Wed, 2009-09-02 at 12:15 +0100, Colin Watson wrote:
 I can't say I'm keen on an arbitrary delay either. inotify would be
 better, but until rsyslog can use it perhaps

I have checked the code now. What I can do with relative ease is re-try
opening failed sockets. However, this would create a non-deterministic
delay, because - with the current code - this would only happen after
select() is left, that is after one message on at least on of the active
sockets has been received. I doubt this is really useful... 

On the other hand, in the case of a system start, chances are good to
have such a message relatively soon, so it may be a pretty dirty but
useful change, in the sense that it works most of the time...

Let me phrase a question on inotify: you would use it to watch the
directory if the sockets has been created (and recursively watch all
directories above it, if they do not exist OR disappear during the watch
process)? Or am I overlooking something. I have to admit I have not
really used inotify so far (compatibility...) so I may be overlooking
something or may be thinking too complex. 

Rainer




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#463793: rsyslogd restarts are not ignored

[Rainer Gerhards]

On Mon, 2009-08-24 at 11:28 -0400, Frédéric Brière wrote:
 On Wed, Aug 19, 2009 at 08:08:18PM +0200, martin f krafft wrote:
  When I joined logcheck, there was an unwritten policy not to filter
  startup and shutdown messages. I don't know if that extends to
...
 But yeah, if rsyslog emits these messages as a matter of course, they
 should be filtered IMO.  Missing a potential theoretical shutdown of
 rsyslog is a lesser evil, compared to annoying the sysadmin with
 messages that will be ignored anyway.
 
 (One possible idea would be to peg the restart rule to the approximate
 time of day when cron.daily is run.

One other option would be to create some rsyslog configuration
statements that can be used to suppress these kind of messages. This is
not very hard, almost trivial. There would one switch be required for
the startup/shutdown message and probably another one for the message
that is emitted when rsyslogd is HUPed.

Would that be useful? If so, I'd consider to implement it relatively
soon (but only in the current v5 devel version).

Rainer




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#543505: rsyslog: Wrong priority format for remote action

[Rainer Gerhards]

On Tue, 2009-08-25 at 15:19 +0200, ur...@xmon.net wrote:
 Package: rsyslog
 Version: 4.4.0-1
 Severity: important
 
 
 Hi,
 
 On a client-server configuration, since my upgrading to the last unstable 
 version (on the client, the server is from stable), 
 i started to get warnings with logcheck like this :
 
 Aug 25 15:09:01 86Aug 25 15:09:01 media CRON[15799]: 
 pam_unix(cron:session): session opened for user root by (uid=0)
 
 ^ priority level appears in the message
 
 
 Tcpdump between the hosts reveals the priority level is doubly angled 
 bracketed in contradiction to the rfc :
 
 14:37:53.148300 IP media.xmon.net.34356  monit.xmon.net.shell: P 
 2921736728:2921736841(113) ack 2924583695 win 257 nop,nop,timestamp 
 1705521342 1705518585
 e.@.@..t
 8...@c
 8...@..4...*..Q...Z.
 e.0.e.%.85Aug 25 14:37:53 media sudo:uroot : TTY=pts/7 ; 
 PWD=/tmp/rsyslog-4.4.0 ; USER=root ; COMMAND=/bin/ls -l
 
 
 My configuration is mostly default except this :
 
 #$ModLoad imklog   # provides kernel logging support (previously done by 
 rklogd) 
 $ModLoad immark  # provides --MARK-- message capability
 *.* @@monit.xmon.net
 
 
 Thx,
 +++
 tonio
 

fixed upstream:
http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=1164429974dcd71ef59dededd3fec54162d919dd

Rainer




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#539739: AW: Bug#539739: rsyslog: The marks (-- MARK --) are not always written

[Rainer Gerhards]

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Tuesday, August 04, 2009 2:47 PM
 To: Frédéric Massot; 539...@bugs.debian.org
 Cc: Rainer Gerhards; cont...@bugs.debian.org
 Subject: Re: Bug#539739: AW: Bug#539739: rsyslog: The marks (-- MARK --
 ) are not always written
 
 reopen 539739
 thanks
 
 Frédéric Massot wrote:
  Michael Biebl a écrit :
  Frédéric Massot wrote:
  If you look at the extract from the log file messages, you see
 that
  there would be a mark to 1h17. But there was none.
  Right, because there was a regular syslog message in between.
  Afaik, the mark messages work this way:
  Whenever you receive a regular syslog message (doesn't matter into
 which log
  file they go), the mark counter is reset.
  So only if you do not receive any regular syslog messages, you get
 mark messages
  in a regular 20 min intervall.
 
  This is surprising, because there is the hddtemp daemon that writes
  every minute in the file syslog, but I have marks in the file
 messages.
 
 Seems I was simply wrong with my assumption.
 I just checked the code in immark.c and when enabled it injects a MARK
 message
 after each iMarkMessagePeriod unconditionally.
 
 Rainer, any ideas why sometimes MARK messages are not written?
 
 Anyway, I reopened the bug report until we know more.

I have now reviewed the code. My initial posting was correct, rsyslog works
as intended. While immark generates mark messages at fixed intervals, the
action processor removes them if the action was recently enough called (see
action.c, ln. 1189, current master branch). This handling is so that a local
perception of recently called is kept on a per-action basis. This stems
back to sysklogd, but I also think it is the correct way to handle the
situation. As such, it is not important if any *other* action was called
within that interval, it is only important if the action itself was called
(or not) within the interval.

I would probably fairly easy to add an option to *always* write mark messages
if there is a real need for such. As of rsyslog policies, that will probably
only go into v5 (maybe v4, but definitely not v3).

Please let me know your thoughts.

Rainer

Bug#539739: AW: Bug#539739: rsyslog: The marks (-- MARK --) are not always written

[Rainer Gerhards]

On Thu, 2009-08-20 at 12:15 +0200, Frédéric Massot wrote:

 To use the watchdog package and the settings file and change it is
 really important that the marks are written every 20 minutes.
 
 And as we are in a context of a server restart automatically in case of
 problems, I think the marks must always be written. That way if the
 server is restarted because of an unwritten marks is that there was
 really a problem and not a decision of rsyslog.  :o)
   
 It's really interesting to use the watchdog package to have an option to
 have the marks are always written.

I have added a new config option $ActionWriteAllMarkMessages, which must
be specified in front of the action that needs to write all mark
messages (in your case probably all).

As of rsyslog policies, this goes into the current development version,
which is v5. However, I think the patch should be fairly easy to
backport, or even apply literaly to older versions (but I have not tried
this and will usually not offer any support for such endavours).

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=c7f746d8349b395b95b3aa70eb395afb07b9c4c7

From the new doc:

==
lib$ActionWriteAllMarkMessages/b [on/boff/b]- [available since
5.1.5] - normally, mark messages
are written to actions only if the action was not recently executed (by
default, recently means within the
past 20 minutes). If this setting is switched to quot;onquot;, mark
messages are always sent to actions,
no matter how recently they have been executed. In this mode, mark
messages can be used as a kind of
heartbeat. Note that this option auto-resets to quot;offquot;, so if
you intend to use it with multiple
actions, it must be specified in front off ball/b selector lines
that should provide this 
functionality.
==

I did only a quick test, but as this is fairly simple, I do not expect
something goes wrong. Any feedback is appreciated.

I hope this is useful.

Rainer




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#519073: rsyslog initialization hangs with some incorrect rsyslog.conf

[Rainer Gerhards]

Sorry for the late reply, been very busy. I tried to reproduce it on a
current version of lenny today. I used the current debian_lenny rsyslog git
branch.

My testing conf did not cause any problems so I used

$ModLoad /path/to/my/copy/of/imudp
$UDPServerRun 514
$UDPServerRun 515

Which also did not cause any issues. Looking at the code also does not reveal
anything that is obvious wrong or at least questionable. 

So at this moment, I am stuck. A gdb backtrace or a debug log (or both ;))
would probably be useful.

Rainer

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Tuesday, May 05, 2009 7:36 PM
 To: Rainer Gerhards; 519...@bugs.debian.org
 Cc: Morten Laursen
 Subject: Re: Bug#519073: rsyslog initialization hangs with some incorrect
 rsyslog.conf
 
 retitle 519073 rsyslog segfaults when $UDPServerRun is configured more than
 once
 severity 519073 important
 thanks
 
 Rainer Gerhards wrote:
  I tried, but cannot reproduce this problem. Can you please run rsyslogd
  in debug mode and submit the debug log of the startup. Instructions are
  available here:
 
  http://www.rsyslog.com/doc-troubleshoot.html
 
  If a module is loaded multiple times rsyslog hangs during startup.
  In particular add the following lines to the end of /etc/rsyslog.conf
  $ModLoad imudp
  $UDPServerRun 514
  $ModLoad imudp
  $UDPServerRun 514
 
 
 Hi,
 
 I can reproduce the problem. The root cause is not, that imudp is loaded
 twice,
 but that you have multiple instances of $UDPServerRun
 
 So this:
 $ModLoad imudp
 $UDPServerRun 514
 $UDPServerRun 515 (doesn't really matter, what port you choose)
 
 will also cause a segfault
 
 I can verify this for both 3.18.4 and 3.20.5 and 3.22.0 (haven't tested
master
 yet).
 
 Rainer, are you able to reproduce the problem with this information?
 
 Cheers,
 Michael
 
 --
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#519073: rsyslog initialization hangs with some incorrect rsyslog.conf

[Rainer Gerhards]

I tried, but cannot reproduce this problem. Can you please run rsyslogd
in debug mode and submit the debug log of the startup. Instructions are
available here:

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

Thanks,
Rainer

 -Original Message-
 From: Morten Laursen [mailto:m...@rtx.dk]
 Sent: Tuesday, March 10, 2009 10:22 AM
 To: sub...@bugs.debian.org
 Subject: Bug#519073: rsyslog initialization hangs with some incorrect
 rsyslog.conf
 
 Package: rsyslog
 Version: 3.18.6-4
 Severity: normal
 
 
 If a module is loaded multiple times rsyslog hangs during startup.
 In particular add the following lines to the end of /etc/rsyslog.conf
 $ModLoad imudp
 $UDPServerRun 514
 $ModLoad imudp
 $UDPServerRun 514
 
 and it will hang during startup.
 
 -- System Information:
 Debian Release: 5.0
   APT prefers stable
   APT policy: (500, 'stable')
 Architecture: i386 (i686)
 
 Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash
 
 Versions of packages rsyslog depends on:
 ii  libc6  2.7-18GNU C Library: Shared
 libraries
 ii  lsb-base   3.2-20Linux Standard Base 3.2
 init scrip
 ii  zlib1g 1:1.2.3.3.dfsg-12 compression library -
 runtime
 
 Versions of packages rsyslog recommends:
 ii  logrotate 3.7.1-5Log rotation utility
 
 Versions of packages rsyslog suggests:
 ii  rsyslog-doc   3.18.6-4   documentation for rsyslog
 pn  rsyslog-mysql | rsyslog-pgsql none (no description
available)
 
 -- no debconf information



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509292: rsyslog: random crashes with remote logging

[Rainer Gerhards]

OK, thanks to the help of Lorenzo Catucci, I was able to pinpoint one
problem that can cause a race. I will write up the details soon, but
this requires some time ;) I think I have a fix for the debian_lenny
branch, you can pull it from git and also find it on its gitweb:

http://git.adiscon.com/?p=rsyslog.git;a=commit;h=35673b12c42429786f6229f
f9fcef7001a6b21ab

No other branch has been patched so far.

Rainer

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org]
 Sent: Tuesday, January 27, 2009 3:03 PM
 To: Rainer Gerhards
 Cc: Juha Koho; 509...@bugs.debian.org
 Subject: Re: Bug#509292: rsyslog: random crashes with remote logging
 
 Rainer Gerhards wrote:
  Is there any chance we could try this with the current v3-stable?
Or,
  better yet, with the current v4? The reason I ask is that I have run
  some valgrind/DRD tests today, and that reminded me that 3.18 had a
  couple of not so nice sync primitive handlings. They should not be
 the
  issue, but it is pretty hard to use valgrind on that version. So
I'll
  focus troubleshooting on v4. It may be that I will not be able to
  backport a fix, once I find it (but it is still too early to think
 about
  the details ... let's find it first ;)).
 
 
 Latest v3-stable (3.20.3) is available from experimental [1].
 I could try to provide unofficial Debian packages for v4 for Juha, if
 that helps
 (but I currently only have a i386 to build these packages)
 
 Cheers,
 Michael
 
 [1] http://packages.debian.org/experimental/rsyslog
 --
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509292: rsyslog: random crashes with remote logging

[Rainer Gerhards]

Sorry, there was a copypaste error in the commit. It is corrected now.
Please pull the latest version from that git branch. 

 -Original Message-
 From: Rainer Gerhards [mailto:rgerha...@hq.adiscon.com]
 Sent: Wednesday, January 28, 2009 1:00 PM
 To: Michael Biebl
 Cc: Juha Koho; 509...@bugs.debian.org
 Subject: Bug#509292: rsyslog: random crashes with remote logging
 
 OK, thanks to the help of Lorenzo Catucci, I was able to pinpoint one
 problem that can cause a race. I will write up the details soon, but
 this requires some time ;) I think I have a fix for the debian_lenny
 branch, you can pull it from git and also find it on its gitweb:
 

http://git.adiscon.com/?p=rsyslog.git;a=commit;h=35673b12c42429786f6229
 f
 f9fcef7001a6b21ab
 
 No other branch has been patched so far.
 
 Rainer
 
  -Original Message-
  From: Michael Biebl [mailto:bi...@debian.org]
  Sent: Tuesday, January 27, 2009 3:03 PM
  To: Rainer Gerhards
  Cc: Juha Koho; 509...@bugs.debian.org
  Subject: Re: Bug#509292: rsyslog: random crashes with remote logging
 
  Rainer Gerhards wrote:
   Is there any chance we could try this with the current v3-stable?
 Or,
   better yet, with the current v4? The reason I ask is that I have
 run
   some valgrind/DRD tests today, and that reminded me that 3.18 had
a
   couple of not so nice sync primitive handlings. They should not
 be
  the
   issue, but it is pretty hard to use valgrind on that version. So
 I'll
   focus troubleshooting on v4. It may be that I will not be able to
   backport a fix, once I find it (but it is still too early to think
  about
   the details ... let's find it first ;)).
  
 
  Latest v3-stable (3.20.3) is available from experimental [1].
  I could try to provide unofficial Debian packages for v4 for Juha,
if
  that helps
  (but I currently only have a i386 to build these packages)
 
  Cheers,
  Michael
 
  [1] http://packages.debian.org/experimental/rsyslog
  --
  Why is it that all of the instruments seeking intelligent life in
the
  universe are pointed away from Earth?
 
 
 




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509292: rsyslog: random crashes with remote logging

[Rainer Gerhards]

Is there any chance we could try this with the current v3-stable? Or,
better yet, with the current v4? The reason I ask is that I have run
some valgrind/DRD tests today, and that reminded me that 3.18 had a
couple of not so nice sync primitive handlings. They should not be the
issue, but it is pretty hard to use valgrind on that version. So I'll
focus troubleshooting on v4. It may be that I will not be able to
backport a fix, once I find it (but it is still too early to think about
the details ... let's find it first ;)).

Rainer

 -Original Message-
 From: Juha Koho [mailto:jmcs...@gmail.com]
 Sent: Sunday, January 25, 2009 10:32 AM
 To: Michael Biebl
 Cc: 509...@bugs.debian.org; Rainer Gerhards
 Subject: Re: Bug#509292: rsyslog: random crashes with remote logging
 
 On Sat, Jan 24, 2009 at 3:06 PM, Michael Biebl bi...@debian.org
 wrote:
  Rainer suspected atomic operations to be the root cause. This would
 mean a
  problem in GCC at compile time.
  rsyslog basically depends on zlib1g and libc6. I don't expect zlib1g
 to have any
  influence, so you might wanna check if libc6 has been updated on you
 system.
 
 Just when I said I have had no problems... last night (not during cron
 job) rsyslog had crashed in my client (last lines of syslog attacted).
 
 So I can still reproduce this bug. Do you want to be sure and wait for
 another crash or do you want me to start be removing the $ActionQueue*
 directives from configuration?
 
 Regards,
 Juha



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509292: rsyslog: random crashes with remote logging

[Rainer Gerhards]

Juha,

that's the problem with this bug, it is hard to reproduce. However, I
made some progress recently and finally am able to reproduce it in my
lab. I am currently posting updates on the progress via twitter at
http://twitter.com/rgerhards in case you'd like to follow - and
eventually add to - what I am doing (It's kind of problematic to
broadcast all the details...).

So in short, I don't suggest anything at this stage. I am pretty
confident, however, that removing the $ActionQueue mode will solve the
issue for the time being, but of course at the cost of reduced
functionality.

Rainer

 -Original Message-
 From: Juha Koho [mailto:jmcs...@gmail.com]
 Sent: Sunday, January 25, 2009 10:32 AM
 To: Michael Biebl
 Cc: 509...@bugs.debian.org; Rainer Gerhards
 Subject: Re: Bug#509292: rsyslog: random crashes with remote logging
 
 On Sat, Jan 24, 2009 at 3:06 PM, Michael Biebl bi...@debian.org
 wrote:
  Rainer suspected atomic operations to be the root cause. This would
 mean a
  problem in GCC at compile time.
  rsyslog basically depends on zlib1g and libc6. I don't expect zlib1g
 to have any
  influence, so you might wanna check if libc6 has been updated on you
 system.
 
 Just when I said I have had no problems... last night (not during cron
 job) rsyslog had crashed in my client (last lines of syslog attacted).
 
 So I can still reproduce this bug. Do you want to be sure and wait for
 another crash or do you want me to start be removing the $ActionQueue*
 directives from configuration?
 
 Regards,
 Juha



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#512663: When logging to remote, hostname gets doubled

[Rainer Gerhards]

The problem is that sysklogd does not properly parse the syslog header
and does NOT expect a hostname inside it. sysklogd always uses the
hostname from the udp layer, thus the duplication.

However, it is easy to work around: you need to create a special
template (that does not contain the host name) and use that template in
the forwarding action. Would probably make sense to include a stock
template for this purpose...

HTH
Rainer

On Thu, 2009-01-22 at 18:52 +0100, Michael Biebl wrote:
 Nikita V. Youshchenko wrote:
  Package: rsyslog
  Version: 3.18.6-3
  Severity: normal
  
  Looks like fresh lenny installs come with rsyslog instead of old
  syslogd.
  
  In our network, logs from all hosts are sent to one server, called
  loghost, using remote logging. There, logs are checked by logcheck.
  
  Most of the net, including loghost, currently runs etch. But there are
  several new hosts with lenny.
  
  On these hosts, I've added this to /etc/rsyslogd.conf:
  
  # Send all logs to loghost
  *.* @loghost.lvknet
  
  This works, however on loghost (running syslogd from etch), all lines
  got from lenny hosts have hostname doubled:
  
  Jan 22 19:20:22 buki.lvknet buki /USR/SBIN/CRON[31333]: (root) CMD (cd /  
  run-parts --report /etc/cron.hourly)
  
  Here, hostname (buki) is written twice.
  
  This is not good, since that breaks all logcheck rules that come from
  various packages.
  
  Btw, in local log files, hostname is not doubled.
  
  Any possibility to make rsyslogd not to double hostname when sending
  logs to remote?
  
 
 I can not reproduce this, but then I have rsyslog running on the syslog 
 server.
 
 So this might actually be a problem in sysklogd.
 
 Rainer, is there an incompatibility when forwarding messages from an rsyslog
 client to a sysklogd server? Can this be worked around in rsyslog?
 
 Cheers,
 Michael
 




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#512663: When logging to remote, hostname gets doubled

[Rainer Gerhards]

 

 -Original Message-
 From: Michael Biebl [mailto:bi...@debian.org] 
 Sent: Thursday, January 22, 2009 7:07 PM
 To: Rainer Gerhards
 Cc: Nikita V. Youshchenko; 512...@bugs.debian.org
 Subject: Re: Bug#512663: When logging to remote, hostname gets doubled
 
 Rainer Gerhards wrote:
  The problem is that sysklogd does not properly parse the 
 syslog header
  and does NOT expect a hostname inside it. sysklogd always uses the
  hostname from the udp layer, thus the duplication.
 
 But that sounds more like a bug in sysklogd then rsyslog, right?
Well... Yes and no (see below)

 Or is adding a hostname to the syslog header non-standard?
No, RFC 3164 specifies that the hostname is present.

 
 I quickly tested syslog-ng, and fwiw it also doesn't seem to 
 have a problem with
 logs from a rsyslog client (although syslog-ng does not use 
 the hostname but the
 ip address from the remote host. So it seems, everyone is 
 doing it a bit
 differently)

That's the big issue: indeed, everybody is doing it different. RFC 3164
is just an informal document and while it is somewhat blessed by RFC
3195, we willl not have a real header standard until syslog-protocol is
finally out. While working on it, my research has shown that nothing
than PRI is acutally common across current syslog implementations. So it
is a really bad situation (the rsyslog parser includes a lot of
guesswork for that very same reason).

 
 
  
  However, it is easy to work around: you need to create a special
  template (that does not contain the host name) and use that 
 template in
  the forwarding action. Would probably make sense to include a stock
  template for this purpose...
 
 Rainer, could you post such a template?

I can not test right now (being at home without a test machine active),
but it should be 

$template sysklogd, %PRI%%TIMESTAMP%
%syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%

I have taken that from the stock templates in rsyslogd and just removed
the hostname. It should do the trick.
 
Rainer



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#511562: rsyslog: segfault on reload when using $AllowedSender

[Rainer Gerhards]

On Thu, 2009-01-15 at 10:03 +0200, Juha Koho wrote:
 On Tue, Jan 13, 2009 at 2:02 AM, Michael Biebl bi...@debian.org wrote:
  Rainer Gerhards wrote:
  In my lab, I could reproduce the issue (well, without an abort,
  unfortunately, but valgrind showed problems). The valgrind run was clean
  after the change. I would appreciate if you could verify in your
  environment. If it looks good, I'll create a new release.
 
  Works for me.
 
 Hello,
 
 seems to work for me too. No problems when reloading.

Juha: thanks for the confirmation. Makes me fell better about the
patch ;)

Michael: do you still want me to hold the release until we can settle
the race condition? I don't want to sound too pessimistic, but I'd
assume that takes at least another two or three weeks. It's your
decision, as only the debian_lenny tree is affected (I'll update the
regular v3-stable soon). Please let me know.

Rainer




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509292: rsyslog: random crashes with remote logging

[Rainer Gerhards]

On Wed, 2009-01-14 at 08:40 +0100, Michael Biebl wrote:
 I don't think the $AllowedSender directive has any influence on the crashes 
 Juho
 experiences on his rsyslog clients (as he only used those directive on the
 rsyslog server).
 Why do you suspect that the $AllowedSender fix might have an influence on 
 this?

I don't suspect it has - I was wrong ;) I think I was too-focussed on
the quad core issue that I didn't even read the config correctly. I
thought the crashes happened on the server. I now need to reevaluate the
material - or maybe it is simpler if I just follow what happens now.

 Then we have the random crashes on the client (tracked as #509292). Juho's
 rsyslog.conf is at [1]. The only clue so far is, that it is related to multi
 core machines (= 4 cores). I'm not convinced that it is related to remote 
 logging.
 Juho, could you strip down your rsyslog.conf step by step (i.e. first remove 
 the
 remote logging, then the $ActionQueue* directives, then the imklog plugin, 
 then
 the different rules), which will help us to narrow down this bug.

I'd actually start with removing the $ActionQueue* directives, as they
cause additional asynchronizity. But the important thing is it first get
back to a state where we can (somewhat) reliably reproduce the bug. I
think we should see at least 3 aborts in a row before we do any changes.
The reason is that we otherwise do not know if the config changed caused
the situation to improve or that was just a random non-abort. That's the
issue I have run into all time so far...

Rainer




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#511562: rsyslog: segfault on reload when using $AllowedSender

[Rainer Gerhards]

Hi Michael,

 Rainer, I'd like (you) to take a look a #509292 first, before making a
 new release.

I am looking at it, but this looks like the dangling issue we have on 4+
core systems from time to time. I am not sure if there will be a quick
fix for that. One problem is that I can not reproduce the issue.

But I'll have another look into it, maybe we get good enough debug info.

Rainer



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509292: rsyslog: random crashes with remote logging

[Rainer Gerhards]

Juha,

I have finally been able to review the material that came with this bug
report. Thanks for all the good info, but it looks everything was
related to the $AllowedSender bug, not to the race condition (which I,
too, think exists).

... more inline below...

On Sat, 2009-01-10 at 20:12 +0200, Juha Koho wrote:
 For this issue (number 2.) I believe it could be a thread
 synchronization issue. The client that has had these problems is a
 quad core system and I installed other single core system with exactly
 the same configuration not running the recompiled version and it has
 been working perfectly since I installed it for at least a week ago.

Definitely. I am trying to track down a nasty race condition (I think it
is one) for a while now. It seems to occur only on machines with at
least four cores and not always. I unfortunately can not reproduced it
myself. This partly due to insufficient hardware, but when I got a
machine for a while, I was able to see the issue only once or twice, but
very, very random and I could not draw any conclusion before I needed to
return the machine. There are few other reports, but for none of them I
have been able to obtain any information that points to the culprit. I
hope we can make better success in your case.

  I
 don't think these issues are related either because my client used to
 crash at random times and not during reload.

Right, this one is different.

 
 By the way. I'm actually using TCP to forward messages and I haven't
 tried UDP yet.

This doesn't seem to make a difference. I think I have tracked down it
to either the code that creates or destructs the message object, but not
being able to reliably reproduce, this is just an educated guess. So the
input may make a difference (but I don't think so).

The primary question I have at this time is if you can reproduce the bug
without the $AllowedSender directive (or with the patch I created for
the cloned bug). If so, that would be a very good thing. From there, we
would need to change the config to see if it disappears if some settings
are changed (I am a bit sceptic about the async queue). That than could
lead us to the right path, even when not being able to apply any debug
settings. Oh - did I mention that the bug almost instantly disappears if
rsyslog is compiled for debugging. I initially thought that is an
artifact of limited concurrency due to debug calls, but now I tend to
believe that it actually is due to reduced speed - so on a 8-core system
we may have the issue even with debug mode (someone with a 8 way system
out there? ;)).

I guess the bug is quite basic, but it is very hard to find it not being
able to reproduce it at will or at least once a day and in debug mode...

Feedback appreciated,
Rainer




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#511562: rsyslog: segfault on reload when using $AllowedSender

[Rainer Gerhards]

Hi all,

thanks for the bug report and your help in narrowing it down. I was on
vacation and returned today. I have created a patch for this issue (as
usual, a dumb mistake...). I'd appreciate if you could give it a try.
Available from rsyslog git (debian_lenny branch):

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=20ff1ed403f05606b68
c13e4d5c591c6b8706f86

In my lab, I could reproduce the issue (well, without an abort,
unfortunately, but valgrind showed problems). The valgrind run was clean
after the change. I would appreciate if you could verify in your
environment. If it looks good, I'll create a new release.

Thanks,
Rainer



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org