On Wed, 18 Oct 2017, deoren wrote:
On 10/18/2017 3:15 PM, David Lang wrote:
On Wed, 18 Oct 2017, deoren wrote:
On 10/18/2017 1:36 PM, David Lang wrote:
On Wed, 18 Oct 2017, deoren wrote:
Since the sender and receiver in this are both the latest versions of
rsyslog (with the plan for the set
On 10/18/2017 3:15 PM, David Lang wrote:
On Wed, 18 Oct 2017, deoren wrote:
On 10/18/2017 1:36 PM, David Lang wrote:
On Wed, 18 Oct 2017, deoren wrote:
Since the sender and receiver in this are both the latest versions
of rsyslog (with the plan for the setup to remain that way), can I
scale
On 10/18/2017 5:02 PM, deoren wrote:
On 10/18/2017 3:22 PM, Rainer Gerhards wrote:
The queue errors are bad. Anything else in regard to that queue?
After discussing it on this thread, I stopped rsyslog yesterday and
moved all content from /var/spool/rsyslog to a different directory,
hoping t
On 10/18/2017 12:34 PM, Rainer Gerhards wrote:
2017-10-18 1:14 GMT+02:00 deoren
:
On 10/17/2017 3:45 PM, Rainer Gerhards wrote:
Errno 11 seems to be EAGAIN, more a status than a warning. The full Debug
log may reveal details.
Is the debug on demand log file sufficient or should enabling deb
On 10/18/2017 3:22 PM, Rainer Gerhards wrote:
The queue errors are bad. Anything else in regard to that queue?
After discussing it on this thread, I stopped rsyslog yesterday and
moved all content from /var/spool/rsyslog to a different directory,
hoping to have rsyslog come back online with a
Thank you very much for your answer and explaination :)
Greetings, Sabine
Von meinem iPhone gesendet
> Am 17.10.2017 um 16:42 schrieb David Lang :
>
>> On Tue, 17 Oct 2017, emaleth wrote:
>>
>> Because it was still in the $Work Directory, it disappeared only after
>> restarting rsyslog.
>
>
The queue errors are bad. Anything else in regard to that queue?
The thread messages are informational and part of the better status
indicators. They say that the load was so high an additional worker thread
was started... And later shut down as it was no longer needed.
Rainer
Sent from phone, t
On Wed, 18 Oct 2017, deoren wrote:
On 10/18/2017 1:36 PM, David Lang wrote:
On Wed, 18 Oct 2017, deoren wrote:
Since the sender and receiver in this are both the latest versions of
rsyslog (with the plan for the setup to remain that way), can I scale the
accepted message size values to proper
On 10/18/2017 1:36 PM, David Lang wrote:
On Wed, 18 Oct 2017, deoren wrote:
I checked and sawmill1 is having trouble sending the messages on to
the "downstream" receivers (sawmill2, sawmill3). Based on the "... at
least 232 byte larger than max msg size ..." log entries, I'd guess
that mess
On Wed, 18 Oct 2017, deoren wrote:
I checked and sawmill1 is having trouble sending the messages on to the
"downstream" receivers (sawmill2, sawmill3). Based on the "... at least
232 byte larger than max msg size ..." log entries, I'd guess that
message size is causing the issue here.
I'm
2017-10-18 1:14 GMT+02:00 deoren
:
> On 10/17/2017 3:45 PM, Rainer Gerhards wrote:
>>
>> Errno 11 seems to be EAGAIN, more a status than a warning. The full Debug
>> log may reveal details.
>
>
> Is the debug on demand log file sufficient or should enabling debug mode at
> startup the better route?
On 10/18/2017 12:02 PM, deoren wrote:
On 10/18/2017 11:51 AM, deoren wrote:
On 10/17/2017 6:57 PM, David Lang wrote:
Yes, rsyslog will accept messages it can't deliver, the accepting of
messages is decoupled from the delivery.
if a message is too long, it will get ttruncated, even if it's jso
On 10/18/2017 11:51 AM, deoren wrote:
On 10/17/2017 6:57 PM, David Lang wrote:
Yes, rsyslog will accept messages it can't deliver, the accepting of
messages is decoupled from the delivery.
if a message is too long, it will get ttruncated, even if it's json
(at that point it's a string of byte
On 10/17/2017 6:57 PM, David Lang wrote:
Yes, rsyslog will accept messages it can't deliver, the accepting of
messages is decoupled from the delivery.
if a message is too long, it will get ttruncated, even if it's json (at
that point it's a string of bytes, rsyslog has no way of knowing that
We updated the RPMs. The libfastjson4 RPM that we provide should now
replace the libfastjson 0.99.4 that is provided through the base
repository.
Florian
2017-10-18 13:21 GMT+02:00 Cédric Jeanneret via rsyslog
:
> Apparently, a new libfastjson4 has been pushed and it replaces the
> libfastjson pa
Do you mean some logs were written to and some not?
If so, I need a Debug log to diagnose what is going on.
Rainer
Sent from phone, thus brief.
Am 18.10.2017 17:36 schrieb "Mike Schleif" :
> # cat /etc/centos-release
> CentOS Linux release 7.4.1708 (Core)
>
>
> After yum updates yesterday (see
# cat /etc/centos-release
CentOS Linux release 7.4.1708 (Core)
After yum updates yesterday (see below,) several logs no longer logged,
including /var/log/secure
In the last hour, we rolled back that entire yum update, and logging
appears to be as expected
Please, advise. Thank you.
~ Mike
#
Apparently, a new libfastjson4 has been pushed and it replaces the
libfastjson package. Just installing it did the trick, and rsyslog is
running as expected.
Thanks!
--
Cédric Jeanneret
Senior Linux System Administrator
Infrastructure Solutions
Camptocamp SA
PSE-A / EPFL, 1015 Lausanne
Phone:
2017-10-18 9:27 GMT+02:00 mostolog--- via rsyslog :
> It doesn't seem possible to exclude specific files when using directory
> wilcards too.
>
> eg: /logs/**/^{file_format_X.log}
** is NOT supported as it would require us to put inotify handles over
a very large directory set
imfile uses this fo
It doesn't seem possible to exclude specific files when using directory
wilcards too.
eg: /logs/**/^{file_format_X.log}
Perhaps http://www.linuxjournal.com/content/bash-extended-globbing could
do the trick, but i was wondering if there won't make more sense to use
REGEX or exclude paratemer
20 matches
Mail list logo
