Mailing List Archive: Logging issue using facility local3

Logging issue using facility local3

Mar 19, 2021, 4:22 PM

Post #1 of 3 (366 views)

I have a rule as follows that will not work if I attempt to use the
symbolic representation for local3 facility. I can change the priority to
anything I want and it will not log to either the local logfile nor will it
be forwarded to the remote server.

local3.* {
action(type="omfwd" target="10.40.46.198" port="10514"
protocol="tcp")
action(type="omfile" file="/var/log/local3.log")
}

However, If I instead use the numeric equivalent value for local3
(LOG_LOCAL3=19) from syslog.h, it works fine, logging to both the local
file as well as forwarding to my remote server.

19.* {
action(type="omfwd" target="10.40.46.198" port="10514"
protocol="tcp")
action(type="omfile" file="/var/log/local3.log")
}

Has anyone else experienced this issue?

I'm running rsyslog version:
rsyslogd 8.24.0-34.el7, compiled with:
PLATFORM: x86_64-redhat-linux-gnu
PLATFORM (lsb_release -d):
FEATURE_REGEXP: Yes
GSSAPI Kerberos 5 support: Yes
FEATURE_DEBUG (debug build, slow code): No
32bit Atomic operations supported: Yes
64bit Atomic operations supported: Yes
memory allocator: system default
Runtime Instrumentation (slow code): No
uuid support: Yes
Number of Bits in RainerScript integers: 64

thanks,

*Scott Slattery*

*Sr. Systems & Cloud Architect*

*Cloud, Compute, Information & Architecture Team*

motorolasolutions.com

*O: 602.529.8226*

*E*: Scott.Slattery@MotorolaSolutions.com

--

*For more information on how and why we collect your personal
information, please visit our Privacy Policy
<https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7&elqaid=2786&elqat=2#privacystatement>.*
_______________________________________________
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.

Re: Logging issue using facility local3 [ In reply to ]

rsyslog at lists

Mar 19, 2021, 5:34 PM

Post #2 of 3 (366 views)

Permalink

8.24 is about a 4 year old version (with some backported fixes by RedHat) that
is no longer supported by the community. Please try a more up to date vesion

That said, I have never seen the 19.* format used before, so I'm surprised that
it works.

I would suggest logging the problem messages with the template
RSYSLOG_DebugFormat as there is probably something in the log entry that is not
what you are thinking that it is.

David Lang

On Fri, 19 Mar 2021, Scott Slattery via rsyslog wrote:

> Date: Fri, 19 Mar 2021 16:22:21 -0700
> From: Scott Slattery via rsyslog <rsyslog@lists.adiscon.com>
> To: rsyslog-users <rsyslog@lists.adiscon.com>
> Cc: Scott Slattery <scott.slattery@motorolasolutions.com>
> Subject: [rsyslog] Logging issue using facility local3
>
> I have a rule as follows that will not work if I attempt to use the
> symbolic representation for local3 facility. I can change the priority to
> anything I want and it will not log to either the local logfile nor will it
> be forwarded to the remote server.
>
> local3.* {
> action(type="omfwd" target="10.40.46.198" port="10514"
> protocol="tcp")
> action(type="omfile" file="/var/log/local3.log")
> }
>
> However, If I instead use the numeric equivalent value for local3
> (LOG_LOCAL3=19) from syslog.h, it works fine, logging to both the local
> file as well as forwarding to my remote server.
>
> 19.* {
> action(type="omfwd" target="10.40.46.198" port="10514"
> protocol="tcp")
> action(type="omfile" file="/var/log/local3.log")
> }
>
> Has anyone else experienced this issue?
>
> I'm running rsyslog version:
> rsyslogd 8.24.0-34.el7, compiled with:
> PLATFORM: x86_64-redhat-linux-gnu
> PLATFORM (lsb_release -d):
> FEATURE_REGEXP: Yes
> GSSAPI Kerberos 5 support: Yes
> FEATURE_DEBUG (debug build, slow code): No
> 32bit Atomic operations supported: Yes
> 64bit Atomic operations supported: Yes
> memory allocator: system default
> Runtime Instrumentation (slow code): No
> uuid support: Yes
> Number of Bits in RainerScript integers: 64
>
> thanks,
>
> *Scott Slattery*
>
> *Sr. Systems & Cloud Architect*
>
> *Cloud, Compute, Information & Architecture Team*
>
> motorolasolutions.com
>
> *O: 602.529.8226*
>
> *E*: Scott.Slattery@MotorolaSolutions.com
>
>
_______________________________________________
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.

