[tickets] [opensaf:tickets] #2425 lck: implement saLckLimitGet
- **status**: accepted --> review - **Blocker**: --> False --- ** [tickets:#2425] lck: implement saLckLimitGet** **Status:** review **Milestone:** 5.17.08 **Created:** Wed Apr 12, 2017 05:04 PM UTC by Alex Jones **Last Updated:** Wed Apr 12, 2017 05:04 PM UTC **Owner:** Alex Jones This ticket is an enhancement to LCK to add saLckLimitGet function. --- 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] #2402 base: "hardening" use of lockfile in opensafd
- **status**: unassigned --> fixed --- ** [tickets:#2402] base: "hardening" use of lockfile in opensafd** **Status:** fixed **Milestone:** 5.2.RC2 **Created:** Wed Mar 29, 2017 10:40 AM UTC by Hans Nordebäck **Last Updated:** Mon Apr 24, 2017 01:37 PM UTC **Owner:** Hans Nordebäck "hardening" use of lockfile in opensafd --- 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] #2459 improve state report for opensafd
- **summary**: graceful shutdown of opensafd --> improve state report for opensafd --- ** [tickets:#2459] improve state report for opensafd** **Status:** assigned **Milestone:** 5.17.08 **Created:** Thu May 11, 2017 12:42 PM UTC by Rafael Odzakow **Last Updated:** Thu May 11, 2017 12:42 PM UTC **Owner:** Rafael Odzakow Today there is no way for SMF (or others) to know when opensafd start is completed. Calling stop when a start is ongoing will not stop opensafd so the reboot will not shutdown opensafd. Resulting in errors reports from several components. Internally opensafd creates a lock file during start/stop. To allow SMF and others to query the state this ticket will use the opensafd lockfile to report the status of start/stop when requested with "opensafd status" --- 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] #2459 graceful shutdown of opensafd
--- ** [tickets:#2459] graceful shutdown of opensafd** **Status:** assigned **Milestone:** 5.17.08 **Created:** Thu May 11, 2017 12:42 PM UTC by Rafael Odzakow **Last Updated:** Thu May 11, 2017 12:42 PM UTC **Owner:** Rafael Odzakow Today there is no way for SMF (or others) to know when opensafd start is completed. Calling stop when a start is ongoing will not stop opensafd so the reboot will not shutdown opensafd. Resulting in errors reports from several components. Internally opensafd creates a lock file during start/stop. To allow SMF and others to query the state this ticket will use the opensafd lockfile to report the status of start/stop when requested with "opensafd status" --- 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] #2416 amf: Problem of assignment failover during stop of both SCs (SC Absence)
Hi Nagu, The log/trace is in previous comment. I think you would see the issue of creation/deletion IMM assignment object in the trace file. Assignment failover of 2N works as normal, except the creation/deletion IMM assignment objects are queued up, thus they won't be writen to IMM when last controller goes down. thanks, Minh --- ** [tickets:#2416] amf: Problem of assignment failover during stop of both SCs (SC Absence)** **Status:** review **Milestone:** 5.17.06 **Created:** Mon Apr 10, 2017 04:39 AM UTC by Minh Hon Chau **Last Updated:** Thu May 11, 2017 09:53 AM UTC **Owner:** Minh Hon Chau In configuration of 2N application which has active SU hosted in controller and the other standby SU is hosted in payload, the event of stopping both SCs could generate a su_si assignment message towards standby SU to change HA state to active. - In case this su_si assignment message is buffered and comes before MDSNCS_DOWN, node is rebooted - In other cases where MDSNCS_DOWN comes before su_si assignment, currently amfnd does not ignore this su_si assignment. amfnd should ignore this su_si assignment message as similiar to other messages like su_pres, su_reg Testing on similar application's configuration continues, problem found will be added in comments --- 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] #2416 amf: Problem of assignment failover during stop of both SCs (SC Absence)
>>Initially, SU1 (in SC1) and SU2 (in SC2) have active and standby assignment. >>Abruptly stop SC1 and SC2, SU3 (PL-3) appears to have standby assignment. Does this happen because SC-1 Amfd sees that SC-2 is going down so it sends standby assignment to SU3(PL-3) ? But this can happen only when PL-3 down has been recieved by SC-1 Amfd and has processed and then sent Standby to SU3, but all the RTA updates would have missed because SC-1 also went down. This results in SU1 is Act and two Standby SU2 and SU3. Am I right? Do you have traces and the time it has happened, I just want to analyse it. --- ** [tickets:#2416] amf: Problem of assignment failover during stop of both SCs (SC Absence)** **Status:** review **Milestone:** 5.17.06 **Created:** Mon Apr 10, 2017 04:39 AM UTC by Minh Hon Chau **Last Updated:** Tue May 09, 2017 06:42 AM UTC **Owner:** Minh Hon Chau In configuration of 2N application which has active SU hosted in controller and the other standby SU is hosted in payload, the event of stopping both SCs could generate a su_si assignment message towards standby SU to change HA state to active. - In case this su_si assignment message is buffered and comes before MDSNCS_DOWN, node is rebooted - In other cases where MDSNCS_DOWN comes before su_si assignment, currently amfnd does not ignore this su_si assignment. amfnd should ignore this su_si assignment message as similiar to other messages like su_pres, su_reg Testing on similar application's configuration continues, problem found will be added in comments --- 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] #2458 amfd: unnecessary coredumps during shutdown
- **status**: unassigned --> review - **Component**: unknown --> amf --- ** [tickets:#2458] amfd: unnecessary coredumps during shutdown** **Status:** review **Milestone:** 5.17.06 **Created:** Wed May 10, 2017 08:14 AM UTC by Gary Lee **Last Updated:** Wed May 10, 2017 08:49 AM UTC **Owner:** nobody If a controller is started and stopped quickly, a coredump can occur if IMM has been shutdown while AMFD is trying to read from it. ``` 2017-04-28 00:52:12 SC-2 opensafd: Stopping OpenSAF Services 2017-04-28 00:52:12 SC-2 opensafd: opensafd start/stop already in progress. Unable to continue 2017-04-28 00:52:12 SC-2 opensafd: To forcefully start/stop OpenSAF remove /var/lock/subsys/opensafd_inprogress 2017-04-28 00:52:12 SC-2 osafamfd[479]: WA configuration validation error: Required attribute saAmfCtDefQuiescingCompleteTimeout not configured for 'safVersion=5.5.5,safCompType=AmfDemo2' 2017-04-28 00:52:12 SC-2 osafamfwd[502]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafamfnd[487]: NO Shutdown initiated 2017-04-28 00:52:12 SC-2 osafrded[416]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafamfnd[487]: NO Terminating all AMF components 2017-04-28 00:52:12 SC-2 osaffmd[424]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafsmfnd[567]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafckptd[506]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafckptnd[516]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafclmd[469]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafclmna[406]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafsmfd[608]: MDTM:SOCKET recd_bytes :0, conn lost with dh server 2017-04-28 00:52:12 SC-2 osafsmfnd[567]: MDTM:SOCKET recd_bytes :0, conn lost with dh server 2017-04-28 00:52:12 SC-2 osafsmfd[608]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osaflogd[452]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafimmd[433]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osaftransportd[405]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafimmnd[443]: ER Failed to Send Message bufflen :445 err :Bad file descriptor 2017-04-28 00:52:12 SC-2 osafimmnd[443]: WA MDS Send Failed 2017-04-28 00:52:12 SC-2 osafimmnd[443]: WA Error code 2 returned for message type 17 - ignoring 2017-04-28 00:52:12 SC-2 osafimmnd[443]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafntfimcnd[729]: MDTM:TCP DBSRsock unable to connect err :Connection refused 2017-04-28 00:52:12 SC-2 osafntfimcnd[729]: ER ntfimcn_imm_init saImmOiInitialize_2 failed SA_AIS_ERR_LIBRARY (2) 2017-04-28 00:52:12 SC-2 osafntfimcnd[729]: ER ntfimcn_imm_init() Fail 2017-04-28 00:52:12 SC-2 osafntfd[461]: exiting for shutdown 2017-04-28 00:52:12 SC-2 osafamfnd[487]: NO Terminated all AMF components 2017-04-28 00:52:12 SC-2 osafamfnd[487]: NO Shutdown completed, exiting 2017-04-28 00:52:12 SC-2 osafamfnd[487]: exiting for shutdown 2017-04-28 00:52:22 SC-2 osafamfd[479]: ER Failed to Send Message bufflen :445 err :Bad file descriptor 2017-04-28 00:52:22 SC-2 osafamfd[479]: src/amf/amfd/comp.cc:814: avd_comp_config_get: Assertion 'rc == SA_AIS_ERR_NOT_EXIST' failed. ``` ``` Thread 1 (Thread 0x7f539951a780 (LWP 479)): #0 0x7f5397724c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 resultvar = 0 pid = 479 selftid = 479 #1 0x7f5397728028 in __GI_abort () at abort.c:89 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 140731000339776, 139997029164327, 5, 0, 0, 139996999666992, 94070744203264, 140731000339776, 94070734617616, 139997029192917, 1, 139997000668251, 0, 0, 139997003564896}}, sa_flags = 0, sa_restorer = 0x0} sigs = {__val = {32, 0 }} #2 0x7f539855e70c in __osafassert_fail (__file=0x558e8cd9437a "src/amf/amfd/comp.cc", __line=814, __func=0x558e8cd95dd0 "avd_comp_config_get", __assertion=0x558e8cd94b15 "rc == SA_AIS_ERR_NOT_EXIST") at src/base/sysf_def.c:286 No locals. #3 0x558e8cbcf750 in avd_comp_config_get (su_name="safSu=SC-2,safSg=NoRed,safApp=OpenSAF", su=0x558e8d4a9c80) at src/amf/amfd/comp.cc:814 searchHandle = 149532075833352 className = 0x558e8cd94a96 "SaAmfComp" configAttributes = {0x558e8cd9463a "saAmfCompType", 0x558e8cd94b37 "saAmfCompCmdEnv", 0x558e8cd9483a "saAmfCompInstantiateCmdArgv", 0x558e8cd94856 "saAmfCompInstantiateTimeout", 0x558e8cd94872 "saAmfCompInstantiationLevel", 0x558e8cd94890 "saAmfCompNumMaxInstantiateWithoutDelay", 0x558e8cd94b48 "saAmfCompNumMaxInstantiateWithDelay", 0x558e8cd948b8 "saAmfCompDelayBetweenInstantiateAttempts", 0x558e8cd948e1 "saAmfCompTerminateCmdArgv", 0x558e8cd948fb "saAmfCompTerminateTimeout", 0x558e8cd94915 "saAmfCompCleanupCmdArgv", 0x558e8cd9492d "saAmfCompCleanupTimeout", 0x558e8cd94945 "saAmfCompAmStartCmdArgv", 0x558e8cd9495d "saAmfCompAmStartTimeout", 0x558e8cd94978 "saAmfCompNumMaxAmStartAttempts", 0x558e8cd94997 "saAmfCompAmStopCmdArgv", 0x558e8cd949ae
[tickets] [opensaf:tickets] #2354 amf: support amf tool command to know AMF cluster/nodes status.
- **status**: review --> fixed - **Blocker**: --> True - **Comment**: 5.17.08: commit aaf6c29d6e9dc59f44f37d720c043dd6c8dad4a4 Author: Praveen Date: Thu May 11 13:59:17 2017 +0530 amf: support amf tool command to know AMF cluster/nodes status [#2354] default (hg): changeset: 8792:db2ba23d2963 tag: tip user:Praveen Malviya date:Thu May 11 14:30:23 2017 +0530 summary: amf: support amf tool command to know AMF cluster/nodes status [#2354] --- ** [tickets:#2354] amf: support amf tool command to know AMF cluster/nodes status.** **Status:** fixed **Milestone:** 5.17.08 **Created:** Wed Mar 08, 2017 07:28 AM UTC by Praveen **Last Updated:** Fri Apr 14, 2017 11:57 AM UTC **Owner:** Praveen This discussion ticket is being raised based on a user list query dated March 1st, 2017. The query says: "We have enabled the new feature "SC Absence" of OpenSAF 5.x in our product, it works good so far. Now we need to make some actions when PLD go in/out "SC Absence" mode, we have to find a way in PLD to detect if it is being in "SC Absent" mode or not. So, does anyone knows how to make it by a utility/tool and C code(i.e. OpenSAF API) as well? " I think we do not have any API which can be used to query OpenSAF for knowing SC absence state. MDS up and down events of directors can be used to decide SC absence state as some agents are and node directors are using. But this will add lot of code in application. Please update this ticket for a known or proposed solution. --- 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