On Tue, Jan 14, 2014 at 5:06 PM, Nick Syslog <[email protected]> wrote:
> Comparing the init.d/rsyslog scripts between 7.4.7 and 7.4.8 I found: > > 7.4.7 (Line 51): > killproc -p "$(PIDFILE)" $exec > > 7.4.8 (Line 51): > killproc -p "$(PIDFILE)" -t30 $exec > > After removing the -t30 line I was able to see what I would consider > "normal operation" (OK after both stopping and starting when issuing > restart.) The issue when the -t30 is present and initiating a restart is > that the start appears to never occur due to the artificial wait. > > Manually starting and manually stopping had no issues. > > > Per the killproc manpage: > > > *-t<sec>* > The number *<sec>* specifies the seconds to wait > between the sent signal *SIGTERM* and the subsequen > tially signal *SIGKILL* if the first *SIGTERM* does not > show any result within the first few milli seconds. > This defaults to *5* seconds. > > mmhhh... that's a bit of a problem. 5 seconds is not a lot of time for shutdown if rsyslog is configured to persist queues to disk, write to databases or do log file signatures ... and similar slow outputs. If we really kill it after 5 seconds, a lot of trouble can occur. So I think this change was intentional (at least I know I just did exactly this to the Ubuntu upstart config). The description sounds a bit crazy, though. It waits that long if it does not terminate with the first few milli seconds? That doesn't sound right, why not wait until it terminates within the timeout window... I think this is what Ubuntu does. Maybe it's not possible with init? Feedback on how to handle this is appreciated. Again, there are a large number of use cases where the default timeout of 5 seconds is clearly insufficient. Rainer > > > > On Tue, Jan 14, 2014 at 12:04 AM, Rainer Gerhards > <[email protected]>wrote: > > > On Mon, Jan 13, 2014 at 10:40 PM, David Lang <[email protected]> wrote: > > > > > I guess the question is what init scripts are you using to do this. I'm > > > not sure syslog maintains the scripts instead of the distro. > > > > > > > > We actually cloned what the distro has, but in the longer term, we need > to > > maintain them ourselves -- at least as far as usual defaults (config > files) > > etc are concerned. Right now, it's plainly taken from distro, but maybe > we > > missed an update ;) > > > > Rainer > > > > > > > are you using the init scripts from the adiscon repository or from > > > somewhere else? > > > > > > David Lang > > > > > > On Mon, 13 Jan 2014, Nick Syslog wrote: > > > > > > Date: Mon, 13 Jan 2014 14:16:29 -0700 > > >> From: Nick Syslog <[email protected]> > > >> Reply-To: rsyslog-users <[email protected]> > > >> To: rsyslog-users <[email protected]> > > >> Subject: [rsyslog] Service/Init issue in RHEL packages for 7.4.8-1? > > >> > > >> > > >> Has anyone else noticed that the service/init starts on version 7.4.8 > > >> typically don't obey standard protocol for starting and stopping the > > >> service? > > >> > > >> Most often I use 'service rsyslog restart' and in my recent cases in > > >> development and elsewhere I am seeing that the service STOPS but I > have > > to > > >> manually execute a "service start rsyslog" after that command to get > > >> rsyslog to come online again. > > >> > > >> I've also seen quirks where it will fail to stop or start at all using > > the > > >> init/service scripts. > > >> > > >> Is this a known bug already or am I just unlucky? > > >> > > >> Running RHEL 6.4 with rsyslog 7.4.8-1 > > >> _______________________________________________ > > >> 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.