Re: Logging issue using facility local3 [ In reply to ]

rsyslog at lists

Mar 22, 2021, 9:30 AM

Post #3 of 3 (366 views)

Permalink

Thanks David, I'll upgrade the version and see if that resolves the issue.
With respect to the numeric facility code use, I do recall reading in the
documentation pretty log ago they are both equally supported. My only
reason for actually doing it in this case was to confirm if the symbolic
facility name vs the numeric one worked the same way. I would never
advocate sticking with the numeric codes since it's too esoteric and not
well understood easily.

I appreciate your feedback.

*Scott Slattery*

*Sr. Systems & Cloud Architect*

*Cloud, Compute, Information & Architecture Team*

motorolasolutions.com

*O: 602.529.8226*

*E*: Scott.Slattery@MotorolaSolutions.com

On Fri, Mar 19, 2021 at 5:34 PM David Lang <david@lang.hm> wrote:

> 8.24 is about a 4 year old version (with some backported fixes by RedHat)
> that
> is no longer supported by the community. Please try a more up to date
> vesion
>
> That said, I have never seen the 19.* format used before, so I'm surprised
> that
> it works.
>
> I would suggest logging the problem messages with the template
> RSYSLOG_DebugFormat as there is probably something in the log entry that
> is not
> what you are thinking that it is.
>
> David Lang
>
> On Fri, 19 Mar 2021, Scott Slattery via rsyslog wrote:
>
> > Date: Fri, 19 Mar 2021 16:22:21 -0700
> > From: Scott Slattery via rsyslog <rsyslog@lists.adiscon.com>
> > To: rsyslog-users <rsyslog@lists.adiscon.com>
> > Cc: Scott Slattery <scott.slattery@motorolasolutions.com>
> > Subject: [rsyslog] Logging issue using facility local3
> >
> > I have a rule as follows that will not work if I attempt to use the
> > symbolic representation for local3 facility. I can change the priority to
> > anything I want and it will not log to either the local logfile nor will
> it
> > be forwarded to the remote server.
> >
> > local3.* {
> > action(type="omfwd" target="10.40.46.198" port="10514"
> > protocol="tcp")
> > action(type="omfile" file="/var/log/local3.log")
> > }
> >
> > However, If I instead use the numeric equivalent value for local3
> > (LOG_LOCAL3=19) from syslog.h, it works fine, logging to both the local
> > file as well as forwarding to my remote server.
> >
> > 19.* {
> > action(type="omfwd" target="10.40.46.198" port="10514"
> > protocol="tcp")
> > action(type="omfile" file="/var/log/local3.log")
> > }
> >
> > Has anyone else experienced this issue?
> >
> > I'm running rsyslog version:
> > rsyslogd 8.24.0-34.el7, compiled with:
> > PLATFORM: x86_64-redhat-linux-gnu
> > PLATFORM (lsb_release -d):
> > FEATURE_REGEXP: Yes
> > GSSAPI Kerberos 5 support: Yes
> > FEATURE_DEBUG (debug build, slow code): No
> > 32bit Atomic operations supported: Yes
> > 64bit Atomic operations supported: Yes
> > memory allocator: system default
> > Runtime Instrumentation (slow code): No
> > uuid support: Yes
> > Number of Bits in RainerScript integers: 64
> >
> > thanks,
> >
> > *Scott Slattery*
> >
> > *Sr. Systems & Cloud Architect*
> >
> > *Cloud, Compute, Information & Architecture Team*
> >
> > motorolasolutions.com
> >
> > *O: 602.529.8226*
> >
> > *E*: Scott.Slattery@MotorolaSolutions.com
> >
> >
>

--

*For more information on how and why we collect your personal
information, please visit our Privacy Policy
<https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7&elqaid=2786&elqat=2#privacystatement>.*
_______________________________________________
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.