hi,
I had a look at this fragment, originally present in the code:
/* reset signal handlers to default */
156 memset(&sigAct, 0, sizeof(sigAct));
157 sigfillset(&sigAct.sa_mask);
158 sigAct.sa_handler = SIG_DFL;
159 for(i = 1 ; i < NSIG ; ++i)
160 sigaction(i, &sigAct, NULL);
There are two caveats here -- firstly, instead of sigfillset() I would use
sigemptyset(), since sigAct.sa_mask specifies the signals which are
deferred.
Secondly, during testing I found that for some reason the list of blocked
signals remains set:
cat /proc/7166/status | grep SigBlk
...
SigBlk: fffffffe7febfeff
...
In order to prevent this, I also called sigprocmask() immediately before
alarm() and execve(). My resulting test code therefore looks roughly as
follows:
/* reset signal handlers to default */
memset(&sigAct, 0, sizeof(sigAct));
sigAct.sa_handler = SIG_DFL;
sigemptyset(&sigAct.sa_mask);
sigAct.sa_flags = NULL;
for(i = 1 ; i < NSIG ; ++i)
sigaction(i, &sigAct, NULL);
sigemptyset(&set);
sigprocmask(SIG_SETMASK, &set, NULL);
With this code, a forked process has an empty list of blocked signals:
cat /proc/6072/status
...
SigBlk: 0000000000000000
...
and signals produce expected effect when sent to the process.
I am not sure if the above code will work as a patch, since I have only
checked its local effects and not sure that there are no unwanted side
effects.
kind regards,
risto
2013/9/25 David Lang <[email protected]>
> trying to combine threads. Yes, this is being called via omprog
>
> From Rainer
>
> Does anybody see anything wrong here?
>>
>> http://git.adiscon.com/?p=**rsyslog.git;a=blob;f=plugins/**
>> omprog/omprog.c;h=**940ef8d72d049126bba0d1394b7dfa**
>> fd95c884b2;hb=HEAD#l155<http://git.adiscon.com/?p=rsyslog.git;a=blob;f=plugins/omprog/omprog.c;h=940ef8d72d049126bba0d1394b7dfafd95c884b2;hb=HEAD#l155>
>>
>> I assume it's called via omprog?
>>
>> Rainer
>>
>
>
>
> On Tue, 24 Sep 2013, Risto Vaarandi wrote:
>
>
>> hi David,
>> today afternoon, I did couple of additional tests and connected /bin/cat
>> to
>> rsyslog. After creating such setup, I observed the same thing -- the
>> /bin/cat process does not respond to signals and can be taken down only
>> with SIGKILL. Apart from SIGTERM, I also tried SIGSEGV and SIGFPE which
>> should all terminate 'cat', but this does not happen.
>> kind regards,
>> risto
>>
>>
>> 2013/9/24 David Lang <[email protected]>
>>
>> On Mon, 23 Sep 2013, John P. Rouillard wrote:
>>>
>>> In message
>>> <alpine.DEB.2.02.**1309231617340.25499@nftneq.**ynat.uz<[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<http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk>
>>> ______________________________**_________________
>>> Simple-evcorr-users mailing list
>>> Simple-evcorr-users@lists.**sourceforge.net<[email protected]>
>>> https://lists.sourceforge.net/**lists/listinfo/simple-evcorr-**users<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
