I'm having trouble on a couple of fronts, one with rules and second with RELP.
RULES
I'm having trouble with a perfectly valid set of rules that function as
configured but nevertheless fail when in an imuxsock ruleset.
I can imagine no reason why this would be and would welcome any input about
how to get the ruleset to work.
I've attached the rsyslog.conf file, which includes all of the working rules
and their failing counterparts, essentially for A/B testing. The behavior
I'm observing is:
- Basic rules (i.e., selector and action) in the imuxsock ruleset execute
(albeit without regard to configuration statements in the module() object
that loads omfile--other than the template specified therein, which the
basic rules observe--another unexpected example of parallel binary
function).
- Rules in the imuxsock ruleset fail if they either (a) have property-based
filters; or (b) are conditional expressions.
- Rules (in the form of conditional expressions) in a separate ruleset
called by an imudp-type input module with otherwise identical syntax,
execute. So, we know that conditional expressions work, which suggests the
issue lies with imuxsock.
So:
- The same rules operate alone but not in a ruleset called by an
imuxsock-type input module.
- Some rules operate in a ruleset called by an imuxsock-type input module,
and others don't. For those that don't, syntactically identical rules in a
ruleset called by imudp-type input module, do operate.
- Some omfile configuration parameters in module() operate for basic rules
and others don't.
Specifically, versions A-D fail; versions E&F, which are outside any
ruleset, execute (versions are identified in commented lines).
Thoughts?
RELP
Several problems with RELP, including listener dependencies and connection.
The RELP listener is failing to bind to its configured port on boot but
succeeds on restart (i.e., systemctl restart rsyslog). This suggests a
dependency issue but I'm not sufficiently familiar with the rsyslog
dependencies to intelligently revise rsyslog.service. Perhaps this may only
require changing Restart=on-failure to Restart=always (with corresponding
addition of StartLimitIntervalSec=0, so as not to limit restarts) but I
imagine a more elegant solution, i.e., revising the dependencies with an
After= or Requires= parameter, exists.
>From the operating state file (also note the incorrect datestamp, which
reflects the prior month) after boot:
20200425-061625: STATE INITIALIZING 8.2004.0
20200425-061625: MSG debug log file is '/var/log/rsyslog.debug', fd 7
20200425-061625: MSG imrelp[20514]: error 'error while binding relp tcp
socket on port '20514'', object 'lstn 20514' - input may not work as
intended
20200425-061625: MSG imrelp: could not activate relp listener, code 10005
After restart (i.e., systemctl restart rsyslog), the two imrelp entries no
longer appear and ss reveals that the port is being listened on.
This reveals the next problem, which is the absence of a RELP connection.
Oddly, this connection existed briefly last week but I then was in the
process of learning that socket= is a mandatory input parameter for imuxsock
(even for the system socket) and so no sender log files exist then--the only
evidence is the presence of sender message files on the receiver. Also,
because I hadn't then realized the RELP listener only was bound after a
restart, it was only on by chance and there are only a handful of messages,
none relevant.
SELinux is not configured.
I also note that messages from a third device via imudp are written as
configured, so a bit is working.
The current error messages (as follow) suggest a librelp issue, but it
persists even after tls="off" is expressly set, on both the sender's omrelp
action statement and the receiver's imrelp input statement. This also does
not explain last week's brief connection.
>From the sender's operating state file (also note the datestamp issue exists
on this system also (U18.04/r8.2004):
20200425-075506: MSG rsyslogd fully started up and initialized - begin
actual processing
20200425-075516: MSG omrelp[192.168.1.2:20514]: error 'error opening
connection to remote peer', object 'conn to srvr 192.168.1.2:20514' -
action may not work as intended
20200425-075516: MSG omrelp[192.168.1.2:20514]: error 'error opening
connection to remote peer', object 'conn to srvr 192.168.1.2:20514' -
action may not work as intended
20200425-075516: MSG omrelp: could not connect to remote server, librelp
error 10015
20200425-075516: MSG action 'act.omrelp' suspended (module 'omrelp'),
retry 0. There should be messages before this one giving the reason for
suspension.
20200425-075516: MSG omrelp: could not connect to remote server, librelp
error 10015
20200425-075516: MSG action 'act.omrelp' suspended (module 'omrelp'),
retry 0. There should be messages before this one giving the reason for
suspension.
>From the sender's rsyslog.conf:
module(
load="omrelp"
)
ruleset(name="rst.omrelp"){
action(
name="act.omrelp"
type="omrelp"
target="192.168.1.2"
# port="601"
port="20514"
template="tpl.msg-basic"
action.errorFile="act.omrelp.error"
action.reportSuspension="on"
action.reportSuspensionContinuation="on"
action.resumeInterval="5"
action.resumeIntervalMax="30"
action.resumeRetryCount="-1"
queue.checkpointInterval="100"
queue.filename="relp.queue"
queue.highWatermark="600"
queue.lightDelayMark="0"
queue.lowWatermark="10"
queue.maxDiskSpace="15g"
queue.maxFilesize="10m"
queue.saveonshutdown="on"
queue.size="1000"
queue.spooldirectory="/var/log"
queue.syncqueuefiles="on"
queue.type="LinkedList"
tls="off"
)
call rst.omfile
}
input(
type="imuxsock"
ruleset="rst.omrelp"
socket="/run/systemd/journal/syslog"
)
PLATFORM
Ubuntu 16.04 (upgrade pending resolution hereof); rsyslog 8.2004.
Many thanks for any guidance.
-ERB
rsyslog.conf
Description: Binary data
_______________________________________________ rsyslog mailing list https://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.
