Re: [rsyslog] Legacy FWD Failes on startup (v8)

[deoren]

On 11/9/2017 4:08 AM, Thomas Deutschmann via rsyslog wrote:

Hi,

no distribution will probably _require_ network for rsyslog per
default because in the default configuration distributions are
shipping, no network is required. Due to the fact that most init
systems nowadays support parallel invocation it isn't that easy to
depend on a working network setup. If you really do that, it will
cause degradation for systems without network connectivity -- that's
why you cannot do that per default in general.

It is (and was!) the system administrator's responsibility to adjust
dependencies if your configuration will _require_ network access.

In rsyslog-8.27 there was a change due to rsyslog required network all
the time but this was fixed in >=8.28
(https://github.com/rsyslog/rsyslog/commit/1a7d3a088969b47798bc1da712ca2
772f91a7c02).

 From reading this bug and others it sounds like rsyslog is having a
problem recovering from complete network outages including failed DNS
resolution.

Based on my own experience: When the omrelp target goes down it will
take some time (especially if there was no new log message on the
client) to re-establish a new connection to resume fwd action, but I
haven't seen any rsyslog client yet which was unable to automatically
resume after central logging server was rebooted for example.


I've had good results with clients resuming after the central logging 
server was restarted.



But based on the recent reports about the last 6 months this does
require more testing. I.e. a verification what will happen if rsyslogd
starts up but cannot resolve ommysql/omrelp target due to DNS error
which will be fixed _after_ rsyslogd was fired up. 


That is exactly the error that I've encountered. By introducing a 
dependency on network.target it appears that we're able to work around 
the problem with rsyslog not recovering from that initial situation.



Also, how does
rsyslogd reacts if an already resolved DNS target will go down: Does
rsyslog really tries to re-resolve the DNS name (i.e. picks up changed
IP addresses -- and not only in case of an error: what will happen if
TTL expires, does rsyslogd do proper lookups or only once at
startup/error case) or not. 


In the last month or so I had to migrate our central logging server from 
one subnet to another and as a result the A record for the system had to 
change. Prior to the change we reduced the TTL to 5 minutes and I found 
that once the central server came back online with the new the clients 
began sending messages over without any interaction necessary on my 
part. No restart of the daemon or box was necessary.


___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[Rainer Gerhards]

Just my 2cts quickly: I fully agree we need more tests/code review
especially on the DNS requery part. It's just so many things on the
todo list. I work very intensely on rsyslog since a couple of weeks
again, but I can't do anything. So one needs to either wait or
contribute (no bashing, just describing the situation and most
importantly wanted to agree that I think we need to look into this).

Rainer

2017-11-09 11:08 GMT+01:00 Thomas Deutschmann via rsyslog
:
> Hi,
>
> no distribution will probably _require_ network for rsyslog per
> default because in the default configuration distributions are
> shipping, no network is required. Due to the fact that most init
> systems nowadays support parallel invocation it isn't that easy to
> depend on a working network setup. If you really do that, it will
> cause degradation for systems without network connectivity -- that's
> why you cannot do that per default in general.
>
> It is (and was!) the system administrator's responsibility to adjust
> dependencies if your configuration will _require_ network access.
>
> In rsyslog-8.27 there was a change due to rsyslog required network all
> the time but this was fixed in >=8.28
> (https://github.com/rsyslog/rsyslog/commit/1a7d3a088969b47798bc1da712ca2
> 772f91a7c02).
>
> From reading this bug and others it sounds like rsyslog is having a
> problem recovering from complete network outages including failed DNS
> resolution.
>
> Based on my own experience: When the omrelp target goes down it will
> take some time (especially if there was no new log message on the
> client) to re-establish a new connection to resume fwd action, but I
> haven't seen any rsyslog client yet which was unable to automatically
> resume after central logging server was rebooted for example.
>
> But based on the recent reports about the last 6 months this does
> require more testing. I.e. a verification what will happen if rsyslogd
> starts up but cannot resolve ommysql/omrelp target due to DNS error
> which will be fixed _after_ rsyslogd was fired up. Also, how does
> rsyslogd reacts if an already resolved DNS target will go down: Does
> rsyslog really tries to re-resolve the DNS name (i.e. picks up changed
> IP addresses -- and not only in case of an error: what will happen if
> TTL expires, does rsyslogd do proper lookups or only once at
> startup/error case) or not. Also, is there a different when DNS isn't
> reachable at all vs replying erroneously with NXDOMAIN for some time...
>
> Maybe it is just a problem in the resume logic of some modules.
>
> Testing error conditions is quite hard.
>
>
> --
> Regards,
> Thomas
> ___
> 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.
___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[Thomas Deutschmann via rsyslog]

