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.
