On Thu, Jun 20, 2013 at 12:25 PM, Risto Vaarandi <risto.vaara...@seb.ee>wrote:
> On 06/20/2013 12:15 PM, Rainer Gerhards wrote: > >> On Thu, Jun 20, 2013 at 11:13 AM, Rainer Gerhards >> <rgerha...@hq.adiscon.com>**wrote: >> >> >>> On Thu, Jun 20, 2013 at 11:10 AM, Risto Vaarandi<risto.vaara...@seb.ee** >>> >wrote: >>> >>> On 06/20/2013 11:31 AM, Rainer Gerhards wrote: >>>> >>>> On Wed, Jun 19, 2013 at 4:49 PM, David Lang<da...@lang.hm> wrote: >>>>> >>>>> On Wed, 19 Jun 2013, Rainer Gerhards wrote: >>>>> >>>>>> >>>>>> I have just checked the code and that is not intentional. I may >>>>>> have >>>>>> >>>>>> overlooked something, as omprog was originally writen to a user >>>>>>> request, >>>>>>> but that users disappeared when it was done and nobody else reported >>>>>>> much >>>>>>> on it. I think this is the right solution for external programs, and >>>>>>> so I >>>>>>> would be very happy to look into problems that the module may have. >>>>>>> >>>>>>> >>>>>>> I know that a restart of rsyslog will kill the program specified, >>>>>> >>>>>> >>>>> >>>>> it doesn't actively kill it, but the program will receive end-of-file >>>>> on >>>>> it's input. >>>>> >>>>> >>>>> will a HUP kill and restart the program? >>>>> >>>>>> >>>>>> >>>>>> no >>>>>> >>>>> >>>>> >>>> It is slightly off-topic, but since SEC was mentioned in this thread, >>>> then the current version will actually not terminate on EOF on pipe. It >>>> will terminate either on TERM from parent, or with a help of a special >>>> rule >>>> that would call exit(0) on no input. Since this is not very convenient >>>> for >>>> connecting SEC to rsyslog via memory-based pipe, the new version of SEC >>>> (currently ready and under testing) will have better support for >>>> receiving >>>> input over a pipe from rsyslog. >>>> >>>> >>> would it help if I add support to send SIGTERM? As of rsyslog policies, I >>> can ony do that in the devel, which means 7.5 branch. >>> >>> >> sorry, half-baked comment. My concern is if someone upgrades to the latest >> rsyslog devel, wouldn't he also upgrade to the latest sec, making this >> change a no-brainer? Or do we think it may be useful for other apps as >> well? >> > > Actually, the TERM approach would work nicely with all versions of sec, so > there is no strict need to upgrade it to the most recent version. > However, termination on EOF-on-pipe would only be available starting from > the next version of sec (hope to release it within two weeks). I would say > that SIGTERM support in rsyslog would be useful for people who for some > reason are running older version of sec and don't want to upgrade. This can > happen on more conservative distributions like Debian which might not > always have a recent version in the standard package repository, and the > user does not want to install sec from source. However, this raises another > question -- are such conservative distributions willing to offer the latest > version of rsyslog (the one with TERM support) from their standard > repositories? Definitely know, that was the prime point why I was considering if the modification would make sense. Both softwares would probably be rolled into their main archives at the same time. However, given David's reasoning, I think I'll look into adding this option for other apps as well (as time permits). Rainer > I fear that this might not always be the case, so the user would have to > bypass standard repositories anyway and do a custom installation. But when > custom installation has to be done, it is probably easier to just put the > newest sec version to place. > > So I would say that extra work just for the sake of sec would probably be > too much, and perhaps worth considering if it would be also beneficial for > a number of other applications. > > kind regards, > risto > > >> Rainer >> >> ______________________________**_________________ >> rsyslog mailing list >> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog> >> http://www.rsyslog.com/**professional-services/<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://lists.adiscon.net/mailman/listinfo/rsyslog> > http://www.rsyslog.com/**professional-services/<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.
