On 06/20/2013 12:15 PM, Rainer Gerhards wrote:
On Thu, Jun 20, 2013 at 11:13 AM, Rainer Gerhards
<[email protected]>wrote:
On Thu, Jun 20, 2013 at 11:10 AM, Risto Vaarandi<[email protected]>wrote:
On 06/20/2013 11:31 AM, Rainer Gerhards wrote:
On Wed, Jun 19, 2013 at 4:49 PM, David Lang<[email protected]> 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? 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://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.
