pmnull module not included in rpm packages

[JPvRiel]

Expected behavior

Given the content of http://rpms.adiscon.com/v8-stable/epel-7/x86_64/RPMS/, pmnull.so should either included in core rsyslog package or have a rsyslog-pnull-.rpm package available to install it.

The pseudo config below would ideally be viable without needing to compile rsyslog and pmnull from source:

module(load="pmnull")
template(name="RawMsg" type="string" string="%rawmsg%\n")
...
ruleset(name="process_raw_message" parser="rsyslog.pmnull") {
  action(
     template="RawMsg"
     ...
  )
}

Actual behavior

Attempting to use the null parser module results in this error for CentOS/RHEL rpm based distros:

      rsyslogd: could not load module '/usr/lib64/rsyslog/pmnull.so', dlopen: /usr/lib64/rsyslog/pmnull.so: cannot open shared object file: No such file or directory  [v8.36.0 try http://www.rsyslog.com/e/2066 ]

http://rpms.adiscon.com/v8-stable/epel-7/x86_64/RPMS/ has no and for rsyslog-8.36.0-1.el7.x86_64.rpm, pmnull.so does not exist in /usr/lib64/rsyslog.

Steps to reproduce the behavior

setup yum to use adiscon repo for stable v8 and simply add module(load="pmnull") to trigger error.

Environment

• rsyslog version: 8.36
• platform: CentOS 7.5

Workarround

Use standard parser chain or just rfc3164 and ignore all rsyslog properties by just using rawmsg in an output template (but a few CPU cycles will be wasted with parsers putting junk into rsyslog properties if the format doesn't comply with syslog)

Extra

Interestingly, the following parse modules were included in rsyslog-8.36.0-1.el7.x86_64.rpm

• pmsnare.so
• pmlastmsg.so
• pmaixforwardedfrom.so

And #1761 is related (but closed) for .deb packages.

[rgerhards]

I guess the differences between distro packages are because we try to keep close to the distros - so we get different package structure.

@friedl can you comment?

[rgerhards]

@JPvRiel pls note: I cannot assign @friedl here as he has no write access to the source repository.

[friedl]

@JPvRiel can you possibly describe your use-case a little bit? What is pmnull used for in your case?

Currently, new packages including pmnull are in the making and should be finished soon.

[JPvRiel]

@JPvRiel can you possibly describe your use-case a little bit? What is pmnull used for in your case?

@friedl thanks for looking into this and the quick fix.

Basically, I'm using rsyslog imkafka to take in messages already fully / correctly parsed into a syslog format from another system and want to relay them via omfwd without needing (or wanting) rsyslog to try parse the headers, hence pmnull. Indeed, I can leave the default parsers and use %rawmsg% in a string template for the output (which will ignore/not be affected by the properties the default parsers set), but the rsyslog parser modules are going to do unnecessary work. In our case, we're heading over 25K/s messages (and likely to double soon) so I'm hoping to find ways to optimize. I expect rsyslog parsers are already highly efficient, so this is not critical, but rather a "nice-to-have".

rsyslog is useful in that it plugs into kafka (which is great for streaming all kinds of log data) while the security product I needed to integrate with didn't have mature kafka support and prefered events in a specific syslog format.

[rgerhards]

@JPvRiel I think the time saving by pmnull is very marginal, so unless you run several 100,000 messages per second, you won't notice it. Just wanted to make this clear. The reason is that pmnull also needs to populate the standard properties, and it does so with the same defaults the standard parser uses. So what can be saved is some comparisons during the parsing.

[JPvRiel]

time saving by pmnull is very marginal

Thanks for the explanation 👍

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.