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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> Reply-To: rsyslog-users <[email protected]> >>> To: rsyslog-users <[email protected]> >>> 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 <[email protected]> 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 < >>>>> [email protected]> >>>>> 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. >>> >>> _______________________________________________ >> 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.
