John,
thanks for the comment. The only aspect which made me consider this are
tools which receive data from sec over named pipes. Prior to the 2.7
version, sec 'write' action opened and closed the pipe at each write which
was not very efficient. In the current major release, sec keeps its output
files (and sockets, which appeared in 2.7) constantly open, until:
1) sec terminates
2) a signal is received which forces outputs to be closed and reopened
(SIGHUP, SIGABRT or SIGUSR2)
If the pipe is closed, the reading end will see EOF in the pipe. By
default, a number of UNIX commandline tools (like cat and logger) terminate
on EOF. This creates an opportunity to control the lifetime of such
processes not only via SIGTERM, but also through a pipe. For example, the
following rule keeps the /bin/logger tool running during sec's lifetime, so
that the process shuts down when sec terminates, and a new process is
spawned when a signal closes /var/log/pipe and takes down the process:
type=Single
ptype=regexp
pattern=^(SEC_STARTUP|SEC_RESTART|SEC_SOFTRESTART|SEC_LOGROTATE)$
context=SEC_INTERNAL_EVENT
desc=(Re)start a process on pipe which logs its input to syslog
action=shellcmd /usr/bin/logger -f /var/log/pipe -p user.notice
(this ruleset uses the new SEC_LOGROTATE internal event which is
implemented in the 2.7.4 test version and is issued on the reception of
SIGUSR2)
In principle, SIGTERM is not really needed for such processes. As far as I
know, common syslog server implementations generally don't support signals
for managing child processes and solely rely on EOF-on-pipe approach. And
that made me thinking whether it is reasonable to retain the current
default if there is now also an alternative. (Of course, by far not all
processes have a pipe connection to sec, and SIGTERM is really the only way
to terminate such processes at shutdown.)
I hope my reasoning about alternatives makes sense :)
kind regards,
risto
2013/6/11 John P. Rouillard <rou...@cs.umb.edu>
>
> In message <51b73dbc.30...@seb.ee>,
> Risto Vaarandi writes:
> >in the most recent version, I've also included new commandline options
> >--childterm and --nochildterm which define if child processes will get
> >the SIGTERM signal when sec terminates. Up to the last version, SIGTERM
> >was always issued which was useful for taking down long running
> >processes not receiving data from sec over a pipe.
> >I was wondering if it would be wise to make --nochildterm the default?
> >On one hand, it differs from the current default (always deliver the
> >signal), but on the other hand, it might not be necessary in many cases.
> >Any opinions on that?
>
> I think I would leave the default at --childterm. I can't think of any
> time I would want a process started from SEC to stay alive when the
> parent SEC goes away. I don't like leaving orphaned processes
> around. If somebody wants to leave the child process running after SEC
> terminates they can catch the TERM signal and ignore it.
>
> Sending a TERM to a process that already exited is a no-op so there is
> no down side to sending the signal.
>
> --
> -- rouilj
> John Rouillard
> ===========================================================================
> My employers don't acknowledge my existence much less my opinions.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
