On 06/11/2013 07:45 PM, John P. Rouillard wrote: > > In message > <CAGfjSCP7eBy4r9f=tXNqhXuUttTQhm2_AwMF5L_Jb9ZUD=2...@mail.gmail.com> , > Risto Vaarandi writes: >> 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 :) > > Yeah I figured it was related to the change in pipe handling. As long > as the exit process is: > > close all pipes > wait a few (milli, centi) seconds for children to exit on EOF > reap any such children > TERM any remaining children > > I think you are fine letting SEC term any children. If the TERM comes > before the EOF, I would change it to allow the more graceful shutdown > using EOF first. >
I was thinking about a small delay, but there is just one very minor issue. Since apart from shutdowns the TERM signal is also sent on full restarts (triggered by HUP), that delay would actually happen in the middle of processing. In the case of shutdown it is not really a problem, of course. I was just wondering how to tackle this in the case of full restart, since quite a lot of data might arrive when a sleep between EOF and TERM is taking place. kind regards, risto > -- > -- 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