Hi,

no distribution will probably _require_ network for rsyslog per
default because in the default configuration distributions are
shipping, no network is required. Due to the fact that most init
systems nowadays support parallel invocation it isn't that easy to
depend on a working network setup. If you really do that, it will
cause degradation for systems without network connectivity -- that's
why you cannot do that per default in general.

It is (and was!) the system administrator's responsibility to adjust
dependencies if your configuration will _require_ network access.

In rsyslog-8.27 there was a change due to rsyslog required network all
the time but this was fixed in >=8.28
(https://github.com/rsyslog/rsyslog/commit/1a7d3a088969b47798bc1da712ca2
772f91a7c02).

>From reading this bug and others it sounds like rsyslog is having a
problem recovering from complete network outages including failed DNS
resolution.

Based on my own experience: When the omrelp target goes down it will
take some time (especially if there was no new log message on the
client) to re-establish a new connection to resume fwd action, but I
haven't seen any rsyslog client yet which was unable to automatically
resume after central logging server was rebooted for example.

But based on the recent reports about the last 6 months this does
require more testing. I.e. a verification what will happen if rsyslogd
starts up but cannot resolve ommysql/omrelp target due to DNS error
which will be fixed _after_ rsyslogd was fired up. Also, how does
rsyslogd reacts if an already resolved DNS target will go down: Does
rsyslog really tries to re-resolve the DNS name (i.e. picks up changed
IP addresses -- and not only in case of an error: what will happen if
TTL expires, does rsyslogd do proper lookups or only once at
startup/error case) or not. Also, is there a different when DNS isn't
reachable at all vs replying erroneously with NXDOMAIN for some time...

Maybe it is just a problem in the resume logic of some modules.

Testing error conditions is quite hard.


-- 
Regards,
Thomas
___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[deoren]

On 11/7/2017 12:25 PM, deoren wrote:

On 11/7/2017 10:31 AM, matthew.gaetano wrote:

With the exception of the relation to storage, yes, for the most part. We
encountered the issue on a physical server using SCSI/SATA drives. Our
secondary tester were in vmware.


I initially emphasized the boot speed from running the Ubuntu 16.04 VM 
on a SSD, but I believe the problem is mainly to do with the startup 
ordering of rsyslog and network support. I ended up working around the 
issue of rsyslog starting before network support was available by 
modifying the systemd unit with a conf fragment:


# /etc/systemd/system/rsyslog.service.d/10-wait-on-network.conf

[Unit]

After=network.target

It mostly works for us and appears to be what stock CentOS 7 is doing 
with their rsyslog package.


I went back and was unable to find an example where a distro-provided 
package is setting 'After=network.target' in the '[Unit]' section of a 
rsyslog.service or syslog.service unit file.


I'm sure I saw it somewhere, but checking these distros/versions I 
didn't spot it:


* Debian 8, 9
* RHEL 7
* CentOS 7
* Ubuntu 16.04

I'll keep looking.
___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[deoren]

On 11/7/2017 10:31 AM, matthew.gaetano wrote:

