hi David,
I tried out your setup on Centos6 both with stock rsyslogd 5.8.10 and newer
7.5.3, and run into the same issue. In fact, no signals are ever delivered
to the sec process, and the signal handlers are not entered. If the process
runs from terminal (or as a daemon, receiving its input from a named pipe),
there are no issues with receiving signals. Since newer Perl versions use
safe signal handling model where signal delivery could be deferred, I also
tested sec with legacy model by setting PERL_SIGNALS environment variable
to "unsafe", but that does not change anything.
Oddly enough, signals are delivered normally when sec is forked from
syslog-ng and gets its events over a pipe (the setup which is identical to
rsyslog configuration, and described in
http://simple-evcorr.sourceforge.net/FAQ.html#3). At this point, I am
somewhat out of ideas, since the problem also appears on Fedora19 with
different major Perl version.
kind regards,
risto
2013/9/24 David Lang <[email protected]>
> On Mon, 23 Sep 2013, John P. Rouillard wrote:
>
> > In message <[email protected]>,
> > David Lang writes:
> >>>> On 09/19/2013 06:16 AM, David Lang wrote:
> >>>>> I've started running SEC from rsyslog via omprog and it's
> >>>>> running, but when it tries to write the dumpfile, nothing
> >>>>> happens.
> >>>>>
> >>>>> I did a cut-n-paste of the command line (as shown in ps) and
> >>>>> ran it from the command line and from there it does create
> >>>>> the dump file. the dump files are set to be written to /var/tmp
>
> Eric, please try this.
>
> > Try this:
> >
> > $ sh
> > $ trap '' USR1
> > $ sec (cut and paste of command line mentioned above)
> > $ kill -USR1 <sec PID>
> > $ exit
> >
> > I have a sneaking suspicion that something in SEC/perl isn't restoring
> > the signal handler if it's set to ignore in the parent process. What
> > the sequence above should do it ignore USR1 in the shell. Then you
> > test the SEC USR1 signal handiling.
> >
> > SEC uses the $SIG{} array to set the signal handlers, I am not sure if
> > the POSIX::sigaction stuff operates differently or is $SIG{} is
> > sigaction under the hood..
> >
> >> enabling the log file shows ongoing activity, but it does not show
> anything
> >> when the USR1 is sent to the pid.
> >
> > That's telling me that USR1 is being ignored somewhere in the process
> > chain. Can you confirm/deny that USR1 is ignored by the signal
> > handling in rsyslog?
>
> Rainer said:
>
> > I just checked, and omprog already resets the signal handlers. So this
> > cannot be the problem...
>
> David Lang
>
> P.S. this is going to be more interesting to figure out since today was my
> last
> day at this job. This is an interesting challenge, so I'm still going the
> help
> the guys who are still there, but I no longer have direct access to things
> there.
>
> I need to try and duplicate this problem on the Ubuntu machines I do have
> access
> to, but it will take me a couple days to get time to do so, so if Eric can
> check
> on the RHEL systems we can keep making progress.
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Simple-evcorr-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
