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 <[email protected]>: > 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. > _______________________________________________ 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.
