[tickets] [opensaf:tickets] #2286 base: unhandled SIGPIPE in osaf_auth_server_connect

[Gary Lee]

- **status**: unassigned --> review



---

** [tickets:#2286] base: unhandled SIGPIPE in osaf_auth_server_connect**

**Status:** review
**Milestone:** 5.0.2
**Created:** Thu Feb 02, 2017 02:54 AM UTC by Gary Lee
**Last Updated:** Thu Feb 02, 2017 02:56 AM UTC
**Owner:** Gary Lee


2017-01-25 07:02:53 SC-2 osafamfd[480]: NO Re-initializing with IMM
2017-01-25 07:02:53 SC-2 osafrded[417]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osafclmd[471]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osaflogd[453]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osafimmd[434]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osafamfnd[489]: ER AMFD has unexpectedly crashed. 
Rebooting node
2017-01-25 07:02:53 SC-2 osafamfnd[489]: Rebooting OpenSAF NodeId = 131599 EE 
Name = , Reason: AMFD has unexpectedly crashed. Rebooting node, OwnNodeId = 
131599, SupervisionTime = 60

signal: 13 pid: 480 uid: 999
/usr/local/lib/opensaf/libopensaf_core.so.0(+0x1820b)[0x7f39d7cc520b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f39d727f330]
/lib/x86_64-linux-gnu/libpthread.so.0(send+0x7b)[0x7f39d727e95b]
/usr/local/lib/opensaf/libopensaf_core.so.0(osaf_auth_server_connect+0xde)[0x7f39d7cd5dce]
/usr/local/lib/opensaf/libopensaf_core.so.0(mds_auth_server_disconnect+0x82)[0x7f39d7cff732]
/usr/local/lib/libSaImmOi.so.0(+0x5294)[0x7f39d8145294]
/usr/local/lib/libSaImmOi.so.0(saImmOiFinalize+0x1b9)[0x7f39d8146d09]
/usr/local/lib/opensaf/osafamfd(+0x4c5b3)[0x55eff4ebe5b3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f39d7277184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f39d6fa437d]

We should probably specify send(., MSG_NOSIGNAL) in 
osaf_auth_server_connect().




---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

Re: [tickets] [opensaf:tickets] Re: #2133 AMF: Rollback admin shutdown/lock SI operation if node failover

[Nagendra Kumar]

Hi Minh,

I also wouldn't prefer to rollback but because of internal 
implementation, I am just reusing the code. I am preferring return code as 
TRY_AGAIN because the error has occurred and the operation can't be completed.

 

Thanks

-Nagu

 

From: Minh Hon Chau [mailto:minh-c...@users.sf.net] 
Sent: 02 February 2017 09:56
To: opensaf-tickets@lists.sourceforge.net
Subject: [tickets] [opensaf:tickets] Re: #2133 AMF: Rollback admin 
shutdown/lock SI operation if node failover

 

Hi Nagu,

I prefer to not rollback the operations (as commented by Praveen earlier) if 
the rollback is due to internal implementation, not from a specific use case. 
Anyway if we have no way to correct it, then we have to accept it. I don't have 
a clear indication on which error code should be returned, both TRY_AGAIN and 
TIMEOUT seems ok since the caller will have to retry the operation.

Thanks,
Minh

  _  

HYPERLINK "https://sourceforge.net/p/opensaf/tickets/2133/"[tickets:#2133] AMF: 
Rollback admin shutdown/lock SI operation if node failover

Status: accepted
Milestone: 5.2.FC
Created: Thu Oct 20, 2016 06:49 PM UTC by Minh Hon Chau
Last Updated: Wed Feb 01, 2017 08:50 AM UTC
Owner: Nagendra Kumar

In scenario of shut down SI, delay QUIESCING csi callback, then reboot the node 
that hosting SU having pending this csi callback. The result of this operation 
looks differently between SGs
- For 2N: the SI Admin state is rollbacked to UNLOCK 
- For Nway: the SI Admin state moves to LOCKED
- In NpM: Haven't tested just browsing SG_NPM::node_fail_si_oper, looks SI 
Admin states rollbacks to UNLOCK

My question is whether the result of these scenario should be consistent? And 
what's the expected outcome?
Also, the handling of node_fail_si_oper for admin lock is not consistent. For 
2N, Admin state remains LOCKED, NpM rollbacks to UNLOCK

  _  

Sent from sourceforge.net because HYPERLINK 
"mailto:opensaf-tickets@lists.sourceforge.net"opensaf-tickets@lists.sourceforge.net
 is subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a 
mailing list, you can unsubscribe from the mailing list.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2210 AMFD: Loss of RT attribute update before headless

[Minh Hon Chau]

Hi Praveen,

AMFD is not reading RTA during failover it seems. Could it be a loss of MBC 
update seen in #2228?

If loss of RTA from headless is detected, we can recover the state and continue 
if only one RTA is lost. The recovery of lost states is difficult (or 
impossible ?) if having 2 or more RTAs are lost. The patch 2210_v2.diff assumes 
the SG Fsm State is correct so that AMFD recovers Admin State, but what happens 
if osafAmfSGFsmState is lost too, and some of other states also. That's reason 
I would suggest to use su_fault() to isolate the loss if we are not able to 
have full recovery solution from loss.

Another alternative is that AMFD distributes all of neccessary RTAs to AMFND in 
form of su_si assignment message, and AMFD collects them via sync info message 
again after headless, but it seems a big change of codes.

I can send 2210_v2.diff for review, but it's a very limited fix and for 
reported issue in this ticket only.

Thanks,
Minh


---

** [tickets:#2210] AMFD: Loss of RT attribute update before headless**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Mon Nov 28, 2016 10:18 PM UTC by Minh Hon Chau
**Last Updated:** Wed Feb 01, 2017 06:07 AM UTC
**Owner:** Minh Hon Chau


A loss of IMM RT saAmfSIAdminState update in AMFD has been seen just before 
cluster goes headless. It results in coredump after headless.

One scenario is:
- Issue amf-admin shutdown SI, delay csi quiescing callback
- Stop SCs, release csi quiescing callback
- Restart SCs
Observation: the saAmfSIAdminState is read as UNLOCKED while related SUSI was 
QUIESCED, and coredump as below

~~~
Thread 1 (Thread 0x7fec174a0780 (LWP 493)):
#0  0x004fbfd5 in SG_2N::node_fail_si_oper (this=0x24109d0, 
su=0x2413440) at sg_2n_fsm.cc:3102
s_susi = 0x8f5000b
susi_temp = 0x5fa169
o_su = 0x2417f98
__FUNCTION__ = "node_fail_si_oper"
cb = 0x919240 <_control_block>
#1  0x004fe69c in SG_2N::node_fail (this=0x24109d0, cb=0x919240 
<_control_block>, su=0x2413440) at sg_2n_fsm.cc:
3469
a_susi = 0x1
s_susi = 0x7fffedecd2d0
o_su = 0x5a50bd 
flag = 2
__FUNCTION__ = "node_fail"
su_ha_state = 0
#2  0x00513010 in AVD_SG::failover_absent_assignment (this=0x24109d0) 
at sg.cc:2273
su = @0x2411330: 0x2413440
__for_range = std::vector of length 2, capacity 2 = {0x2413440, 
0x24111e0}
__for_begin = 
__for_end = 
__FUNCTION__ = "failover_absent_assignment"
#3  0x0043be65 in avd_cluster_tmr_init_evh (cb=0x919240 
<_control_block>, evt=0x7fec04000df0) at cluster.cc:103
i_sg = 0x24109d0
it = {first = "safSg=1,safApp=osaftest", second = }
__FUNCTION__ = "avd_cluster_tmr_init_evh"
su = 0x0
node = 0x240f9b0
~~~



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] Re: #2133 AMF: Rollback admin shutdown/lock SI operation if node failover

