Re: [rsyslog] Question on DoDie
The (8.2 / 8.4) rsyslog service stop/restart issues on VMware instances appear to be resolved. Rsyslog 8.6.0-2 is functioning properly after upgrading to latest release. Thank you! On Wed, Dec 3, 2014 at 12:12 AM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: I have had now time to check the ChangeLog. There was a fix when imudp prevented shutdown. This is now part of 8.6.0. I could very well address what you describe. HTH Rainer 2014-12-02 23:04 GMT+01:00 Kendall Green kendallar...@gmail.com: To specifically answer the question, Are you saying that DebugOnDemand must be set for rsyslog to work properly? or that you are only trying to start it with that set? We've tried both service rsyslog start and /etc/init.d/rsyslog start, which rsyslog will appear to run properly, however shutdown does not work properly unless is started with /etc/init.d/rsyslog start while debug on demand env is set. Thus if started services from the init.d then execute service rsyslog restart, the system would appear to shutdown and startup properly, but the next stop action would fail to report in /var/log/messages as restart from 'service' script has same issue as the 'start' function. So Yes, debug on demand must be set then run by /etc/init.d/rsyslog start and restart, or the stop process is latent and without logging. Thank you for your help in isolating this obscure issue with rsyslog running on VMware instances with RHEL6.5. On Mon, Dec 1, 2014 at 6:17 PM, Kendall Green kendallar...@gmail.com wrote: In order for rsyslog to start/restart properly on VMware, the set env with export RSYSLOG_DEBUG=DebugOnDemand and directly execute /etc/init.d/rsyslog start, no special debug options, and if restart from service script it will fail to stop properly with exit status in /var/log/messages. When comparing ps -eZ |grep rsyslog, on physical server, kernel prefix the output, but the VM displays only a hyphen, '-' preceding pid information that is otherwise the same. Does this solution apply concerning vmware kdump: and the necessity for the debug variable? https://access.redhat.com/solutions/260003 So, VMware instance of RHEL6.5, rsyslog ps -eZ process does not appear to be owned by 'kernel', start/restart will display stop/exit status in /var/log/messages when /etc/init.d/rsyslog start is executed from root directly with debug on demand set. Is debug setting at all related to that rh solution?: - When hot-adding memory to a Red Hat Enterprise Linux system running in a vmware environment, the system may attempt to reload the kdump kernel and regenerate a new kdump initrd. On Mon, Dec 1, 2014 at 5:36 PM, David Lang da...@lang.hm wrote: If SELinux is disabled, you should be able to see any differences in how rsyslog is started by looking at the resulting command line with ps (or thorugh /proc) There has to be something different about the way they are being started if one works and the other doesn't. Are you saying that DebugOnDemand must be set for rsyslog to work properly? or that you are only trying to start it with that set? David Lang On Mon, 1 Dec 2014, Kendall Green wrote: Date: Mon, 1 Dec 2014 17:30:26 -0700 From: Kendall Green kendallar...@gmail.com Reply-To: rsyslog-users rsyslog@lists.adiscon.com To: rsyslog-users rsyslog@lists.adiscon.com Subject: Re: [rsyslog] Question on DoDie Verified SELinux is disabled on both VMware instance and baremetal installs, and no systemd, only the traditional service init functions. There doesn't appear to be any differences between the scripts: /etc/init.d/rsyslog and the /etc/rc.d/rc#.d/S12rsyslog There appears to be something ''unknown'' happening on vmware instance for service init, which could relate to the udev rules, kdump, being different from baremetal, or another aspect which makes a difference when setting DebugOnDemand and starting from /etc/init.d/rsyslog instead of service rsyslog start. Both methods of starting the rsyslog service appears to work, but will not stop and restart properly. However stop/start/restart will succeed consecutively, only when started by '/etc/init.d/rsyslog start' while DebugOnDemand value set for rsyslog debug env. Since it is consistently, only a problem on systems that are VMs on 8.2.2 and now 8.4.2, even with RHEL6.2 recently upgraded to RHEL6.5 and issue persists. Anyone have an answer to more specific difference between init.d/rsyslog start and service rsyslog start on RHEL6.x? Thanks! On Mon, Dec 1, 2014 at 2:36 PM, David Lang da...@lang.hm wrote: This sounds like it's more likely a problem with the service scripts/systemd config than with rsyslog itself. what is different between /etc/init.d/rsyslog start
Re: [rsyslog] Question on DoDie
Thanks for the confirmation! Rainer 2014-12-04 9:32 GMT+01:00 Kendall Green kendallar...@gmail.com: The (8.2 / 8.4) rsyslog service stop/restart issues on VMware instances appear to be resolved. Rsyslog 8.6.0-2 is functioning properly after upgrading to latest release. Thank you! On Wed, Dec 3, 2014 at 12:12 AM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: I have had now time to check the ChangeLog. There was a fix when imudp prevented shutdown. This is now part of 8.6.0. I could very well address what you describe. HTH Rainer 2014-12-02 23:04 GMT+01:00 Kendall Green kendallar...@gmail.com: To specifically answer the question, Are you saying that DebugOnDemand must be set for rsyslog to work properly? or that you are only trying to start it with that set? We've tried both service rsyslog start and /etc/init.d/rsyslog start, which rsyslog will appear to run properly, however shutdown does not work properly unless is started with /etc/init.d/rsyslog start while debug on demand env is set. Thus if started services from the init.d then execute service rsyslog restart, the system would appear to shutdown and startup properly, but the next stop action would fail to report in /var/log/messages as restart from 'service' script has same issue as the 'start' function. So Yes, debug on demand must be set then run by /etc/init.d/rsyslog start and restart, or the stop process is latent and without logging. Thank you for your help in isolating this obscure issue with rsyslog running on VMware instances with RHEL6.5. On Mon, Dec 1, 2014 at 6:17 PM, Kendall Green kendallar...@gmail.com wrote: In order for rsyslog to start/restart properly on VMware, the set env with export RSYSLOG_DEBUG=DebugOnDemand and directly execute /etc/init.d/rsyslog start, no special debug options, and if restart from service script it will fail to stop properly with exit status in /var/log/messages. When comparing ps -eZ |grep rsyslog, on physical server, kernel prefix the output, but the VM displays only a hyphen, '-' preceding pid information that is otherwise the same. Does this solution apply concerning vmware kdump: and the necessity for the debug variable? https://access.redhat.com/solutions/260003 So, VMware instance of RHEL6.5, rsyslog ps -eZ process does not appear to be owned by 'kernel', start/restart will display stop/exit status in /var/log/messages when /etc/init.d/rsyslog start is executed from root directly with debug on demand set. Is debug setting at all related to that rh solution?: - When hot-adding memory to a Red Hat Enterprise Linux system running in a vmware environment, the system may attempt to reload the kdump kernel and regenerate a new kdump initrd. On Mon, Dec 1, 2014 at 5:36 PM, David Lang da...@lang.hm wrote: If SELinux is disabled, you should be able to see any differences in how rsyslog is started by looking at the resulting command line with ps (or thorugh /proc) There has to be something different about the way they are being started if one works and the other doesn't. Are you saying that DebugOnDemand must be set for rsyslog to work properly? or that you are only trying to start it with that set? David Lang On Mon, 1 Dec 2014, Kendall Green wrote: Date: Mon, 1 Dec 2014 17:30:26 -0700 From: Kendall Green kendallar...@gmail.com Reply-To: rsyslog-users rsyslog@lists.adiscon.com To: rsyslog-users rsyslog@lists.adiscon.com Subject: Re: [rsyslog] Question on DoDie Verified SELinux is disabled on both VMware instance and baremetal installs, and no systemd, only the traditional service init functions. There doesn't appear to be any differences between the scripts: /etc/init.d/rsyslog and the /etc/rc.d/rc#.d/S12rsyslog There appears to be something ''unknown'' happening on vmware instance for service init, which could relate to the udev rules, kdump, being different from baremetal, or another aspect which makes a difference when setting DebugOnDemand and starting from /etc/init.d/rsyslog instead of service rsyslog start. Both methods of starting the rsyslog service appears to work, but will not stop and restart properly. However stop/start/restart will succeed consecutively, only when started by '/etc/init.d/rsyslog start' while DebugOnDemand value set for rsyslog debug env. Since it is consistently, only a problem on systems that are VMs on 8.2.2 and now 8.4.2, even with RHEL6.2 recently upgraded to RHEL6.5 and issue persists. Anyone have an answer to more specific difference between init.d/rsyslog start and service rsyslog start on RHEL6.x? Thanks
Re: [rsyslog] Question on DoDie
I have had now time to check the ChangeLog. There was a fix when imudp prevented shutdown. This is now part of 8.6.0. I could very well address what you describe. HTH Rainer 2014-12-02 23:04 GMT+01:00 Kendall Green kendallar...@gmail.com: To specifically answer the question, Are you saying that DebugOnDemand must be set for rsyslog to work properly? or that you are only trying to start it with that set? We've tried both service rsyslog start and /etc/init.d/rsyslog start, which rsyslog will appear to run properly, however shutdown does not work properly unless is started with /etc/init.d/rsyslog start while debug on demand env is set. Thus if started services from the init.d then execute service rsyslog restart, the system would appear to shutdown and startup properly, but the next stop action would fail to report in /var/log/messages as restart from 'service' script has same issue as the 'start' function. So Yes, debug on demand must be set then run by /etc/init.d/rsyslog start and restart, or the stop process is latent and without logging. Thank you for your help in isolating this obscure issue with rsyslog running on VMware instances with RHEL6.5. On Mon, Dec 1, 2014 at 6:17 PM, Kendall Green kendallar...@gmail.com wrote: In order for rsyslog to start/restart properly on VMware, the set env with export RSYSLOG_DEBUG=DebugOnDemand and directly execute /etc/init.d/rsyslog start, no special debug options, and if restart from service script it will fail to stop properly with exit status in /var/log/messages. When comparing ps -eZ |grep rsyslog, on physical server, kernel prefix the output, but the VM displays only a hyphen, '-' preceding pid information that is otherwise the same. Does this solution apply concerning vmware kdump: and the necessity for the debug variable? https://access.redhat.com/solutions/260003 So, VMware instance of RHEL6.5, rsyslog ps -eZ process does not appear to be owned by 'kernel', start/restart will display stop/exit status in /var/log/messages when /etc/init.d/rsyslog start is executed from root directly with debug on demand set. Is debug setting at all related to that rh solution?: - When hot-adding memory to a Red Hat Enterprise Linux system running in a vmware environment, the system may attempt to reload the kdump kernel and regenerate a new kdump initrd. On Mon, Dec 1, 2014 at 5:36 PM, David Lang da...@lang.hm wrote: If SELinux is disabled, you should be able to see any differences in how rsyslog is started by looking at the resulting command line with ps (or thorugh /proc) There has to be something different about the way they are being started if one works and the other doesn't. Are you saying that DebugOnDemand must be set for rsyslog to work properly? or that you are only trying to start it with that set? David Lang On Mon, 1 Dec 2014, Kendall Green wrote: Date: Mon, 1 Dec 2014 17:30:26 -0700 From: Kendall Green kendallar...@gmail.com Reply-To: rsyslog-users rsyslog@lists.adiscon.com To: rsyslog-users rsyslog@lists.adiscon.com Subject: Re: [rsyslog] Question on DoDie Verified SELinux is disabled on both VMware instance and baremetal installs, and no systemd, only the traditional service init functions. There doesn't appear to be any differences between the scripts: /etc/init.d/rsyslog and the /etc/rc.d/rc#.d/S12rsyslog There appears to be something ''unknown'' happening on vmware instance for service init, which could relate to the udev rules, kdump, being different from baremetal, or another aspect which makes a difference when setting DebugOnDemand and starting from /etc/init.d/rsyslog instead of service rsyslog start. Both methods of starting the rsyslog service appears to work, but will not stop and restart properly. However stop/start/restart will succeed consecutively, only when started by '/etc/init.d/rsyslog start' while DebugOnDemand value set for rsyslog debug env. Since it is consistently, only a problem on systems that are VMs on 8.2.2 and now 8.4.2, even with RHEL6.2 recently upgraded to RHEL6.5 and issue persists. Anyone have an answer to more specific difference between init.d/rsyslog start and service rsyslog start on RHEL6.x? Thanks! On Mon, Dec 1, 2014 at 2:36 PM, David Lang da...@lang.hm wrote: This sounds like it's more likely a problem with the service scripts/systemd config than with rsyslog itself. what is different between /etc/init.d/rsyslog start and service rsyslog start? is the command line any different? or are they started with different SELinux settings? David Lang On Mon, 1 Dec 2014, Kendall Green wrote: I have encountered similar issue which is repeatable when running RHEL6 on VMware instances, with RSyslog 8.4.2.ad1, where shutdown takes a very long time and does not report the exit signal
Re: [rsyslog] Question on DoDie
This sounds like it's more likely a problem with the service scripts/systemd config than with rsyslog itself. what is different between /etc/init.d/rsyslog start and service rsyslog start? is the command line any different? or are they started with different SELinux settings? David Lang On Mon, 1 Dec 2014, Kendall Green wrote: I have encountered similar issue which is repeatable when running RHEL6 on VMware instances, with RSyslog 8.4.2.ad1, where shutdown takes a very long time and does not report the exit signal to /var/log/messages as it does on baremetal installs. The issue is that rsyslog stop/exit message only appears in /var/log/messages if started/restarted from init.d/rsyslog when having rsyslog debug env value set DebugOnDemand. Running service rsyslog stop/start or restart will show the exit and start messages, but the next stop or restart will fail to report the exit/service stop message because rsyslog needs to be started by init, /etc/init.d/rsyslog start instead of service rsyslog start, along with the debugging on demand, present but inactive. Otherwise, when rsyslog is started without debugging, or from service rsyslog start, the stop / exit message is lost, and the slowdown indicates other issues with the shutdown/processes... Are these issues already corrected in the upcoming 8.6.0 release, with announcement of bug fix for shutdown issues when running with more than one thread, or support for RHEL7 systemd, backwards compatible with RHEL6 service rsyslog scripts? Thanks, Kendall On Fri, Jul 11, 2014 at 11:58 AM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: Just in case you have overlooked my message: i am waiting for a debug log. And... sorry if *I* overlooked a log you sent ;) Rainer Sent from phone, thus brief. ___ 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. ___ 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] Question on DoDie
Verified SELinux is disabled on both VMware instance and baremetal installs, and no systemd, only the traditional service init functions. There doesn't appear to be any differences between the scripts: /etc/init.d/rsyslog and the /etc/rc.d/rc#.d/S12rsyslog There appears to be something ''unknown'' happening on vmware instance for service init, which could relate to the udev rules, kdump, being different from baremetal, or another aspect which makes a difference when setting DebugOnDemand and starting from /etc/init.d/rsyslog instead of service rsyslog start. Both methods of starting the rsyslog service appears to work, but will not stop and restart properly. However stop/start/restart will succeed consecutively, only when started by '/etc/init.d/rsyslog start' while DebugOnDemand value set for rsyslog debug env. Since it is consistently, only a problem on systems that are VMs on 8.2.2 and now 8.4.2, even with RHEL6.2 recently upgraded to RHEL6.5 and issue persists. Anyone have an answer to more specific difference between init.d/rsyslog start and service rsyslog start on RHEL6.x? Thanks! On Mon, Dec 1, 2014 at 2:36 PM, David Lang da...@lang.hm wrote: This sounds like it's more likely a problem with the service scripts/systemd config than with rsyslog itself. what is different between /etc/init.d/rsyslog start and service rsyslog start? is the command line any different? or are they started with different SELinux settings? David Lang On Mon, 1 Dec 2014, Kendall Green wrote: I have encountered similar issue which is repeatable when running RHEL6 on VMware instances, with RSyslog 8.4.2.ad1, where shutdown takes a very long time and does not report the exit signal to /var/log/messages as it does on baremetal installs. The issue is that rsyslog stop/exit message only appears in /var/log/messages if started/restarted from init.d/rsyslog when having rsyslog debug env value set DebugOnDemand. Running service rsyslog stop/start or restart will show the exit and start messages, but the next stop or restart will fail to report the exit/service stop message because rsyslog needs to be started by init, /etc/init.d/rsyslog start instead of service rsyslog start, along with the debugging on demand, present but inactive. Otherwise, when rsyslog is started without debugging, or from service rsyslog start, the stop / exit message is lost, and the slowdown indicates other issues with the shutdown/processes... Are these issues already corrected in the upcoming 8.6.0 release, with announcement of bug fix for shutdown issues when running with more than one thread, or support for RHEL7 systemd, backwards compatible with RHEL6 service rsyslog scripts? Thanks, Kendall On Fri, Jul 11, 2014 at 11:58 AM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: Just in case you have overlooked my message: i am waiting for a debug log. And... sorry if *I* overlooked a log you sent ;) Rainer Sent from phone, thus brief. ___ 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. ___ 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] Question on DoDie
If SELinux is disabled, you should be able to see any differences in how rsyslog is started by looking at the resulting command line with ps (or thorugh /proc) There has to be something different about the way they are being started if one works and the other doesn't. Are you saying that DebugOnDemand must be set for rsyslog to work properly? or that you are only trying to start it with that set? David Lang On Mon, 1 Dec 2014, Kendall Green wrote: Date: Mon, 1 Dec 2014 17:30:26 -0700 From: Kendall Green kendallar...@gmail.com Reply-To: rsyslog-users rsyslog@lists.adiscon.com To: rsyslog-users rsyslog@lists.adiscon.com Subject: Re: [rsyslog] Question on DoDie Verified SELinux is disabled on both VMware instance and baremetal installs, and no systemd, only the traditional service init functions. There doesn't appear to be any differences between the scripts: /etc/init.d/rsyslog and the /etc/rc.d/rc#.d/S12rsyslog There appears to be something ''unknown'' happening on vmware instance for service init, which could relate to the udev rules, kdump, being different from baremetal, or another aspect which makes a difference when setting DebugOnDemand and starting from /etc/init.d/rsyslog instead of service rsyslog start. Both methods of starting the rsyslog service appears to work, but will not stop and restart properly. However stop/start/restart will succeed consecutively, only when started by '/etc/init.d/rsyslog start' while DebugOnDemand value set for rsyslog debug env. Since it is consistently, only a problem on systems that are VMs on 8.2.2 and now 8.4.2, even with RHEL6.2 recently upgraded to RHEL6.5 and issue persists. Anyone have an answer to more specific difference between init.d/rsyslog start and service rsyslog start on RHEL6.x? Thanks! On Mon, Dec 1, 2014 at 2:36 PM, David Lang da...@lang.hm wrote: This sounds like it's more likely a problem with the service scripts/systemd config than with rsyslog itself. what is different between /etc/init.d/rsyslog start and service rsyslog start? is the command line any different? or are they started with different SELinux settings? David Lang On Mon, 1 Dec 2014, Kendall Green wrote: I have encountered similar issue which is repeatable when running RHEL6 on VMware instances, with RSyslog 8.4.2.ad1, where shutdown takes a very long time and does not report the exit signal to /var/log/messages as it does on baremetal installs. The issue is that rsyslog stop/exit message only appears in /var/log/messages if started/restarted from init.d/rsyslog when having rsyslog debug env value set DebugOnDemand. Running service rsyslog stop/start or restart will show the exit and start messages, but the next stop or restart will fail to report the exit/service stop message because rsyslog needs to be started by init, /etc/init.d/rsyslog start instead of service rsyslog start, along with the debugging on demand, present but inactive. Otherwise, when rsyslog is started without debugging, or from service rsyslog start, the stop / exit message is lost, and the slowdown indicates other issues with the shutdown/processes... Are these issues already corrected in the upcoming 8.6.0 release, with announcement of bug fix for shutdown issues when running with more than one thread, or support for RHEL7 systemd, backwards compatible with RHEL6 service rsyslog scripts? Thanks, Kendall On Fri, Jul 11, 2014 at 11:58 AM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: Just in case you have overlooked my message: i am waiting for a debug log. And... sorry if *I* overlooked a log you sent ;) Rainer Sent from phone, thus brief. ___ 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. ___ 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
Re: [rsyslog] Question on DoDie
In order for rsyslog to start/restart properly on VMware, the set env with export RSYSLOG_DEBUG=DebugOnDemand and directly execute /etc/init.d/rsyslog start, no special debug options, and if restart from service script it will fail to stop properly with exit status in /var/log/messages. When comparing ps -eZ |grep rsyslog, on physical server, kernel prefix the output, but the VM displays only a hyphen, '-' preceding pid information that is otherwise the same. Does this solution apply concerning vmware kdump: and the necessity for the debug variable? https://access.redhat.com/solutions/260003 So, VMware instance of RHEL6.5, rsyslog ps -eZ process does not appear to be owned by 'kernel', start/restart will display stop/exit status in /var/log/messages when /etc/init.d/rsyslog start is executed from root directly with debug on demand set. Is debug setting at all related to that rh solution?: - When hot-adding memory to a Red Hat Enterprise Linux system running in a vmware environment, the system may attempt to reload the kdump kernel and regenerate a new kdump initrd. On Mon, Dec 1, 2014 at 5:36 PM, David Lang da...@lang.hm wrote: If SELinux is disabled, you should be able to see any differences in how rsyslog is started by looking at the resulting command line with ps (or thorugh /proc) There has to be something different about the way they are being started if one works and the other doesn't. Are you saying that DebugOnDemand must be set for rsyslog to work properly? or that you are only trying to start it with that set? David Lang On Mon, 1 Dec 2014, Kendall Green wrote: Date: Mon, 1 Dec 2014 17:30:26 -0700 From: Kendall Green kendallar...@gmail.com Reply-To: rsyslog-users rsyslog@lists.adiscon.com To: rsyslog-users rsyslog@lists.adiscon.com Subject: Re: [rsyslog] Question on DoDie Verified SELinux is disabled on both VMware instance and baremetal installs, and no systemd, only the traditional service init functions. There doesn't appear to be any differences between the scripts: /etc/init.d/rsyslog and the /etc/rc.d/rc#.d/S12rsyslog There appears to be something ''unknown'' happening on vmware instance for service init, which could relate to the udev rules, kdump, being different from baremetal, or another aspect which makes a difference when setting DebugOnDemand and starting from /etc/init.d/rsyslog instead of service rsyslog start. Both methods of starting the rsyslog service appears to work, but will not stop and restart properly. However stop/start/restart will succeed consecutively, only when started by '/etc/init.d/rsyslog start' while DebugOnDemand value set for rsyslog debug env. Since it is consistently, only a problem on systems that are VMs on 8.2.2 and now 8.4.2, even with RHEL6.2 recently upgraded to RHEL6.5 and issue persists. Anyone have an answer to more specific difference between init.d/rsyslog start and service rsyslog start on RHEL6.x? Thanks! On Mon, Dec 1, 2014 at 2:36 PM, David Lang da...@lang.hm wrote: This sounds like it's more likely a problem with the service scripts/systemd config than with rsyslog itself. what is different between /etc/init.d/rsyslog start and service rsyslog start? is the command line any different? or are they started with different SELinux settings? David Lang On Mon, 1 Dec 2014, Kendall Green wrote: I have encountered similar issue which is repeatable when running RHEL6 on VMware instances, with RSyslog 8.4.2.ad1, where shutdown takes a very long time and does not report the exit signal to /var/log/messages as it does on baremetal installs. The issue is that rsyslog stop/exit message only appears in /var/log/messages if started/restarted from init.d/rsyslog when having rsyslog debug env value set DebugOnDemand. Running service rsyslog stop/start or restart will show the exit and start messages, but the next stop or restart will fail to report the exit/service stop message because rsyslog needs to be started by init, /etc/init.d/rsyslog start instead of service rsyslog start, along with the debugging on demand, present but inactive. Otherwise, when rsyslog is started without debugging, or from service rsyslog start, the stop / exit message is lost, and the slowdown indicates other issues with the shutdown/processes... Are these issues already corrected in the upcoming 8.6.0 release, with announcement of bug fix for shutdown issues when running with more than one thread, or support for RHEL7 systemd, backwards compatible with RHEL6 service rsyslog scripts? Thanks, Kendall On Fri, Jul 11, 2014 at 11:58 AM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: Just in case you have overlooked my message: i am waiting for a debug log. And... sorry if *I* overlooked a log you sent ;) Rainer Sent from phone, thus brief. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo
Re: [rsyslog] Question on DoDie
Just in case you have overlooked my message: i am waiting for a debug log. And... sorry if *I* overlooked a log you sent ;) Rainer Sent from phone, thus brief. ___ 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] Question on DoDie
They are indeed VMs using a shared storage methodology in a state-lite configuration. That being said, up until this point I'd seen normal behavior out of 7.6.2 but as soon as we jumped to 8.2.1 I noticed inconsistent behavior on my VM servers. (On baremetal hosts I do not seem to encounter this same issue.) In addition I've gone through the rigor of removing all of the packages from the prior versions for a 'fresh start' approach and have observed the same behavior even after installation. In my case all of the systems observed are considered identical platforms (VMs on shared infrastructure) and in the 3 instances that were upgraded I experienced very similar issues regarding the exit status messages being omitted or the 'DoDie' message being printed instead. With regards to the 'service rsyslog restart' command, the only way that the init script was successfully able to start/stop was when there was a 'sleep .3' inserted between the start and stop stanza's under restart. If executing 'service rsyslog stop' and then start independently the service reported back the status of 'ok' each time (the exception being that process exit messages were still being omitted from the /var/log/messages file) On Mon, Jul 7, 2014 at 1:58 PM, David Lang da...@lang.hm wrote: The problem is that there's not much that rsyslog can do. It can't write to the files (they are owned by the old copy) It can't write to the old copy (it's shutdown it's input as it's trying to stop cleanly) It can't reliably write to stderr because most of the distro startup scripts capture this output and don't show it to the user (this is probably what's happening when you find that it's waiting for user input but doesn't show any prompt and you need to control-c to get out) now, you say this is new behavior for you, so what changed? are you using a different version, different storage? are these VMs? David Lang On Mon, 7 Jul 2014, Nick Syslog wrote: Either way completely hanging service restart on the start and not emitting exit signals to log files as well as the dodie message in place of the exit message seems a bit more complex than just a simple hang... Especially since this behavior was previously un observed and reproduced on 3 different identical hosts including one with a 'base' install. On Sat, Jul 5, 2014 at 4:11 PM, David Lang da...@lang.hm wrote: On Thu, 3 Jul 2014, Nick Syslog wrote: I've upgraded my VMWare based hosts to 8.2.2 recently and have had some weird phenomena that I can't seemingly explain from the previous installation...specifically: OS: RHEL 6.3 -Starting/stopping the service using service rsyslog restart hangs unless a sleep is inserted between the stop/start execution in the init. remember that the stop signal does not instantly kill rsyslog, it just sends it a message asking it to shutdown gracefully, not corrupting anything in the meantime. This means that rsylog works to flush the messages it has in queues, close files cleanly, etc. There is a timeout in the rsyslog config that tells it that if it hasn't finished after X seconds, abandon the remaining queue messages and just close things. If the start happens while rsyslog is still in the process of shutting down, it finds that there is already a pidfile in place (meaning that the process is either still running, or crashed) and it asks the user if it should go ahead and start or not (because if it is already running, having two copies manipulating the same files will cause interesting results) David Lang The service appears to still start but the message OK is never released back to the cli leaving the user to ctrl-c to exit. -Messages for exit signal 15 (normal shutdown messages) have disappeared completely leaving only the 'start' messages in their place and in some cases the message DoDie Called. appears immediately prior to a start event. ___ 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] Question on DoDie
I'm not sure who is maintaining the init scripts for RHEL/CentOS6 (isn't that upstart?) We should get them to weigh in here. if you were to do killall rsyslogd; /usr/bin/rsyslogd I would expect that you will see the saem thing. With shared storage between the VMs, I would expect that it would take longer to flush the queues, so you would be more likely to run into this problem than on bare metal. unfortunantly, when you run service rsyslog start, teh Ok is being generated by the initscript, not by rsyslog. Was the only thing changed in the upgrade the rsyslog version? David Lang On Tue, 8 Jul 2014, Nick Syslog wrote: They are indeed VMs using a shared storage methodology in a state-lite configuration. That being said, up until this point I'd seen normal behavior out of 7.6.2 but as soon as we jumped to 8.2.1 I noticed inconsistent behavior on my VM servers. (On baremetal hosts I do not seem to encounter this same issue.) In addition I've gone through the rigor of removing all of the packages from the prior versions for a 'fresh start' approach and have observed the same behavior even after installation. In my case all of the systems observed are considered identical platforms (VMs on shared infrastructure) and in the 3 instances that were upgraded I experienced very similar issues regarding the exit status messages being omitted or the 'DoDie' message being printed instead. With regards to the 'service rsyslog restart' command, the only way that the init script was successfully able to start/stop was when there was a 'sleep .3' inserted between the start and stop stanza's under restart. If executing 'service rsyslog stop' and then start independently the service reported back the status of 'ok' each time (the exception being that process exit messages were still being omitted from the /var/log/messages file) On Mon, Jul 7, 2014 at 1:58 PM, David Lang da...@lang.hm wrote: The problem is that there's not much that rsyslog can do. It can't write to the files (they are owned by the old copy) It can't write to the old copy (it's shutdown it's input as it's trying to stop cleanly) It can't reliably write to stderr because most of the distro startup scripts capture this output and don't show it to the user (this is probably what's happening when you find that it's waiting for user input but doesn't show any prompt and you need to control-c to get out) now, you say this is new behavior for you, so what changed? are you using a different version, different storage? are these VMs? David Lang On Mon, 7 Jul 2014, Nick Syslog wrote: Either way completely hanging service restart on the start and not emitting exit signals to log files as well as the dodie message in place of the exit message seems a bit more complex than just a simple hang... Especially since this behavior was previously un observed and reproduced on 3 different identical hosts including one with a 'base' install. On Sat, Jul 5, 2014 at 4:11 PM, David Lang da...@lang.hm wrote: On Thu, 3 Jul 2014, Nick Syslog wrote: I've upgraded my VMWare based hosts to 8.2.2 recently and have had some weird phenomena that I can't seemingly explain from the previous installation...specifically: OS: RHEL 6.3 -Starting/stopping the service using service rsyslog restart hangs unless a sleep is inserted between the stop/start execution in the init. remember that the stop signal does not instantly kill rsyslog, it just sends it a message asking it to shutdown gracefully, not corrupting anything in the meantime. This means that rsylog works to flush the messages it has in queues, close files cleanly, etc. There is a timeout in the rsyslog config that tells it that if it hasn't finished after X seconds, abandon the remaining queue messages and just close things. If the start happens while rsyslog is still in the process of shutting down, it finds that there is already a pidfile in place (meaning that the process is either still running, or crashed) and it asks the user if it should go ahead and start or not (because if it is already running, having two copies manipulating the same files will cause interesting results) David Lang The service appears to still start but the message OK is never released back to the cli leaving the user to ctrl-c to exit. -Messages for exit signal 15 (normal shutdown messages) have disappeared completely leaving only the 'start' messages in their place and in some cases the message DoDie Called. appears immediately prior to a start event. ___ 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
Re: [rsyslog] Question on DoDie
Correct, the only thing changed was the rsyslog version. I know it's strange and understand it's controlled by init, but to me it's very odd that the hang is so deviant when there is literally no saveonshutdown, no queues, it's a vanilla install in at least 2 instances. I figured it bared mentioning given the issues mentioned previously on a VM instance (in the 7.6.X stability thread.) Ultimately I can live with the ok messages and putting in a sleep between my init script 'restart' function, what REALLY bothers me though is the case of the missing exit messages. On my baremetal hosts I get the exit messages, etc. without incident, on my VM hosts however, that message seems to almost be non-existant (or in my case will RARELY generate the dodie message prior to seeing the 'start' message) So in summary, I can live with the init, but the lack of standard process exit information I'm used to seeing on all prior versions (and currently see on baremetal 8.2.X) concerns me that there is other information that just isn't being processed correctly. On Tue, Jul 8, 2014 at 5:57 PM, David Lang da...@lang.hm wrote: I'm not sure who is maintaining the init scripts for RHEL/CentOS6 (isn't that upstart?) We should get them to weigh in here. if you were to do killall rsyslogd; /usr/bin/rsyslogd I would expect that you will see the saem thing. With shared storage between the VMs, I would expect that it would take longer to flush the queues, so you would be more likely to run into this problem than on bare metal. unfortunantly, when you run service rsyslog start, teh Ok is being generated by the initscript, not by rsyslog. Was the only thing changed in the upgrade the rsyslog version? David Lang On Tue, 8 Jul 2014, Nick Syslog wrote: They are indeed VMs using a shared storage methodology in a state-lite configuration. That being said, up until this point I'd seen normal behavior out of 7.6.2 but as soon as we jumped to 8.2.1 I noticed inconsistent behavior on my VM servers. (On baremetal hosts I do not seem to encounter this same issue.) In addition I've gone through the rigor of removing all of the packages from the prior versions for a 'fresh start' approach and have observed the same behavior even after installation. In my case all of the systems observed are considered identical platforms (VMs on shared infrastructure) and in the 3 instances that were upgraded I experienced very similar issues regarding the exit status messages being omitted or the 'DoDie' message being printed instead. With regards to the 'service rsyslog restart' command, the only way that the init script was successfully able to start/stop was when there was a 'sleep .3' inserted between the start and stop stanza's under restart. If executing 'service rsyslog stop' and then start independently the service reported back the status of 'ok' each time (the exception being that process exit messages were still being omitted from the /var/log/messages file) On Mon, Jul 7, 2014 at 1:58 PM, David Lang da...@lang.hm wrote: The problem is that there's not much that rsyslog can do. It can't write to the files (they are owned by the old copy) It can't write to the old copy (it's shutdown it's input as it's trying to stop cleanly) It can't reliably write to stderr because most of the distro startup scripts capture this output and don't show it to the user (this is probably what's happening when you find that it's waiting for user input but doesn't show any prompt and you need to control-c to get out) now, you say this is new behavior for you, so what changed? are you using a different version, different storage? are these VMs? David Lang On Mon, 7 Jul 2014, Nick Syslog wrote: Either way completely hanging service restart on the start and not emitting exit signals to log files as well as the dodie message in place of the exit message seems a bit more complex than just a simple hang... Especially since this behavior was previously un observed and reproduced on 3 different identical hosts including one with a 'base' install. On Sat, Jul 5, 2014 at 4:11 PM, David Lang da...@lang.hm wrote: On Thu, 3 Jul 2014, Nick Syslog wrote: I've upgraded my VMWare based hosts to 8.2.2 recently and have had some weird phenomena that I can't seemingly explain from the previous installation...specifically: OS: RHEL 6.3 -Starting/stopping the service using service rsyslog restart hangs unless a sleep is inserted between the stop/start execution in the init. remember that the stop signal does not instantly kill rsyslog, it just sends it a message asking it to shutdown gracefully, not corrupting anything in the meantime. This means that rsylog works to flush the messages it has in queues, close files cleanly, etc. There is a timeout in the rsyslog config that tells it that if it hasn't finished after X seconds, abandon the remaining queue messages and just close
Re: [rsyslog] Question on DoDie
Either way completely hanging service restart on the start and not emitting exit signals to log files as well as the dodie message in place of the exit message seems a bit more complex than just a simple hang... Especially since this behavior was previously un observed and reproduced on 3 different identical hosts including one with a 'base' install. On Sat, Jul 5, 2014 at 4:11 PM, David Lang da...@lang.hm wrote: On Thu, 3 Jul 2014, Nick Syslog wrote: I've upgraded my VMWare based hosts to 8.2.2 recently and have had some weird phenomena that I can't seemingly explain from the previous installation...specifically: OS: RHEL 6.3 -Starting/stopping the service using service rsyslog restart hangs unless a sleep is inserted between the stop/start execution in the init. remember that the stop signal does not instantly kill rsyslog, it just sends it a message asking it to shutdown gracefully, not corrupting anything in the meantime. This means that rsylog works to flush the messages it has in queues, close files cleanly, etc. There is a timeout in the rsyslog config that tells it that if it hasn't finished after X seconds, abandon the remaining queue messages and just close things. If the start happens while rsyslog is still in the process of shutting down, it finds that there is already a pidfile in place (meaning that the process is either still running, or crashed) and it asks the user if it should go ahead and start or not (because if it is already running, having two copies manipulating the same files will cause interesting results) David Lang The service appears to still start but the message OK is never released back to the cli leaving the user to ctrl-c to exit. -Messages for exit signal 15 (normal shutdown messages) have disappeared completely leaving only the 'start' messages in their place and in some cases the message DoDie Called. appears immediately prior to a start event. ___ 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. ___ 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] Question on DoDie
The problem is that there's not much that rsyslog can do. It can't write to the files (they are owned by the old copy) It can't write to the old copy (it's shutdown it's input as it's trying to stop cleanly) It can't reliably write to stderr because most of the distro startup scripts capture this output and don't show it to the user (this is probably what's happening when you find that it's waiting for user input but doesn't show any prompt and you need to control-c to get out) now, you say this is new behavior for you, so what changed? are you using a different version, different storage? are these VMs? David Lang On Mon, 7 Jul 2014, Nick Syslog wrote: Either way completely hanging service restart on the start and not emitting exit signals to log files as well as the dodie message in place of the exit message seems a bit more complex than just a simple hang... Especially since this behavior was previously un observed and reproduced on 3 different identical hosts including one with a 'base' install. On Sat, Jul 5, 2014 at 4:11 PM, David Lang da...@lang.hm wrote: On Thu, 3 Jul 2014, Nick Syslog wrote: I've upgraded my VMWare based hosts to 8.2.2 recently and have had some weird phenomena that I can't seemingly explain from the previous installation...specifically: OS: RHEL 6.3 -Starting/stopping the service using service rsyslog restart hangs unless a sleep is inserted between the stop/start execution in the init. remember that the stop signal does not instantly kill rsyslog, it just sends it a message asking it to shutdown gracefully, not corrupting anything in the meantime. This means that rsylog works to flush the messages it has in queues, close files cleanly, etc. There is a timeout in the rsyslog config that tells it that if it hasn't finished after X seconds, abandon the remaining queue messages and just close things. If the start happens while rsyslog is still in the process of shutting down, it finds that there is already a pidfile in place (meaning that the process is either still running, or crashed) and it asks the user if it should go ahead and start or not (because if it is already running, having two copies manipulating the same files will cause interesting results) David Lang The service appears to still start but the message OK is never released back to the cli leaving the user to ctrl-c to exit. -Messages for exit signal 15 (normal shutdown messages) have disappeared completely leaving only the 'start' messages in their place and in some cases the message DoDie Called. appears immediately prior to a start event. ___ 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] Question on DoDie
On Thu, 3 Jul 2014, Nick Syslog wrote: I've upgraded my VMWare based hosts to 8.2.2 recently and have had some weird phenomena that I can't seemingly explain from the previous installation...specifically: OS: RHEL 6.3 -Starting/stopping the service using service rsyslog restart hangs unless a sleep is inserted between the stop/start execution in the init. remember that the stop signal does not instantly kill rsyslog, it just sends it a message asking it to shutdown gracefully, not corrupting anything in the meantime. This means that rsylog works to flush the messages it has in queues, close files cleanly, etc. There is a timeout in the rsyslog config that tells it that if it hasn't finished after X seconds, abandon the remaining queue messages and just close things. If the start happens while rsyslog is still in the process of shutting down, it finds that there is already a pidfile in place (meaning that the process is either still running, or crashed) and it asks the user if it should go ahead and start or not (because if it is already running, having two copies manipulating the same files will cause interesting results) David Lang The service appears to still start but the message OK is never released back to the cli leaving the user to ctrl-c to exit. -Messages for exit signal 15 (normal shutdown messages) have disappeared completely leaving only the 'start' messages in their place and in some cases the message DoDie Called. appears immediately prior to a start event. ___ 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] Question on DoDie
This sounds indeed strange. Can you send me a debug log? Rainer On Thu, Jul 3, 2014 at 11:21 PM, Nick Syslog rsys...@nanoscopic.net wrote: I've upgraded my VMWare based hosts to 8.2.2 recently and have had some weird phenomena that I can't seemingly explain from the previous installation...specifically: OS: RHEL 6.3 -Starting/stopping the service using service rsyslog restart hangs unless a sleep is inserted between the stop/start execution in the init. The service appears to still start but the message OK is never released back to the cli leaving the user to ctrl-c to exit. -Messages for exit signal 15 (normal shutdown messages) have disappeared completely leaving only the 'start' messages in their place and in some cases the message DoDie Called. appears immediately prior to a start event. ___ 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.
[rsyslog] Question on DoDie
I've upgraded my VMWare based hosts to 8.2.2 recently and have had some weird phenomena that I can't seemingly explain from the previous installation...specifically: OS: RHEL 6.3 -Starting/stopping the service using service rsyslog restart hangs unless a sleep is inserted between the stop/start execution in the init. The service appears to still start but the message OK is never released back to the cli leaving the user to ctrl-c to exit. -Messages for exit signal 15 (normal shutdown messages) have disappeared completely leaving only the 'start' messages in their place and in some cases the message DoDie Called. appears immediately prior to a start event. ___ 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.