With the exception of the relation to storage, yes, for the most part. We
encountered the issue on a physical server using SCSI/SATA drives. Our
secondary tester were in vmware.


I initially emphasized the boot speed from running the Ubuntu 16.04 VM 
on a SSD, but I believe the problem is mainly to do with the startup 
ordering of rsyslog and network support. I ended up working around the 
issue of rsyslog starting before network support was available by 
modifying the systemd unit with a conf fragment:


# /etc/systemd/system/rsyslog.service.d/10-wait-on-network.conf

[Unit]

After=network.target

It mostly works for us and appears to be what stock CentOS 7 is doing 
with their rsyslog package.



It appears someone else has posted a similar issue already as well @
https://github.com/rsyslog/rsyslog/issues/1694


Thanks for linking to that GitHub issue. Their issue appears to be with 
omfwd while mine was with omrelp. Presumably the issue is "lower" down 
the stack than either module as David Lang indicated here:


https://github.com/rsyslog/rsyslog/issues/1694#issuecomment-319674827

___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[matthew.gaetano]

With the exception of the relation to storage, yes, for the most part. We
encountered the issue on a physical server using SCSI/SATA drives. Our
secondary tester were in vmware.

It appears someone else has posted a similar issue already as well @
https://github.com/rsyslog/rsyslog/issues/1694

~Regards



-
~Regards

Matthew Gaetano
--
Sent from: http://rsyslog-users.1305293.n2.nabble.com/
___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[deoren]

https://github.com/rsyslog/rsyslog/issues/1656

See if that matches what you are fighting with.

On November 7, 2017 9:51:51 AM CST, "matthew.gaetano"  
wrote:
>Queue's aside, regardless of the order rsyslog loads (before or after
>network) its retry function should not stall. As it currently stands
>under
>CentOS 7.x and Rsyslog v8.x if a configuration uses FQDNs rather than
>IPs
>and the rsyslog server starts prior to the network forwarding actions
>suspend and do not resume once the network comes up. Assuming no
>disagreement i will open a issue in github, if not already there.
>
>
>
>-
>~Regards
>
>Matthew Gaetano
>--
>Sent from: http://rsyslog-users.1305293.n2.nabble.com/
>___
>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.
___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[matthew.gaetano]

Queue's aside, regardless of the order rsyslog loads (before or after
network) its retry function should not stall. As it currently stands under
CentOS 7.x and Rsyslog v8.x if a configuration uses FQDNs rather than IPs
and the rsyslog server starts prior to the network forwarding actions
suspend and do not resume once the network comes up. Assuming no
disagreement i will open a issue in github, if not already there.



-
~Regards

Matthew Gaetano
--
Sent from: http://rsyslog-users.1305293.n2.nabble.com/
___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[David Lang]

On Tue, 31 Oct 2017, deoren wrote:


On 10/31/2017 4:05 PM, matthew.gaetano wrote:

Seems like your on the right track. We changed the dns names in the conf to
the destination IPs and this somewhat resolved the issue.

Rsyslog would still suspend the two destination actions however once the
system settled the actions were resumed. Since there is no queue setup the
messages from boot are not forwarded but new messages are sent. The same
behavior occurs when using the dns names in the conf but adding the
resolution to /etc/hosts.


Am I wrong in that messages are ordinarily lost if a queue has not been 
explicitly configured for a forwarding action?


if it's a reliable option (TCP/RELP/file/etc), then no. If there is no queue 
defined for that action then all log processing stops and the message is in the 
main queue.


If it's not a reliable options (UDP), then rsyslgo can't know to queue the 
message as it doesn't know that it wasn't delivered.


note that there are ways for logs to be lost with TCP delivery


Afterwards we edited the systemd service script to wait until after the
network started, same line as you had suggested
("/usr/lib/systemd/system/rsyslog.service"). This again somewhat resolved
the problem, though vice-versa from the previous tests. Instead we got what
appears to be most, if not all, the boot up logs as expected but instead we
did not see logs on shutdown/reboot.


Honestly, I don't know that the systemd conf fragment solved it for us, but 
the problem seems to occur much less often now. While troubleshooting other 
issues, I ended up enabling a persistent systemd journal so that it would 
retain messages before/after rsyslog comes online. It was useful in 
determining that rsyslog was killed by systemd after hitting a configured 
timeout value on more than one occasion. It would be interesting to know 
whether something similar is going on here.


If you've not done so, you enable persistent storage of your journal log 
files by creating the /var/log/journal directory. You then restart 
systemd-journal and it will start saving log details to disk. This will allow 
you to view messages regarding the shutdown of rsyslog and it starting up 
again.


this will also cause all logs to be written and read from disk, that may cause 
performance issues.


David Lang
___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[deoren]

On 10/31/2017 4:05 PM, matthew.gaetano wrote:

Seems like your on the right track. We changed the dns names in the conf to
the destination IPs and this somewhat resolved the issue.

Rsyslog would still suspend the two destination actions however once the
system settled the actions were resumed. Since there is no queue setup the
messages from boot are not forwarded but new messages are sent. The same
behavior occurs when using the dns names in the conf but adding the
resolution to /etc/hosts.


Am I wrong in that messages are ordinarily lost if a queue has not been 
explicitly configured for a forwarding action?



Afterwards we edited the systemd service script to wait until after the
network started, same line as you had suggested
("/usr/lib/systemd/system/rsyslog.service"). This again somewhat resolved
the problem, though vice-versa from the previous tests. Instead we got what
appears to be most, if not all, the boot up logs as expected but instead we
did not see logs on shutdown/reboot.


Honestly, I don't know that the systemd conf fragment solved it for us, 
but the problem seems to occur much less often now. While 
troubleshooting other issues, I ended up enabling a persistent systemd 
journal so that it would retain messages before/after rsyslog comes 
online. It was useful in determining that rsyslog was killed by systemd 
after hitting a configured timeout value on more than one occasion. It 
would be interesting to know whether something similar is going on here.


If you've not done so, you enable persistent storage of your journal log 
files by creating the /var/log/journal directory. You then restart 
systemd-journal and it will start saving log details to disk. This will 
allow you to view messages regarding the shutdown of rsyslog and it 
starting up again.



This still seems incorrect in direct comparison to v7. Note that the service
script for v7 includes the "After=network.target" - not sure if that is a
mistake and if its a RHEL or rsyslog concern.


I saw that the stock unit file had that entry as well when researching 
my problem. I don't know whether the official rsyslog RPMs contain a 
unit file or if those packages rely on the original provided by 
CentOS/RHEL to operate. I'd assume they have their own copy, but I 
didn't spot it when I briefly looked at the CentOS/RHEL packaging 
project contents:


https://github.com/rsyslog/rsyslog-pkg-rhel-centos
___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[matthew.gaetano]

Seems like your on the right track. We changed the dns names in the conf to
the destination IPs and this somewhat resolved the issue.

Rsyslog would still suspend the two destination actions however once the
system settled the actions were resumed. Since there is no queue setup the
messages from boot are not forwarded but new messages are sent. The same
behavior occurs when using the dns names in the conf but adding the
resolution to /etc/hosts.

Afterwards we edited the systemd service script to wait until after the
network started, same line as you had suggested
("/usr/lib/systemd/system/rsyslog.service"). This again somewhat resolved
the problem, though vice-versa from the previous tests. Instead we got what
appears to be most, if not all, the boot up logs as expected but instead we
did not see logs on shutdown/reboot.

This still seems incorrect in direct comparison to v7. Note that the service
script for v7 includes the "After=network.target" - not sure if that is a
mistake and if its a RHEL or rsyslog concern.

~Regards



-
~Regards

Matthew Gaetano
--
Sent from: http://rsyslog-users.1305293.n2.nabble.com/
___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[deoren]