[Minh Hon Chau]

Hi Nagu,

I prefer to not rollback the operations (as commented by Praveen earlier) if 
the rollback is due to internal implementation, not from a specific use case. 
Anyway if we have no way to correct it, then we have to accept it. I don't have 
a clear indication on which error code should be returned, both TRY_AGAIN and 
TIMEOUT seems ok since the caller will have to retry the operation.

Thanks,
Minh


---

** [tickets:#2133] AMF: Rollback admin shutdown/lock SI operation if node 
failover**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Thu Oct 20, 2016 06:49 PM UTC by Minh Hon Chau
**Last Updated:** Wed Feb 01, 2017 08:50 AM UTC
**Owner:** Nagendra Kumar


In scenario of shut down SI, delay QUIESCING csi callback, then reboot the node 
that hosting SU having pending this csi callback. The result of this operation 
looks differently between SGs
- For 2N: the SI Admin state is rollbacked to UNLOCK 
- For Nway: the SI Admin state moves to LOCKED
- In NpM: Haven't tested just browsing SG_NPM::node_fail_si_oper, looks SI 
Admin states rollbacks to UNLOCK

My question is whether the result of these scenario should be consistent? And 
what's the expected outcome?
Also, the handling of node_fail_si_oper for admin lock is not consistent. For 
2N, Admin state remains LOCKED, NpM rollbacks to UNLOCK


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2278 mds: Blocking send causes AMF health check time-out

[A V Mahesh (AVM)]

- **status**: unassigned --> assigned
- **assigned_to**: A V Mahesh (AVM)



---

** [tickets:#2278] mds: Blocking send causes AMF health check time-out**

**Status:** assigned
**Milestone:** 5.1.1
**Created:** Thu Jan 26, 2017 09:49 AM UTC by Anders Widell
**Last Updated:** Thu Jan 26, 2017 09:49 AM UTC
**Owner:** A V Mahesh (AVM)


AMF health-check time-out is seen on SC-1 after restarting SC-2. The system is 
using OpenSAF 5.1.0 configured with TCP communication.

Syslog:

~~~
2017-01-20T18:29:04.405982+01:00 local0.err SC-1 osafamfnd[2820]: ER AMF 
director heart beat timeout, generating core for amfd
2017-01-20T18:29:05.408819+01:00 local0.crit SC-1 osafamfnd[2820]: Rebooting 
OpenSAF NodeId = 131343 EE Name = , Reason: AMF director heart beat timeout, 
OwnNodeId = 131343, SupervisionTime = 0
~~~

Back-trace of osafamfd:

~~~
0x7fa316cceb60 osaf_poll_no_timeout (osaf/libs/core/common/osaf_poll.c:33)
0x7fa316ccede5 osaf_poll (osaf/libs/core/common/osaf_poll.c:45)
0x7fa316ccee25 osaf_poll_one_fd (osaf/libs/core/common/osaf_poll.c:129)
0x7fa316cfab67 mds_mcm_time_wait 
(osaf/libs/core/common/include/osaf_utility.h:79)
0x7fa316cfae51 mds_subtn_tbl_add_disc_queue 
(osaf/libs/core/mds/mds_c_sndrcv.c:1808)
0x7fa316cfb03d mds_mcm_process_disc_queue_checks_redundant 
(osaf/libs/core/mds/mds_c_sndrcv.c:2338)
0x7fa316cfbcd1 mcm_pvt_red_snd_process_common 
(osaf/libs/core/mds/mds_c_sndrcv.c:2257)
0x7fa316cfd04d mcm_pvt_red_svc_snd (osaf/libs/core/mds/mds_c_sndrcv.c:2174)
0x7fa316cff8f9 mds_send (osaf/libs/core/mds/mds_c_sndrcv.c:736)
0x7fa316cf9068 ncsmds_api (osaf/libs/core/mds/mds_papi.c:191)
0x7fa316ce6f5f mbcsv_mds_send_msg (osaf/libs/core/mbcsv/mbcsv_mds.c:239)
0x7fa316cec440 mbcsv_send_ckpt_data_to_all_peers 
(osaf/libs/core/mbcsv/mbcsv_util.c:479)
0x7fa316ce56d7 mbcsv_process_snd_ckpt_request 
(osaf/libs/core/mbcsv/mbcsv_api.c:862)
0x40bfc0 avsv_send_ckpt_data(cl_cb_tag*, unsigned int, unsigned long, unsigned 
int, unsigned int) (osaf/services/saf/amf/amfd/chkop.cc:1062)
0x446649 avd_node_oper_state_set(AVD_AVND*, SaAmfOperationalStateT) 
(osaf/services/saf/amf/amfd/node.cc:505)
0x44040c avd_node_mark_absent(AVD_AVND*) 
(osaf/services/saf/amf/amfd/ndfsm.cc:1018)
0x4438ba avd_node_failover(AVD_AVND*) 
(osaf/services/saf/amf/amfd/ndproc.cc:1141)

~~~


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2285 LOG: Check size of logBufSize could be non backward compatible

[Minh Hon Chau]

Hi Vu,

"Consistent" in AIS spec seems not clear, some can inteprete to count length 
with null pointer, some may not. This issue had been flagged in review of 
#2038. After this check is introduced, applications may still be running 
without problem, some may receive INVALID_PARAM. I guess it's possibly due to 1 
byte difference of null. 
This issue is seen during upgrade, I'm not sure if application wants to change 
their code which is running without problem previously after application uses 
the Opensaf version having this check. I suppose both NTF and LOG can make this 
check a bit friendly. But the Opensaf version in this reported problem does not 
have that check for NTF, so I raise it under LOGsv. If we include this check 
for NTF, those applications will fail straight away, it could result in 
coredump or error.

Thanks,
Minh



---

** [tickets:#2285] LOG: Check size of logBufSize could be non backward 
compatible**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Thu Feb 02, 2017 01:44 AM UTC by Minh Hon Chau
**Last Updated:** Thu Feb 02, 2017 02:10 AM UTC
**Owner:** nobody


NTF has received INVALID_PARAM when logging notification 

Jan 31 13:05:28.661574 osafntfd [12166:lga_api.c:1136] >> saLogWriteLogAsync
Jan 31 13:05:28.661578 osafntfd [12166:lga_api.c:0989] >> handle_log_record
Jan 31 13:05:28.661582 osafntfd [12166:lga_api.c:1094] << handle_log_record
Jan 31 13:05:28.661586 osafntfd [12166:lga_api.c:1171] TR logBufSize > 
strlen(logBuf) + 1
Jan 31 13:05:28.661589 osafntfd [12166:lga_api.c:1291] << saLogWriteLogAsync
Jan 31 13:05:28.661611 osafntfd [12166:NtfLogger.cc:0255] NO Failed to log an 
alarm or security alarm notification (7)

This notification comes from application who specifies the lengthAdditionalText 
and additionalText. If a check that returns INVALID_PARAM in relation to size 
of AdditonalText and it causes existing application fails to log, then this 
check probably is non backward compatible.

The mismatch in size of additionalText could be a misuse of sizeof() from 
application side, in similar way which has been reported in #2038.

INVALID_PARAM should be avoided, and Log Agent can adjust to expected size and 
gives a log warning, so that the existing application can log.

A similar check in NTF Agent also can be a similar problem potentially.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2286 base: unhandled SIGPIPE in osaf_auth_server_connect

[Gary Lee]

- **summary**: base: ignore SIGPIPE in osaf_auth_server_connect --> base: 
unhandled SIGPIPE in osaf_auth_server_connect



---

** [tickets:#2286] base: unhandled SIGPIPE in osaf_auth_server_connect**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Thu Feb 02, 2017 02:54 AM UTC by Gary Lee
**Last Updated:** Thu Feb 02, 2017 02:54 AM UTC
**Owner:** Gary Lee


2017-01-25 07:02:53 SC-2 osafamfd[480]: NO Re-initializing with IMM
2017-01-25 07:02:53 SC-2 osafrded[417]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osafclmd[471]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osaflogd[453]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osafimmd[434]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osafamfnd[489]: ER AMFD has unexpectedly crashed. 
Rebooting node
2017-01-25 07:02:53 SC-2 osafamfnd[489]: Rebooting OpenSAF NodeId = 131599 EE 
Name = , Reason: AMFD has unexpectedly crashed. Rebooting node, OwnNodeId = 
131599, SupervisionTime = 60

signal: 13 pid: 480 uid: 999
/usr/local/lib/opensaf/libopensaf_core.so.0(+0x1820b)[0x7f39d7cc520b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f39d727f330]
/lib/x86_64-linux-gnu/libpthread.so.0(send+0x7b)[0x7f39d727e95b]
/usr/local/lib/opensaf/libopensaf_core.so.0(osaf_auth_server_connect+0xde)[0x7f39d7cd5dce]
/usr/local/lib/opensaf/libopensaf_core.so.0(mds_auth_server_disconnect+0x82)[0x7f39d7cff732]
/usr/local/lib/libSaImmOi.so.0(+0x5294)[0x7f39d8145294]
/usr/local/lib/libSaImmOi.so.0(saImmOiFinalize+0x1b9)[0x7f39d8146d09]
/usr/local/lib/opensaf/osafamfd(+0x4c5b3)[0x55eff4ebe5b3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f39d7277184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f39d6fa437d]

We should probably specify send(., MSG_NOSIGNAL) in 
osaf_auth_server_connect().




---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2286 base: ignore SIGPIPE in osaf_auth_server_connect

[Gary Lee]

---

** [tickets:#2286] base: ignore SIGPIPE in osaf_auth_server_connect**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Thu Feb 02, 2017 02:54 AM UTC by Gary Lee
**Last Updated:** Thu Feb 02, 2017 02:54 AM UTC
**Owner:** Gary Lee


2017-01-25 07:02:53 SC-2 osafamfd[480]: NO Re-initializing with IMM
2017-01-25 07:02:53 SC-2 osafrded[417]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osafclmd[471]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osaflogd[453]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osafimmd[434]: exiting for shutdown
2017-01-25 07:02:53 SC-2 osafamfnd[489]: ER AMFD has unexpectedly crashed. 
Rebooting node
2017-01-25 07:02:53 SC-2 osafamfnd[489]: Rebooting OpenSAF NodeId = 131599 EE 
Name = , Reason: AMFD has unexpectedly crashed. Rebooting node, OwnNodeId = 
131599, SupervisionTime = 60

signal: 13 pid: 480 uid: 999
/usr/local/lib/opensaf/libopensaf_core.so.0(+0x1820b)[0x7f39d7cc520b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f39d727f330]
/lib/x86_64-linux-gnu/libpthread.so.0(send+0x7b)[0x7f39d727e95b]
/usr/local/lib/opensaf/libopensaf_core.so.0(osaf_auth_server_connect+0xde)[0x7f39d7cd5dce]
/usr/local/lib/opensaf/libopensaf_core.so.0(mds_auth_server_disconnect+0x82)[0x7f39d7cff732]
/usr/local/lib/libSaImmOi.so.0(+0x5294)[0x7f39d8145294]
/usr/local/lib/libSaImmOi.so.0(saImmOiFinalize+0x1b9)[0x7f39d8146d09]
/usr/local/lib/opensaf/osafamfd(+0x4c5b3)[0x55eff4ebe5b3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f39d7277184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f39d6fa437d]

We should probably specify send(., MSG_NOSIGNAL) in 
osaf_auth_server_connect().




---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2285 LOG: Check size of logBufSize could be non backward compatible

[Vu Minh Nguyen]

Hi Minh,

I think, the applications encountered this case have to fix the wrong code from 
their side as they have not followed the NTF AIS spec correctly.

Here is the statement from the AIS spec.
> additionalText optional – length must be consistent with lengthAdditionalText

Also, I remember there was a fix in NTFA regarding inconsistence 
b/w`additionalText` `lengthAdditionalText`. Refer to [#2006].

If having [#2006] included in, INVALID_PARAM should be returned by NTFA and the 
request should not be able to reach LOGsv.

/Vu


---

** [tickets:#2285] LOG: Check size of logBufSize could be non backward 
compatible**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Thu Feb 02, 2017 01:44 AM UTC by Minh Hon Chau
**Last Updated:** Thu Feb 02, 2017 01:44 AM UTC
**Owner:** nobody


NTF has received INVALID_PARAM when logging notification 

Jan 31 13:05:28.661574 osafntfd [12166:lga_api.c:1136] >> saLogWriteLogAsync
Jan 31 13:05:28.661578 osafntfd [12166:lga_api.c:0989] >> handle_log_record
Jan 31 13:05:28.661582 osafntfd [12166:lga_api.c:1094] << handle_log_record
Jan 31 13:05:28.661586 osafntfd [12166:lga_api.c:1171] TR logBufSize > 
strlen(logBuf) + 1
Jan 31 13:05:28.661589 osafntfd [12166:lga_api.c:1291] << saLogWriteLogAsync
Jan 31 13:05:28.661611 osafntfd [12166:NtfLogger.cc:0255] NO Failed to log an 
alarm or security alarm notification (7)

This notification comes from application who specifies the lengthAdditionalText 
and additionalText. If a check that returns INVALID_PARAM in relation to size 
of AdditonalText and it causes existing application fails to log, then this 
check probably is non backward compatible.

The mismatch in size of additionalText could be a misuse of sizeof() from 
application side, in similar way which has been reported in #2038.

INVALID_PARAM should be avoided, and Log Agent can adjust to expected size and 
gives a log warning, so that the existing application can log.

A similar check in NTF Agent also can be a similar problem potentially.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2285 LOG: Check size of logBufSize could be non backward compatible

[Minh Hon Chau]

---

** [tickets:#2285] LOG: Check size of logBufSize could be non backward 
compatible**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Thu Feb 02, 2017 01:44 AM UTC by Minh Hon Chau
**Last Updated:** Thu Feb 02, 2017 01:44 AM UTC
**Owner:** nobody


NTF has received INVALID_PARAM when logging notification 

Jan 31 13:05:28.661574 osafntfd [12166:lga_api.c:1136] >> saLogWriteLogAsync
Jan 31 13:05:28.661578 osafntfd [12166:lga_api.c:0989] >> handle_log_record
Jan 31 13:05:28.661582 osafntfd [12166:lga_api.c:1094] << handle_log_record
Jan 31 13:05:28.661586 osafntfd [12166:lga_api.c:1171] TR logBufSize > 
strlen(logBuf) + 1
Jan 31 13:05:28.661589 osafntfd [12166:lga_api.c:1291] << saLogWriteLogAsync
Jan 31 13:05:28.661611 osafntfd [12166:NtfLogger.cc:0255] NO Failed to log an 
alarm or security alarm notification (7)

This notification comes from application who specifies the lengthAdditionalText 
and additionalText. If a check that returns INVALID_PARAM in relation to size 
of AdditonalText and it causes existing application fails to log, then this 
check probably is non backward compatible.

The mismatch in size of additionalText could be a misuse of sizeof() from 
application side, in similar way which has been reported in #2038.

INVALID_PARAM should be avoided, and Log Agent can adjust to expected size and 
gives a log warning, so that the existing application can log.

A similar check in NTF Agent also can be a similar problem potentially.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] Re: #2284 IMM: Improper return code without any error string while deleting large number of objects

[Zoran Milinkovic]

Hi,

I have similar problem with deleting large amount of objects in IMM.
CCB has only 1 object (the root object in cascade delete).

Steps to reproduce the problem:
1. populate IMM with large amount of objects. The easiest way is to use 
immpopulate. I tested with 20 objects.
2. immcfg -d 

Then I can see many syslogs like:
Feb  1 15:07:56 SC-1 osafimmnd[6519]: CR MDTM: undelivered message condition 
ancillary data: TIPC_ERR_OVERLOAD
Feb  1 15:07:56 SC-1 osafimmnd[6519]: CR MDTM: undelivered message condition 
ancillary data: TIPC_RETDATA
.
Feb  1 15:07:56 SC-1 osafimmnd[6519]: message repeated 1843 times: [ CR MDTM: 
undelivered message condition ancillary data: TIPC_RETDATA]
Feb  1 15:07:56 SC-1 osafimmnd[6519]: WA MDS Send Failed to service:IMMA OI rc:2
Feb  1 15:07:56 SC-1 osafimmnd[6519]: ER Immnd upcall over MDS for 
ccbObjectDelete to PBE failed! - aborting ccb 2
Feb  1 15:07:56 SC-1 osafimmnd[6519]: CR MDTM: undelivered message condition 
ancillary data: TIPC_RETDATA
Feb  1 15:07:56 SC-1 osafimmnd[6519]: message repeated 396 times: [ CR MDTM: 
undelivered message condition ancillary data: TIPC_RETDATA]
Feb  1 15:07:56 SC-1 osafimmnd[6519]: NO Implementer locally disconnected. 
Marking it as doomed 6 <204, 2010f> (OpenSafImmPBE)
Feb  1 15:07:56 SC-1 osafimmnd[6519]: CR MDTM: undelivered message condition 
ancillary data: TIPC_RETDATA
Feb  1 15:07:56 SC-1 osafimmnd[6519]: message repeated 1665 times: [ CR MDTM: 
undelivered message condition ancillary data: TIPC_RETDATA]
Feb  1 15:07:56 SC-1 osafimmnd[6519]: NO Ccb 2 ABORTED (immcfg_SC-1_6788)

BR,
Zoran


-Original Message-
From: Neelakanta Reddy [mailto:neelaka...@users.sf.net] 
Sent: den 1 februari 2017 10:03
To: [opensaf:tickets] <2...@tickets.opensaf.p.re.sf.net>
Subject: [opensaf:tickets] #2284 IMM: Improper return code without any error 
string while deleting large number of objects

The IMM service, says that the default number of supported objects is 1 for 
one CCB., Beyond which there may be corruptuion.in IMM.  if your environment 
can support,  then the limit of  IMMSV_MAX_OBJECTS can be increased  grater 
than 1.


---

** [tickets:#2284] IMM: Improper return code without any error string while 
deleting large number of objects**

**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Wed Feb 01, 2017 07:13 AM UTC by Chani Srivastava **Last 
Updated:** Wed Feb 01, 2017 08:34 AM UTC
**Owner:** nobody


Steps to reproduce:

1. Bring up opensaf on a cluster
2. Create around 10k objects
3. Try deleating these objects in one immcfg operation

Output:
Error Returned - error - saImmOmAdminOwnerSet FAILED: SA_AIS_ERR_LIBRARY (2)

No error string stating the cause of failure is returned.

Syslog - immcfg: ER TOO MANY Object Names line:733

Expected behavior - Proper return code with error string should be returned 


---

Sent from sourceforge.net because you indicated interest in 




To unsubscribe from further messages, please visit 



---

** [tickets:#2284] IMM: Improper return code without any error string while 
deleting large number of objects**

**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Wed Feb 01, 2017 07:13 AM UTC by Chani Srivastava
**Last Updated:** Wed Feb 01, 2017 09:02 AM UTC
**Owner:** nobody


Steps to reproduce:

1. Bring up opensaf on a cluster
2. Create around 10k objects
3. Try deleating these objects in one immcfg operation

Output:
Error Returned - error - saImmOmAdminOwnerSet FAILED: SA_AIS_ERR_LIBRARY (2)

No error string stating the cause of failure is returned.

Syslog - immcfg: ER TOO MANY Object Names line:733

Expected behavior - Proper return code with error string should be returned 


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2277 smf: smf failed to set saAmfSUMaintenanceCampaign set , when ccb is aborted due to immnd sync

[Neelakanta Reddy]

- **status**: review --> fixed
- **Comment**:

changeset:   8552:63084c85e928
tag: tip
parent:  8549:346005001e6f
user:Neelakanta Reddy 
date:Wed Feb 01 16:25:33 2017 +0530
summary: smf: retry the ccb modify operation when the ccb is aborted with 
resource abort [#2277]

changeset:   8551:2aea0b91ae5a
branch:  opensaf-5.1.x
parent:  8547:12e6a9128684
user:Neelakanta Reddy 
date:Wed Feb 01 16:14:06 2017 +0530
summary: smf: retry the ccb modify operation when the ccb is aborted with 
resource abort [#2277]

changeset:   8550:431ac44d8ee4
branch:  opensaf-5.0.x
parent:  8546:8543ff234ae2
user:Neelakanta Reddy 
date:Wed Feb 01 16:14:06 2017 +0530
summary: smf: retry the ccb modify operation when the ccb is aborted with 
resource abort [#2277]




---

** [tickets:#2277] smf: smf failed to set saAmfSUMaintenanceCampaign  set , 
when ccb is aborted due to immnd sync**

**Status:** fixed
**Milestone:** 5.0.2
**Created:** Wed Jan 25, 2017 11:25 AM UTC by Neelakanta Reddy
**Last Updated:** Mon Jan 30, 2017 01:27 PM UTC
**Owner:** Neelakanta Reddy


Jan 19 06:01:25 sc2 osafsmfd[6110]: NO CAMP: Campaign wrapup, reset 
saAmfSUMaintenanceCampaign flags
Jan 19 06:01:25 sc2 osafimmd[5983]: NO Node 2030f request sync sync-pid:3965 
epoch:0
Jan 19 06:01:25 sc2 osafimmnd[6000]: NO Announce sync, epoch:52
Jan 19 06:01:25 sc2 osafimmnd[6000]: NO SERVER STATE: IMM_SERVER_READY --> 
IMM_SERVER_SYNC_SERVER
Jan 19 06:01:25 sc2 osafimmnd[6000]: NO NODE STATE-> IMM_NODE_R_AVAILABLE
Jan 19 06:01:29 sc2 osafimmnd[6000]: NO Precheck of fevs message of type <33> 
failed with ERROR:18
Jan 19 06:01:30 sc2 osafimmnd[6000]: WA Aborting ccbId  59 to start sync
Jan 19 06:01:30 sc2 osafimmnd[6000]: NO Ccb 59 ABORTED (SMFSERVICE)
Jan 19 06:01:30 sc2 osafsmfd[6110]: NO saImmOmCcbApply failed 
rc=SA_AIS_ERR_FAILED_OPERATION (21)

The campaign is cmmited sucefully, but when another campaign is executed, 
failed with error:
ER Failed to set maintenance state in step=safSmfStep=0001

solution:
use  saImmOmCcbGetErrorStrings, to find VALIDATION/RESOURCE ABORT.
If it is RESOURCE ABORT retry reset saAmfSUMaintenanceCampaign



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2104 nid: Use the tipc command instead of tipc-config

[A V Mahesh (AVM)]

Anders Widell do you mena "tipc" command is the below  ?

===
xenial (8) tipc.8.gz
Provided by: iproute2_4.3.0-1ubuntu3_i386 bug

NAME
   tipc - a TIPC configuration and management tool

SYNOPSIS
   tipc [ OPTIONS ] COMMAND ARGUMENTS

   COMMAND := { bearer | link | media | nametable | node | socket }

   OPTIONS := { -h[help] }

DESCRIPTION
   The Transparent Inter-Process Communication (TIPC) protocol offers
   total address transparency between processes which allows applications
   in a clustered computer environment to communicate quickly and reliably
   with each other, regardless of their location within the cluster.

   TIPC originated at the telecommunications manufacturer Ericsson. The
   first open source version of TIPC was created in 2000 when Ericsson
   released its first Linux version of TIPC. TIPC was introduced in the
   mainline Linux kernel in 2006 and is now widely used both within and
   outside of Ericsson.

OPTIONS
   -h, --help
  Show help about last given command. For example tipc bearer
  --help will show bearer help and tipc --help will show general
  help. The position of the option in the string is irrelevant.

COMMANDS
   BEARER - Show or modify TIPC bearers

   LINK   - Show or modify TIPC links

   MEDIA  - Show or modify TIPC media

   NAMETABLE
  - Show TIPC nametable

   NODE   - Show or modify TIPC node parameters

   SOCKET - Show TIPC sockets

ARGUMENTS
   Command arguments are described in a command specific man page and
   typically consists of nested commands along with key value pairs.  If
   no arguments are given a command typically shows its help text. The
   explicit help option -h or --help can occur anywhere among the
   arguments and will show help for the last valid command given.

EXIT STATUS
   Exit status is 0 if command was successful or a positive integer upon
   failure.

SEE ALSO
   tipc-bearer(8), tipc-link(8), tipc-media(8), tipc-nametable(8), tipc-
   node(8), tipc-socket(8)

REPORTING BUGS
   Report any bugs to the Network Developers mailing list
    where the development and maintenance is
   primarily done.  You do not have to be subscribed to the list to send a
   message there.

AUTHOR
   Richard Alpe 


---

** [tickets:#2104] nid: Use the tipc command instead of tipc-config**

**Status:** unassigned
**Milestone:** future
**Created:** Fri Oct 07, 2016 04:58 PM UTC by Anders Widell
**Last Updated:** Fri Oct 07, 2016 04:58 PM UTC
**Owner:** nobody


The tipc-config command is obsolete and no longer being maintained. We should 
switch to using the "tipc" command instead.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2282 base: `make rpm` giving error with gcc version 6.1.0

[Hans Nordebäck]

- **status**: review --> fixed
- **Comment**:

changeset:   8549:346005001e6f
tag: tip
user:Hans Nordeback 
date:Wed Feb 01 10:39:08 2017 +0100
summary: base: make rpm giving error with gcc version 6.1.0 on SLES11  
[#2282]




---

** [tickets:#2282] base: `make rpm` giving error with gcc version 6.1.0**

**Status:** fixed
**Milestone:** 5.2.FC
**Created:** Tue Jan 31, 2017 09:38 AM UTC by A V Mahesh (AVM)
**Last Updated:** Wed Feb 01, 2017 08:22 AM UTC
**Owner:** A V Mahesh (AVM)


While creating rpm from latest opensaf-staging, I am getting following 
errors.
64-bit machine
GCC version : 6.1

src/mds/mds_log.cc: In static member function 'static bool MdsLog::Init()':
src/mds/mds_log.cc:93:50: error: expected ')' before 'PRIu32'
snprintf(pid_path, sizeof(pid_path), "/proc/%" PRIu32 "/cmdline", 
process_id);
   ^~
src/mds/mds_log.cc:93:79: error: spurious trailing '%' in format 
[-Werror=format=]
snprintf(pid_path, sizeof(pid_path), "/proc/%" PRIu32 "/cmdline", 
process_id);
^
src/mds/mds_log.cc:93:79: error: too many arguments for format 
[-Werror=format-extra-args]
cc1plus: all warnings being treated as errors
make[3]: *** [src/mds/lib_libopensaf_core_la-mds_log.lo] Error 1
make[3]: Leaving directory 
`/home/chani/Builds/opensaf_latest/rpms/BUILD/opensaf-5.2.M0'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
`/home/chani/Builds/opensaf_latest/rpms/BUILD/opensaf-5.2.M0'
make[1]: *** [all] Error 2
make[1]: Leaving directory 
`/home/chani/Builds/opensaf_latest/rpms/BUILD/opensaf-5.2.M0'
error: Bad exit status from 
/home/chani/Builds/opensaf_latest/rpms/tmp/rpm-tmp.96704 (%build)


RPM build errors:
 Bad exit status from 
/home/chani/Builds/opensaf_latest/rpms/tmp/rpm-tmp.96704 (%build)
make: *** [rpm] Error 1



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2284 IMM: Improper return code without any error string while deleting large number of objects

[Neelakanta Reddy]

The IMM service, says that the default number of supported objects is 1 for 
one CCB., Beyond which there may be corruptuion.in IMM.  if your environment 
can support,  then the limit of  IMMSV_MAX_OBJECTS can be increased  grater 
than 1.


---

** [tickets:#2284] IMM: Improper return code without any error string while 
deleting large number of objects**

**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Wed Feb 01, 2017 07:13 AM UTC by Chani Srivastava
**Last Updated:** Wed Feb 01, 2017 08:34 AM UTC
**Owner:** nobody


Steps to reproduce:

1. Bring up opensaf on a cluster
2. Create around 10k objects
3. Try deleating these objects in one immcfg operation

Output:
Error Returned - error - saImmOmAdminOwnerSet FAILED: SA_AIS_ERR_LIBRARY (2)

No error string stating the cause of failure is returned.

Syslog - immcfg: ER TOO MANY Object Names line:733

Expected behavior - Proper return code with error string should be returned 


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2133 AMF: Rollback admin shutdown/lock SI operation if node failover

[Nagendra Kumar]

- **Type**: defect --> enhancement
- **Comment**:

Changing to enhancement as it changes return types of few admin operation 
mentioned above.



---

** [tickets:#2133] AMF: Rollback admin shutdown/lock SI operation if node 
failover**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Thu Oct 20, 2016 06:49 PM UTC by Minh Hon Chau
**Last Updated:** Wed Feb 01, 2017 07:49 AM UTC
**Owner:** Nagendra Kumar


In scenario of shut down SI, delay QUIESCING csi callback, then reboot the node 
that hosting SU having pending this csi callback. The result of this operation 
looks differently between SGs
- For 2N: the SI Admin state is rollbacked to UNLOCK 
- For Nway: the SI Admin state moves to LOCKED
- In NpM: Haven't tested just browsing SG_NPM::node_fail_si_oper, looks SI 
Admin states rollbacks to UNLOCK

My question is whether the result of these scenario should be consistent? And 
what's the expected outcome?
Also, the handling of node_fail_si_oper for admin lock is not consistent. For 
2N, Admin state remains LOCKED, NpM rollbacks to UNLOCK


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2284 IMM: Improper return code without any error string while deleting large number of objects

[Chani Srivastava]

- Description has changed:

Diff:



--- old
+++ new
@@ -11,4 +11,4 @@
 
 Syslog - immcfg: ER TOO MANY Object Names line:733
 
-Expected behavior - Proper error string should be returned 
+Expected behavior - Proper return code with error string should be returned 



- **Comment**:

>From the spec -

saImmOmCcbObjectDelete()
Return Values:
SA_AIS_ERR_LIBRARY - An unexpected problem occurred in the library (such as
corruption). The library cannot be used anymore.

Deleting large number of objects does not fall in the category of ERR_LIBRARY 



---

** [tickets:#2284] IMM: Improper return code without any error string while 
deleting large number of objects**

**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Wed Feb 01, 2017 07:13 AM UTC by Chani Srivastava
**Last Updated:** Wed Feb 01, 2017 07:40 AM UTC
**Owner:** nobody


Steps to reproduce:

1. Bring up opensaf on a cluster
2. Create around 10k objects
3. Try deleating these objects in one immcfg operation

Output:
Error Returned - error - saImmOmAdminOwnerSet FAILED: SA_AIS_ERR_LIBRARY (2)

No error string stating the cause of failure is returned.

Syslog - immcfg: ER TOO MANY Object Names line:733

Expected behavior - Proper return code with error string should be returned 


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2282 base: `make rpm` giving error with gcc version 6.1.0

[Hans Nordebäck]

- **status**: assigned --> review



---

** [tickets:#2282] base: `make rpm` giving error with gcc version 6.1.0**

**Status:** review
**Milestone:** 5.2.FC
**Created:** Tue Jan 31, 2017 09:38 AM UTC by A V Mahesh (AVM)
**Last Updated:** Tue Jan 31, 2017 09:38 AM UTC
**Owner:** A V Mahesh (AVM)


While creating rpm from latest opensaf-staging, I am getting following 
errors.
64-bit machine
GCC version : 6.1

src/mds/mds_log.cc: In static member function 'static bool MdsLog::Init()':
src/mds/mds_log.cc:93:50: error: expected ')' before 'PRIu32'
snprintf(pid_path, sizeof(pid_path), "/proc/%" PRIu32 "/cmdline", 
process_id);
   ^~
src/mds/mds_log.cc:93:79: error: spurious trailing '%' in format 
[-Werror=format=]
snprintf(pid_path, sizeof(pid_path), "/proc/%" PRIu32 "/cmdline", 
process_id);
^
src/mds/mds_log.cc:93:79: error: too many arguments for format 
[-Werror=format-extra-args]
cc1plus: all warnings being treated as errors
make[3]: *** [src/mds/lib_libopensaf_core_la-mds_log.lo] Error 1
make[3]: Leaving directory 
`/home/chani/Builds/opensaf_latest/rpms/BUILD/opensaf-5.2.M0'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
`/home/chani/Builds/opensaf_latest/rpms/BUILD/opensaf-5.2.M0'
make[1]: *** [all] Error 2
make[1]: Leaving directory 
`/home/chani/Builds/opensaf_latest/rpms/BUILD/opensaf-5.2.M0'
error: Bad exit status from 
/home/chani/Builds/opensaf_latest/rpms/tmp/rpm-tmp.96704 (%build)


RPM build errors:
 Bad exit status from 
/home/chani/Builds/opensaf_latest/rpms/tmp/rpm-tmp.96704 (%build)
make: *** [rpm] Error 1



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets