Summary: base: use dup2 instead of freopen (non async-signal-safe) V1
Review request for Trac Ticket(s): #532
Peer Reviewer(s): HansF, AndersW, Ramesh
Pull request to:
Affected branch(es): 4.3, 4.4, default
Development branch: default
Impacted area Impact
Hi Gary,
Tested :
1. amf-adm lock safVersion=4.0.0,safAppType=OpenSafApplicationType
Got error: Admin operation not supported for
safVersion=4.0.0,safAppType=OpenSafApplicationType
2. amf-adm si-swap safSi=SC-2N,safApp=OpenSAF and then amf-adm lock
safSu=SC-1\,safSg=2N\,safApp=OpenSAF
Apr 23
osaf/libs/core/leap/os_defs.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
New issues where freopen freezes, use dup2 instead.
Non async-signal-safe are used in ncs_os_process_execute_timed,
sched_setscheduler, syslog, setenv, getenv and freopen. Syslog may
Ack. See also related #442. I think this is also fixed with this patch
Thanks
Lennart
-Original Message-
From: mathi.naic...@oracle.com [mailto:mathi.naic...@oracle.com]
Sent: den 15 april 2014 02:56
To: Lennart Lund
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1]
What happens in/with the child process if this code is instead removed
completely?
/HansF
-Original Message-
From: Hans Nordebäck
Sent: den 23 april 2014 09:11
To: Hans Feldt; Anders Widell; ramesh.bet...@oracle.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1]
In that case the child will have the same stdin/stdout/stderr as the
parent process. But if we know for sure that the parent already has
redirected its stdin/stdout/stderr to /dev/null then I think it ought to
be fine.
/ Anders Widell
2014-04-23 09:45, Hans Feldt skrev:
What happens in/with
Yes we know that for sure, it is amfnd or smfnd calling this routine.
From what I remember one closeonexec is needed (some leap fd) then we can
remove the close loop and the reopen part. I think we should aim for that
instead of patching.
/HansF
-Original Message-
From: Anders
We need to be careful that all file descriptors have the FD_CLOEXEC
flag, then. It can easily happen that someone later on creates a file
descriptor without this flag, without knowing that it is needed.
If we had a debug build, then we could have a loop surronded by #ifdef
DEBUG, that checks
Me too have the same opinion, there is a good chance that 'fd' can be
created without FD_CLOEXEC flag.
Well, 'close()' is an async-signal-safe function.. so it should not be a
problem.
Regards,
Ramesh.
On 4/23/2014 1:43 PM, Anders Widell wrote:
We need to be careful that all file descriptors
Well lets remove the 3*open part then.
Thanks,
Hans
On 04/23/2014 12:11 PM, Ramesh Betham wrote:
Me too have the same opinion, there is a good chance that 'fd' can be created
without FD_CLOEXEC flag.
Well, 'close()' is an async-signal-safe function.. so it should not be a
problem.
Ack from Me.
Tested the positive cases for enabling and disabling imcn notifications.
/AndersBj
-Original Message-
From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com]
Sent: den 18 april 2014 15:25
To: Anders Björnerstedt
Cc: opensaf-devel@lists.sourceforge.net
Ack
/Lennart
-Original Message-
From: Zoran Milinkovic
Sent: den 8 april 2014 10:43
To: Lennart Lund
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 0 of 1] Review Request for OSAF: fix errors compiled with
32-bit compiler [#838]
Summary: OSAF: fix errors compiled with
osaf/services/saf/amf/amfd/sg.cc | 26 +++---
1 files changed, 3 insertions(+), 23 deletions(-)
When an SG is extended with a new SU, it will not be instantiated or
assigned unless saAmfSGNumPrefInserviceSUs is configured accordingly.
Reason is saAmfSGNumPrefInserviceSUs
Summary: Fix saAmfSGNumPrefInserviceSUs handling
Review request for Trac Ticket(s): 278
Peer Reviewer(s): Nags
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
Affected branch(es): all
Development branch: default
Impacted area Impact y/n
14 matches
Mail list logo
