Hi,
I have a patch(added some syslogs), which reproduces this problem each
time you start controller in any one of the middleware component.
Thanks
-Nagu
-----Original Message-----
From: Nagendra Kumar
Sent: 12 August 2013 09:30
To: Anders Bjornerstedt; Anders Widell
Cc: [email protected]; [email protected]
Subject: Re: [devel] [PATCH 1 of 1] leap: ncs_os_process_execute_timed child
process takes too long time before exec (#514)
Hi,
I agree with Anders. We had reproduced last week only with syslog
addition 1. between fork and exec, 2 Few syslog in main thread of leap.
So, to me, it looks like a bug in syslog(when added between fork and exec).
Thanks
-Nagu
-----Original Message-----
From: Anders Bjornerstedt [mailto:[email protected]]
Sent: 09 August 2013 13:54
To: Anders Widell
Cc: [email protected]; [email protected]
Subject: Re: [devel] [PATCH 1 of 1] leap: ncs_os_process_execute_timed child
process takes too long time before exec (#514)
WE have had several inciudents/problems causeed by syslog messages inside
signal handlers.
So I guess its not so surprising that you could get problems between fork and
exec.
/AndersBj
Anders Widell wrote:
> Wow, this was news to me. Ok then we must go through all functions we
> use after fork() and check that they are safe.
>
> So do we know if syslog() in general can block (if we disregard the
> case when it is used after fork(), which apparently is a illegal).
>
> regards,
> Anders Widell
>
> 2013-08-09 09:17, Hans Feldt skrev:
>
>> Yeah it seems that syslog in a child between fork() and exec() is unsecure.
>> Googling reveals this:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454183
>>
>> In search for #514 a syslog entry was added between fork() and exec() that
>> increased the likeliness of this to happen. The remaining syslogs between
>> fork() and exec() are for error cases. I guess those need to be stderr
>> prints. The problem is that stderr is closed in the child...
>> We need to come up with a way to have stderr available in some
>> trouble shooting scenarios
>>
>> /HansF
>>
>>
>>> -----Original Message-----
>>> From: Hans Nordebäck
>>> Sent: den 9 augusti 2013 09:04
>>> To: praveen malviya; Nagendra Kumar; Ramesh Babu Betham; Hans Feldt
>>> Cc: [email protected]; Anders Widell
>>> Subject: Re: SV: [PATCH 1 of 1] leap: ncs_os_process_execute_timed
>>> child process takes too long time before exec (#514)
>>>
>>> Hi, we got feedback from one site with the alarm patch applied (#532).
>>> In this case it hangs when calling syslog:
>>>
>>> #0 0x00007f03b0b9db35 in raise () from /lib64/libc.so.6
>>> #0 0x00007f03b0b9db35 in raise () from /lib64/libc.so.6
>>> #1 0x00007f03b0b9f111 in abort () from /lib64/libc.so.6
>>> #2 0x00007f03b1e1dd99 in sigalrm_handler (sig=5928) at os_defs.c:79
>>> #3 <signal handler called>
>>> #4 0x00007f03b0c51dac in __lll_lock_wait_private () from
>>> /lib64/libc.so.6
>>> #5 0x00007f03b0c04e0d in _L_lock_1598 () from /lib64/libc.so.6
>>> #6 0x00007f03b0c04bc6 in __tz_convert () from /lib64/libc.so.6
>>> #7 0x00007f03b0c40f6a in __vsyslog_chk () from /lib64/libc.so.6
>>> #8 0x00007f03b0c415b0 in syslog () from /lib64/libc.so.6
>>> #9 0x00007f03b1e1e992 in ncs_os_process_execute_timed
>>> (req=0x7fff10644ef0) at os_defs.c:1086
>>> #10 0x0000000000416d03 in avnd_comp_clc_cmd_execute (cb=0x6578c0,
>>> comp=0x67f680,
>>> cmd_type=AVND_COMP_CLC_CMD_TYPE_INSTANTIATE) at avnd_clc.c:2702
>>> #11 0x000000000041a810 in avnd_comp_clc_uninst_inst_hdler
>>> (cb=0x6578c0, comp=0x67f680) at avnd_clc.c:1384
>>> #12 0x00000000004187fb in avnd_comp_clc_fsm_run (cb=0x6578c0,
>>> comp=0x67f680, ev=AVND_COMP_CLC_PRES_FSM_EV_INST) at
>>> avnd_clc.c:874
>>> #13 0x000000000043438f in avnd_su_pres_insting_compinst_hdler
>>> (cb=0x6578c0, su=0x676380, comp=0x680750) at avnd_susm.c:1759
>>> #14 0x0000000000435bc4 in avnd_su_pres_fsm_run (cb=0x6578c0,
>>> su=0x676380, comp=0x680750,
>>> ev=AVND_SU_PRES_FSM_EV_COMP_INSTANTIATED) at avnd_susm.c:1293
>>> #15 0x00000000004175cb in avnd_comp_clc_st_chng_prc (cb=0x6578c0,
>>> comp=0x680750, prv_st=SA_AMF_PRESENCE_INSTANTIATING,
>>> final_st=SA_AMF_PRESENCE_INSTANTIATED) at avnd_clc.c:1313
>>> #16 0x000000000041888f in avnd_comp_clc_fsm_run (cb=0x6578c0,
>>> comp=0x680750,
>>> ev=AVND_COMP_CLC_PRES_FSM_EV_INST_SUCC) at avnd_clc.c:897
>>> #17 0x000000000041adb8 in avnd_evt_clc_resp_evh (cb=0x6578c0,
>>> evt=0x67d0e0) at avnd_clc.c:446
>>> #18 0x00000000004300e0 in avnd_evt_process (evt=<optimized out>) at
>>> avnd_proc.c:278
>>> #19 avnd_main_process () at avnd_proc.c:219
>>> #20 0x0000000000408815 in main (argc=1, argv=0x7fff10645988) at
>>> amfnd_main.c:61
>>>
>>>
>>> /HansN
>>>
>>> On 08/06/13 09:34, praveen malviya wrote:
>>>
>>>> Hi,
>>>> I added a new syslog entry(to debug) before execv and was
>>>> able to reproduce the problem.
>>>> The reason for the time out seems to be that syslog was *hung*, but
>>>> *after* writing the new log message into /var/log/messages.
>>>> So, there is a high possibility that the child process gets hung in
>>>> syslog or other file operations.
>>>> See bt below:
>>>> Thread 1 (Thread 0x7f030a16f700 (LWP 16331)):
>>>>
>>>> #0 0x00007f0308de4b1e in __lll_lock_wait_private () from
>>>> /lib64/libc.so.6
>>>> #1 0x00007f0308dd4398 in _L_lock_634 () from /lib64/libc.so.6
>>>> #2 0x00007f0308dd3e62 in __vsyslog_chk () from /lib64/libc.so.6
>>>> #3 0x00007f0308dd4320 in syslog () from /lib64/libc.so.6
>>>> #4 0x00007f0309d38feb in ncs_os_process_execute_timed
>>>> (req=0x7fffdcc52770, flag=false) at os_defs.c:1059
>>>> #5 0x0000000000416bd6 in avnd_comp_clc_cmd_execute (cb=0x6578a0,
>>>> comp=0x673840, cmd_type=AVND_COMP_CLC_CMD_TYPE_INSTANTIATE)
>>>> at avnd_clc.c:2687
>>>> #6 0x000000000041a630 in avnd_comp_clc_uninst_inst_hdler
>>>> (cb=0x6578a0, comp=0x673840) at avnd_clc.c:1384
>>>> #7 0x000000000041865b in avnd_comp_clc_fsm_run (cb=0x6578a0,
>>>> comp=0x673840, ev=AVND_COMP_CLC_PRES_FSM_EV_INST)
>>>> at avnd_clc.c:874
>>>> #8 0x0000000000433f5f in avnd_su_pres_insting_compinst_hdler
>>>> (cb=0x6578a0, su=0x66fc70, comp=0x674e10) at avnd_susm.c:1759
>>>> #9 0x0000000000435764 in avnd_su_pres_fsm_run (cb=0x6578a0,
>>>> su=0x66fc70, comp=0x674e10,
>>>> ev=AVND_SU_PRES_FSM_EV_COMP_INSTANTIATED) at avnd_susm.c:1293
>>>> #10 0x000000000041748b in avnd_comp_clc_st_chng_prc (cb=0x6578a0,
>>>> comp=0x674e10, prv_st=SA_AMF_PRESENCE_INSTANTIATING,
>>>> final_st=SA_AMF_PRESENCE_INSTANTIATED) at avnd_clc.c:1313
>>>> #11 0x00000000004186ef in avnd_comp_clc_fsm_run (cb=0x6578a0,
>>>> comp=0x674e10, ev=AVND_COMP_CLC_PRES_FSM_EV_INST_SUCC)
>>>> at avnd_clc.c:897
>>>> #12 0x000000000041f400 in avnd_comp_reg_prc (cb=0x6578a0,
>>>> comp=0x674e10, pxy_comp=<optimized out>, reg=0x677528,
>>>> dest=0x677518) at avnd_comp.c:709
>>>> #13 0x000000000041fbd7 in avnd_evt_ava_comp_reg_evh (cb=0x6578a0,
>>>> evt=0x683530) at avnd_comp.c:212
>>>> #14 0x000000000042fcc8 in avnd_evt_process (evt=<optimized out>) at
>>>> avnd_proc.c:278
>>>> #15 avnd_main_process () at avnd_proc.c:219
>>>> #16 0x0000000000408835 in main (argc=2, argv=0x7fffdcc53588) at
>>>> amfnd_main.c:53
>>>>
>>>>
>>>> Thanks,
>>>> Praveen.
>>>>
>>>>
>>>> On 03-Aug-13 9:47 PM, Hans Nordebäck wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think the problem with "child before exec" "hangs" and the
>>>>> problem where "child" at cleanup times out instantly, even though a 10
>>>>> sec.
>>>>> timeout is set, are related.
>>>>>
>>>>> Some reasons why the child seems to hang could be:
>>>>>
>>>>> 1. Not run at all
>>>>> 2. "Hangs" in e.g. close.
>>>>> 3. Crashes, but then whe should have core dumps.
>>>>>
>>>>> but the problem with "hanging" and instantly times out could be:
>>>>>
>>>>> 4. When parent process adds the pid in the patricia tree,
>>>>> add_new_req_pid_in_list, ncs_exec_mod_hdlr is able to kill this
>>>>> child pid before it has started.
>>>>> A e.g. race condtion in this code could explain both these faults.
>>>>> I looked briefly in this code and one thing is the delivery of the
>>>>> SIGCHLD signal, any thread can get that signal, e.g amfnd, mds,
>>>>> timer or ncs_exec_mod_hdlr. I think a dedicated thread should
>>>>> handle SIGCHLD.
>>>>> I guess we should look closer to this part.
>>>>>
>>>>> /BR HansN
>>>>> ________________________________________
>>>>> Från: Hans Nordebäck
>>>>> Skickat: den 30 juli 2013 13:05
>>>>> Till: Nagendra Kumar
>>>>> Cc: Ramesh Babu Betham; [email protected];
>>>>> Praveen Malviya; Hans Feldt
>>>>> Ämne: RE: [PATCH 1 of 1] leap: ncs_os_process_execute_timed child
>>>>> process takes too long time before exec (#514)
>>>>>
>>>>> Hi Nagu, I have tested the patch and simulated "hanging" in the
>>>>> child part, the core dump produced points out where.
>>>>> The system works as before, exept the core dump if it hangs in the
>>>>> child part. We have this patch running at a site waiting for it to
>>>>> trigger, so we don't know yet what is causing this and if the
>>>>> patch will help.
>>>>>
>>>>> /BR HansN
>>>>>
>>>>> -----Original Message-----
>>>>> From: Nagendra Kumar [mailto:[email protected]]
>>>>> Sent: den 30 juli 2013 13:05
>>>>> To: Hans Nordebäck
>>>>> Cc: Ramesh Babu Betham; [email protected];
>>>>> Praveen Malviya; Hans Feldt
>>>>> Subject: RE: [PATCH 1 of 1] leap: ncs_os_process_execute_timed
>>>>> child process takes too long time before exec (#514)
>>>>>
>>>>> Hi Hans N,
>>>>>
>>>>> Close is not a sync call. I am still not convinced, these calls
>>>>> may get blocked because of NFS system issue.
>>>>> Have you tested by keeping abort in child process and see how
>>>>> amfnd or other services behaves(just to simulate abort)?
>>>>>
>>>>> Thanks
>>>>> -Nagu
>>>>>
>>>>> -----Original Message-----
>>>>> From: Hans Nordebäck [mailto:[email protected]]
>>>>> Sent: 30 July 2013 16:16
>>>>> To: Nagendra Kumar
>>>>> Cc: Ramesh Babu Betham; [email protected];
>>>>> Praveen Malviya; Hans Feldt
>>>>> Subject: Re: [PATCH 1 of 1] leap: ncs_os_process_execute_timed
>>>>> child process takes too long time before exec (#514)
>>>>>
>>>>> Hi Nagu, I agree with Ramesh, e.g. in the child part:
>>>>>
>>>>> /* By default we close all inherited file descriptors in
>>>>> the child */
>>>>> if (getenv("OPENSAF_KEEP_FD_OPEN_AFTER_FORK") == NULL) {
>>>>> /* Close all inherited file descriptors */
>>>>> int i = sysconf(_SC_OPEN_MAX);
>>>>> if (i == -1) {
>>>>> syslog(LOG_ERR, "%s: sysconf failed - %s",
>>>>> __FUNCTION__, strerror(errno));
>>>>> exit(EXIT_FAILURE);
>>>>> }
>>>>> for (i--; i >= 0; --i)
>>>>> (void) close(i); /* close all descriptors */
>>>>>
>>>>> /* Redirect standard files to /dev/null */
>>>>> if (freopen("/dev/null", "r", stdin) == NULL)
>>>>> syslog(LOG_ERR, "%s: freopen stdin failed -
>>>>> %s", __FUNCTION__, strerror(errno));
>>>>> if (freopen("/dev/null", "w", stdout) == NULL)
>>>>> syslog(LOG_ERR, "%s: freopen stdout failed -
>>>>> %s", __FUNCTION__, strerror(errno));
>>>>> if (freopen("/dev/null", "w", stderr) == NULL)
>>>>> syslog(LOG_ERR, "%s: freopen stderr failed -
>>>>> %s", __FUNCTION__, strerror(errno));
>>>>> }
>>>>>
>>>>> close are issued.
>>>>>
>>>>> /BR HansN
>>>>>
>>>>> On 07/30/13 12:34, Nagendra Kumar wrote:
>>>>>
>>>>>> But where are file operations coming during fork, can you please
>>>>>> explain ?
>>>>>>
>>>>>> Thanks
>>>>>> -Nagu
>>>>>> -----Original Message-----
>>>>>> From: Ramesh Betham
>>>>>> Sent: 30 July 2013 15:53
>>>>>> To: Nagendra Kumar
>>>>>> Cc: Hans Nordebäck; [email protected]; Praveen
>>>>>> Malviya; Hans Feldt
>>>>>> Subject: Re: [PATCH 1 of 1] leap: ncs_os_process_execute_timed
>>>>>> child process takes too long time before exec (#514)
>>>>>>
>>>>>> Nagu: Hans N might be pointing to the chances of hung of
>>>>>> file-operation calls (esp. when some inconsistency happens with
>>>>>> NFS). Just a guess, let Hans N confirm it.
>>>>>>
>>>>>> Thanks,
>>>>>> Ramesh.
>>>>>>
>>>>>> On 7/30/2013 3:27 PM, Nagendra Kumar wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>>> regarding what can "hang" in the child part, e.g close of file
>>>>>>>>> descriptors close of file descriptors.
>>>>>>>>>
>>>>>>> When this can happen? After fork is successful, this shouldn't
>>>>>>> happen. Can you please provide any example.
>>>>>>>
>>>>>>> Thanks
>>>>>>> -Nagu
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Hans Nordebäck [mailto:[email protected]]
>>>>>>> Sent: 30 July 2013 12:53
>>>>>>> To: Nagendra Kumar
>>>>>>> Cc: Hans Nordebäck; [email protected]; Praveen
>>>>>>> Malviya; Ramesh Babu Betham; Hans Feldt
>>>>>>> Subject: Re: [PATCH 1 of 1] leap: ncs_os_process_execute_timed
>>>>>>> child process takes too long time before exec (#514)
>>>>>>>
>>>>>>> Hi Nagu, regarding what can "hang" in the child part, e.g close
>>>>>>> of file descriptors. /BR HansN On 07/30/13 09:01, Hans Nordebäck wrote:
>>>>>>>
>>>>>>>> Hi Nagu,
>>>>>>>>
>>>>>>>> On 07/30/13 08:54, Nagendra Kumar wrote:
>>>>>>>>
>>>>>>>>> Hi Hans N,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> 1. OPENSAF_CHILD_EXEC_TIME_TOLERANCE is the name of a new
>>>>>>>>>>> environment variable where value is used as input to alarm,
>>>>>>>>>>> if not set it is default 2 seconds.
>>>>>>>>>>>
>>>>>>>>> Do we have some place holder for this variable for
>>>>>>>>> configuration and are we going to add it in README for information.
>>>>>>>>>
>>>>>>>> Perhaps the name isn't the best, but it should be handled as
>>>>>>>> the other env variable I guess, e.g. "AVND_PM_MONITORING_RATE", etc.
>>>>>>>>
>>>>>>>>>>> if the child "hangs" before exec this extra coredump should
>>>>>>>>>>> give information where/what is wrong.
>>>>>>>>>>>
>>>>>>>>> This means that fork hangs, am I right ? If yes, then dump is
>>>>>>>>> not going to provide any information as it is a system call,
>>>>>>>>> it can only show, ithangs in fork.
>>>>>>>>>
>>>>>>>> I don't think fork hangs as the parent part continues and
>>>>>>>> later, with the help of ncs_exec_mod_hdlr, the parent detects
>>>>>>>> that the child or "exec" has timed out,
>>>>>>>> 10 sec in this case. But in this case the exec has not been
>>>>>>>> performed.
>>>>>>>>
>>>>>>>>>>> After exec, it will work as usual
>>>>>>>>>>>
>>>>>>>>> This confirms that we are only targeting fork to debug.
>>>>>>>>>
>>>>>>>> Yes, the extra core dump will help troubleshooting.
>>>>>>>> /BR HansN
>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> -Nagu
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Hans Nordebäck [mailto:[email protected]]
>>>>>>>>> Sent: 30 July 2013 11:57
>>>>>>>>> To: Nagendra Kumar
>>>>>>>>> Cc: [email protected]; Praveen Malviya;
>>>>>>>>> Ramesh Babu Betham; Hans Feldt; Hans Nordebäck
>>>>>>>>> Subject: RE: [PATCH 1 of 1] leap: ncs_os_process_execute_timed
>>>>>>>>> child process takes too long time before exec (#514)
>>>>>>>>>
>>>>>>>>> Hi Nagu,
>>>>>>>>>
>>>>>>>>> 1. OPENSAF_CHILD_EXEC_TIME_TOLERANCE is the name of a new
>>>>>>>>> environment variable where value is used as input to alarm, if
>>>>>>>>> not set it is default 2 seconds.
>>>>>>>>> 2. Yes you are right, in this particular case it is set to 10
>>>>>>>>> sec, that's why the env. variable above can be set.
>>>>>>>>> 3. This alarm is just an additional precaution, at no extra
>>>>>>>>> cost, to check the child part before the exec. After exec
>>>>>>>>> it will work as usual but if the child "hangs"
>>>>>>>>> before exec this extra coredump should give information where/what
>>>>>>>>> is wrong.
>>>>>>>>>
>>>>>>>>> /BR HansN
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Nagendra Kumar [mailto:[email protected]]
>>>>>>>>> Sent: den 30 juli 2013 07:11
>>>>>>>>> To: Hans Nordebäck; Praveen Malviya; Hans Feldt; Ramesh Babu
>>>>>>>>> Betham
>>>>>>>>> Cc: [email protected]
>>>>>>>>> Subject: RE: [PATCH 1 of 1] leap: ncs_os_process_execute_timed
>>>>>>>>> child process takes too long time before exec (#514)
>>>>>>>>>
>>>>>>>>> Hi Hans N,
>>>>>>>>> For my understanding, can you please provide the
>>>>>>>>> below
>>>>>>>>> information:
>>>>>>>>>
>>>>>>>>> 1. I can't find OPENSAF_CHILD_EXEC_TIME_TOLERANCE in opensaf
>>>>>>>>> source code.
>>>>>>>>> 2. I hope the child process is hung for more than
>>>>>>>>> saAmfCtDefClcCliTimeout resulting in CLC time out. Am I right?
>>>>>>>>> 3. Even we add assert in child process and we get core dump, but
>>>>>>>>> it may not give any information as it got delayed because of
>>>>>>>>> system issue. Are we targeting, which system call the
>>>>>>>>> child process is hung?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> -Nagu
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Hans Nordeback [mailto:[email protected]]
>>>>>>>>> Sent: 22 July 2013 17:07
>>>>>>>>> To: Nagendra Kumar; Praveen Malviya; [email protected];
>>>>>>>>> Ramesh Babu Betham
>>>>>>>>> Cc: [email protected]
>>>>>>>>> Subject: [PATCH 1 of 1] leap: ncs_os_process_execute_timed
>>>>>>>>> child process takes too long time before exec (#514)
>>>>>>>>>
>>>>>>>>> osaf/libs/core/leap/os_defs.c | 27 +++++++++++++++++++++++++++
>>>>>>>>> 1 files changed, 27 insertions(+), 0 deletions(-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> amfnd calls ncs_os_process_execute_timed and the child process
>>>>>>>>> takes too long time before exec, (10 sec timeout). An alarm is
>>>>>>>>> set in the ncs_os_process_execute_timed child process. If
>>>>>>>>> timed out a core dump will be produced to be able to trouble shoot.
>>>>>>>>>
>>>>>>>>> diff --git a/osaf/libs/core/leap/os_defs.c
>>>>>>>>> b/osaf/libs/core/leap/os_defs.c
>>>>>>>>> --- a/osaf/libs/core/leap/os_defs.c
>>>>>>>>> +++ b/osaf/libs/core/leap/os_defs.c
>>>>>>>>> @@ -65,6 +65,15 @@ bool gl_ncs_atomic_mtx_initialise = fals
>>>>>>>>> * description of SOCK_CLOEXEC. */
>>>>>>>>> static pthread_mutex_t s_cloexec_mutex =
>>>>>>>>> PTHREAD_MUTEX_INITIALIZER;
>>>>>>>>> +/*
>>>>>>>>> + * ALRM signal is used to detect if child process takes too
>>>>>>>>> + long
>>>>>>>>> time before exec.
>>>>>>>>> + *
>>>>>>>>> + * @param sig
>>>>>>>>> + */
>>>>>>>>> +static void sigalrm_handler(int sig) {
>>>>>>>>> + abort();
>>>>>>>>> +}
>>>>>>>>> /*************************************************************
>>>>>>>>> **************
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>> * uns64
>>>>>>>>> @@ -999,6 +1008,22 @@ uint32_t ncs_os_process_execute_timed(NC
>>>>>>>>> osaf_mutex_lock_ordie(&s_cloexec_mutex);
>>>>>>>>> if ((pid = fork()) == 0) {
>>>>>>>>> + unsigned int alarm_time_sec;
>>>>>>>>> + char* alarm_time;
>>>>>>>>> +
>>>>>>>>> + if (signal(SIGALRM, sigalrm_handler) == SIG_ERR) {
>>>>>>>>> + LOG_ER("signal ALRM failed: %s",
>>>>>>>>> strerror(errno));
>>>>>>>>> + }
>>>>>>>>> + if ((alarm_time =
>>>>>>>>> getenv("OPENSAF_CHILD_EXEC_TIME_TOLERANCE")) != NULL) {
>>>>>>>>> + alarm_time_sec = strtol(alarm_time,
>>>>>>>>> NULL, 0);
>>>>>>>>> + }
>>>>>>>>> + else {
>>>>>>>>> + // default alarm timeout 2 seconds
>>>>>>>>> + alarm_time_sec = 2;
>>>>>>>>> + }
>>>>>>>>> +
>>>>>>>>> + alarm(alarm_time_sec);
>>>>>>>>> +
>>>>>>>>> /*
>>>>>>>>> ** Make sure forked processes have default
>>>>>>>>> scheduling class
>>>>>>>>> ** independent of the callers scheduling class.
>>>>>>>>> @@ -1054,6 +1079,8 @@ uint32_t ncs_os_process_execute_timed(NC
>>>>>>>>> }
>>>>>>>>> #endif
>>>>>>>>> + alarm(0);
>>>>>>>>> +
>>>>>>>>> /* child part */
>>>>>>>>> if (execvp(req->i_script, req->i_argv) == -1) {
>>>>>>>>> syslog(LOG_ERR, "%s: execvp '%s' failed -
>>>>>>>>> %s", __FUNCTION__, req->i_script, strerror(errno));
>>>>>>>>>
>
>
>
> ----------------------------------------------------------------------
> -------- Get 100% visibility into Java/.NET code with AppDynamics
> Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.c
> lktrk _______________________________________________
> Opensaf-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensaf-devel
>
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