On 10/31/2017 12:42 PM, matthew.gaetano wrote:

Hello,

I'm not sure this is an issue considering Legacy format shouldn't really be
used in version 8, however it seems that when using legacy forwarding (as
described in the default rsyslog.conf file) rsyslog suspends the actions and
never retries. This only occurs during system boot and if the service is
restarted after boot the issue is resolved. We have attempted to enable
debug during startup but cant seem to get it to function.

Rsyslog Version: 8.26 - 8.30
OS Version: CentOS 7.3.1611 (minimum)
syntax in question: *.* @mysyslogserver:514

Note that this came up because of an endpoint being updated from default
installation version of 7.x to latest.

Has anyone else experienced this?

Thanks

~Regards


Out of curiousity, have you specified the remote server via FQDN or IP 
Address?


I encountered an issue some months ago where rsyslog would startup and 
log messages locally, but fail to deliver them remotely. If I specified 
the remote receiver via IP Address or set an artificial delay for 
starting rsyslog, sending messages to the remote receiver worked as 
expected.


https://github.com/rsyslog/rsyslog/issues/1656

True, my situation was with Ubuntu 16.04 and RELP instead of CentOS and 
UDP as your circumstance involves, but I figured it was worth mentioning 
just in case my remarks are useful.


The hotfix I ended up going with was the artificial delay:

#1) Create a 
/etc/systemd/system/rsyslog.service.d/10-wait-on-network.conf file

#2) Include 'After=network.target' beneath a '[Unit]' section heading

Example with included comments:

[Unit]

# Append link to relevant ticket to the documentation list
Documentation=https://OUR_INTERNAL_SYSTEM/redmine/issues/TICKET_NUMBER_HERE

# rsyslog doesn't seem to gracefully handle lack of functioning name
# resolution when processing remote queues (specifically omrelp, but likely
# other network-dependent output modules also). Here we ask systemd to only
# start rsyslog once the network target has been started.
After=network.target

___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[matthew.gaetano]

Managed to get the debug to work. Attached is the log file as the system
boots, and then manual stopped.

rsyslog-process-debug.7z

  

~Regards



-
~Regards

Matthew Gaetano
--
Sent from: http://rsyslog-users.1305293.n2.nabble.com/
___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[matthew.gaetano]

I could if i can manage to figure out how to enable debug on startup. I've
tried adding the environment variables to "/etc/environment", roots
"./bash_profile" and attempted to edit the systemctl service file to include
them but without success. I'm not sure what I am doing wrong in that regard;
I've only ever used debug manually. 



-
~Regards

Matthew Gaetano
--
Sent from: http://rsyslog-users.1305293.n2.nabble.com/
___
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.

Re: [rsyslog] Legacy FWD Failes on startup (v8)

[Rainer Gerhards]

Can you provide a Debug log of such a case?

Sent from phone, thus brief.

Am 31.10.2017 18:42 schrieb "matthew.gaetano" :

> Hello,
>
> I'm not sure this is an issue considering Legacy format shouldn't really be
> used in version 8, however it seems that when using legacy forwarding (as
> described in the default rsyslog.conf file) rsyslog suspends the actions
> and
> never retries. This only occurs during system boot and if the service is
> restarted after boot the issue is resolved. We have attempted to enable
> debug during startup but cant seem to get it to function.
>
> Rsyslog Version: 8.26 - 8.30
> OS Version: CentOS 7.3.1611 (minimum)
> syntax in question: *.* @mysyslogserver:514
>
> Note that this came up because of an endpoint being updated from default
> installation version of 7.x to latest.
>
> Has anyone else experienced this?
>
> Thanks
>
> ~Regards
>
>
>
> -
> ~Regards
>
> Matthew Gaetano
> --
> Sent from: http://rsyslog-users.1305293.n2.nabble.com/
> ___
> 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.
>
___
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.