Thanks for the confirmation! Rainer
2014-12-04 9:32 GMT+01:00 Kendall Green <[email protected]>: > 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 <[email protected] > > > 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 <[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. > > > _______________________________________________ > 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.
