On 2017-01-30 08:22, Risto Vaarandi wrote: > hi all, > > I am working on the next sec release and would like get some feedback > from end users, since I've implemented some changes in the beta code > of the next release. > > Previous versions of sec have ignored the PIPE signal in specific > parts of the code (such as functions which write to tcp and udp > sockets). Unfortunately, this still leaves the danger of getting this > signal when it is not expected. For example, if sec is not running as > a daemon and its standard error is connected to pipe, an unexpected > perl warning will produce SIGPIPE if the reader has disappeared on > pipe. In the new release, PIPE signal is ignored globally in all parts > of the code. Would that change be ok with the users? (SIGPIPE handler > is set back to default when child processes are forked.) > > Another change involves the creation of child processes for the 'pipe' > action. Previous versions of sec used the Perl pipe open for forking a > process: > open(PIPE, "| cmd"). > Also, the exit code of the child process was collected with blocking > close(PIPE). > Unfortunately, when the child process receives the TERM signal which > interrupts blocking close() and calls exit(), recent Perl versions > produce a warning "refcnt: fd -1 < 0", since exit() calls close() for > the second time for pipe descriptor. In order to avoid this warning, > the 'pipe' action is now implemented through lower level calls to > pipe(), fork(), exec() and waitpid(). Are there any special > considerations while someone might still prefer a higher level pipe > open? > > I am also considering raising the default value for the --blocksize > option (it is currently 1024 which means that sec attempts to read > from input files by 1KB blocks). Are there any objections if the > default is raised to 8KB or 16KB? > > Finally, while most users are letting sec to load its rule files as US > ASCII data, there might still be cases when unicode IO is activated > for sec (e.g., with env PERL_UNICODE=SAD /usr/bin/sec > --conf=test.rules ...).Previous versions of sec have used the \d > regular expression construct for verifying the numeric rule fields, > but this passes other characters than just 0-9, since with unicode > exotic digit symbols also match \d. However, usually they don't > receive proper interpretation and perl converts them to just 0. To > prevent the accidental use of such exotic digits, \d has been > exchanged for [0-9] which only matches meaningful numerals. Can anyone > think of possible caveats here? (Characters 0..9 are adjacent in both > ascii and ebcdic and thus the list [0-9] covers all ten digits for > them, but can anyone recall some exotic character sets where this is > not the case?) > > kind regards, > risto
Looks good here. And thank you for a FANTASTIC application. James ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
