[tickets] [opensaf:tickets] #2401 imm: Check for response when using MDS SNDRSP
- **status**: review --> fixed
- **Milestone**: 5.0.2 --> 5.17.06
- **Comment**:
develop [code:754f34]
~~~
commit 754f34d5c94cdef78ecddd6d499ea96b6dfe9540
Author: Hung Nguyen
Date: Thu Apr 13 13:58:47 2017 +0700
imm: Check if response is NULL when sending MDS sync message [#2401]
Check if response is NULL when sending MDS sync message.
~~~
release [code:87616d]
~~~
commit 87616d21636686095e5779fe894ec438a2cff701
Author: Hung Nguyen
Date: Thu Apr 13 13:58:47 2017 +0700
imm: Check if response is NULL when sending MDS sync message [#2401]
Check if response is NULL when sending MDS sync message.
~~~
default (hg) [staging:8374cd]
~~~
changeset: 8766:8374cdffbd62
user:Hung Nguyen
date:Thu Apr 13 13:18:36 2017 +0700
summary: imm: Check if response is NULL when sending MDS sync message
[#2401]
~~~
---
** [tickets:#2401] imm: Check for response when using MDS SNDRSP**
**Status:** fixed
**Milestone:** 5.17.06
**Created:** Wed Mar 29, 2017 09:02 AM UTC by Hung Nguyen
**Last Updated:** Wed Apr 05, 2017 07:36 AM UTC
**Owner:** Hung Nguyen
Sometimes, ncsmds_api() returned NCSCC_RC_SUCCESS even when
NCSMDS_INFO.info.svc_send.info.sndrsp.o_rsp is NULL.
The library may crash when that happens
~~~
[New LWP 478]
[New LWP 480]
[New LWP 481]
[New LWP 482]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/lib/opensaf/osafamfd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
Thread 1 (Thread 0x7f00cb1b5780 (LWP 478)):
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
No locals.
#1 0x7f00ca2e8ef1 in osaf_extended_name_lend (value=0x0,
name=0x7ffc65188f50) at src/base/osaf_extended_name.c:82
length =
#2 0x7f00c909a166 in saImmOmSearchNext_2
(searchHandle=searchHandle@entry=1490679334504883525,
objectName=objectName@entry=0x7ffc65188f50,
attributes=attributes@entry=0x7ffc65188ea0) at src/imm/agent/imma_om_api.cc:7580
objName = 0x0
rc =
#3 0x7f00cab8a7dc in immutil_saImmOmSearchNext_2
(searchHandle=1490679334504883525, objectName=0x7ffc65188f50,
attributes=0x7ffc65188ea0) at src/osaf/immutil/immutil.c:1817
rc =
nTries =
#4 0x5619eccab268 in avd_su_config_get
(sg_name="safSg=AmfDemo,safApp=AmfDemo2", sg=sg@entry=0x5619ed8e5b40) at
src/amf/amfd/su.cc:704
searchHandle = 1490679334504883525
su_name = "safSu=SU1,safSg=AmfDemo,safApp=AmfDemo2"
className = 0x5619eccc1a33 "SaAmfSU"
su =
configAttributes = {0x5619ecccebde "saAmfSUType", 0x5619eccced2c
"saAmfSURank", 0x5619eccc1913 "saAmfSUHostedByNode", 0x5619ecccebfd
"saAmfSUHostNodeOrNodeGroup", 0x5619ecccec29 "saAmfSUFailover", 0x5619eccced11
"saAmfSUMaintenanceCampaign", 0x5619eccbb477 "saAmfSUAdminState", 0x0}
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
searchParam = {searchOneAttr = {attrName = 0x5619eccb998c
"SaImmAttrClassName", attrValueType = SA_IMM_ATTR_SASTRINGT, attrValue =
0x7ffc65188ea8}}
__FUNCTION__ = "avd_su_config_get"
error = SA_AIS_OK
rc =
tmp_su_name = {_opaque = {0 }}
attributes = 0x5619ed8e5c70
#5 0x5619ecc61711 in avd_sg_config_get (app_dn="safApp=AmfDemo2",
app=app@entry=0x5619ed8abc40) at src/amf/amfd/sg.cc:470
searchHandle = 1490679334503167364
dn = {_opaque = {29, 24947, 21350, 15719, 27969, 17510, 28005, 11375,
24947, 16742, 28784, 16701, 26221, 25924, 28525, 50, 0 }}
className = 0x5619eccc1a23 "SaAmfSG"
configAttributes = {0x5619eccc84e6 "saAmfSGType", 0x5619eccc8516
"saAmfSGSuHostNodeGroup", 0x5619eccc84f2 "saAmfSGAutoRepair", 0x5619eccc8504
"saAmfSGAutoAdjust", 0x5619eccc857c "saAmfSGNumPrefActiveSUs", 0x5619eccc8594
"saAmfSGNumPrefStandbySUs", 0x5619eccc85ad "saAmfSGNumPrefInserviceSUs",
0x5619eccc85c8 "saAmfSGNumPrefAssignedSUs", 0x5619eccc85e2
"saAmfSGMaxActiveSIsperSU", 0x5619eccc85fb "saAmfSGMaxStandbySIsperSU",
0x5619eccc8615 "saAmfSGAutoAdjustProb", 0x5619eccc862b
"saAmfSGCompRestartProb", 0x5619eccc8642 "saAmfSGCompRestartMax",
0x5619eccc8658 "saAmfSGSuRestartProb", 0x5619eccc866d "saAmfSGSuRestartMax",
0x5619eccc8313 "saAmfSGAdminState", 0x5619eccc833e "osafAmfSGFsmState", 0x0}
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
sg = 0x5619ed8e5b40
searchParam = {searchOneAttr = {attrName = 0x5619eccb998c
"SaImmAttrClassName", attrValueType = SA_IMM_ATTR_SASTRINGT, attrValue =
0x7ffc65189108}}
__FUNCTION__ = "avd_sg_config_get"
error = SA_AIS_OK
rc =
attributes = 0x5619ed8e4370
#6 0x5619ecbf8981 in avd_app_config_get () at src/amf/amfd/app.cc:460
searchHandle = 1490679334315192083
dn = {_opaque = {15, 24947, 16742, 28784, 16701, 26221, 25924, 28525,
50, 0 }}
className = 0x5619eccb9938 "S
[tickets] [opensaf:tickets] #2419 smf: when fixing ticket #2145 a NBC problem was introduced
Suggestion is to disable setting the maintenance campaign attribute on the AMF object by default. And optionally have a setting to enable setting this attribute. This would disable possible AMF NBC as well as the SMF NBC for #2144 and #2145 --- ** [tickets:#2419] smf: when fixing ticket #2145 a NBC problem was introduced** **Status:** unassigned **Milestone:** 5.2.0 **Created:** Mon Apr 10, 2017 11:11 AM UTC by elunlen **Last Updated:** Wed Apr 12, 2017 01:02 PM UTC **Owner:** nobody Previous behavior: The behavior was to ignore a fail to activate a component unless any secondary fault happened. This means that it was for example possible to complete a campaign even if a component failed to start and fix this problem after committing. No action to resume the campaign was needed. After [#2145]: The campaign will always suspend in case of component fail and a resume must be requested for the campaign to continue. NBC: The behavior has changed in such a way that it must be seen as a NBC. The #2145 ticket corrects SMF behavior regarding AIS but is still NBC since the previous behavior is the legacy behavior in previous releases. Proposal 1; Fix if not needed to change setting in runtime e.g. during an upgrade Add a new configuration attribute to the SMF configuration class that makes it possible to select whether the behavior after #2145 shall be used or not. The default setting must be the previous behavior. The setting must have the following properties: - If the attribute does not exist (old model) legacy behavior - If the attribute value is not changed from defaultlegacy behavior - If the attribute value is or invalid legacy behavior - If the attribute value is a valid “ON” settingnew behavior - A request to change the attribute in runtime shall always be rejected Proposal 2; Fix if change has to be made during upgrade: Add a new configuration attribute to the SMF configuration class that makes it possible to select whether the behavior after #2145 shall be used or not. The default setting must be the previous behavior. The setting must have the following properties: - If the attribute does not exist (old model) legacy behavior - If the attribute value is not changed from defaultlegacy behavior - If the attribute value is or invalid legacy behavior - If the attribute value is a valid “ON” settingnew behavior - Attribute value must be possible to change in runtime in “idle” state (no campaign is executing) - Attribute value must be possible to change in runtime in campaign init state. Note that if changed here the new setting must be used in the rest of the campaign --- 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] #2418 imm: Info of dead IMMND remains in standby IMMD
- **status**: accepted --> review --- ** [tickets:#2418] imm: Info of dead IMMND remains in standby IMMD** **Status:** review **Milestone:** 5.0.2 **Created:** Mon Apr 10, 2017 10:23 AM UTC by Hung Nguyen **Last Updated:** Mon Apr 10, 2017 10:24 AM UTC **Owner:** Hung Nguyen **Attachments:** - [log.tgz](https://sourceforge.net/p/opensaf/tickets/2418/attachment/log.tgz) (149.4 kB; application/x-compressed) When Standby IMMD is up at the same time with a IMMND exiting, the info of that IMMND might not be removed from **immnd_tree** of the Standby IMMD. Details of the problem is explained in the sequence diagram below [sequence diagram](http://sequencediagram.org/index.html?initialData=A4QwTgLglgxloDsIAICCBhAKgWgJIFl8ARAKFElnhCWQGVMAhPQ0kkAIwHsAPZTgNwCmYOo2bFkAYjCCAJgC5kRAPIB1AHLJBQmgDMwnALbIC+dUT4JkCTrMHIAGiRJdeA4aKamii3AigoxLQAOgh+Acj4DOjI1LLIAM6CgdHIBgA29hCcdBBx7ACezvReLMjYAHxoWOIW8uic6bIJBQgwaYIAjgCuggkQziQYON7lVSW1ig1NLW0dCcCcCEmhEAAW9qbmyOlQ-chQbenddgnI65uE20vWtvZOzhw8fEIiw7VSMgpKapragnoDMYthYbjY7I5nK4Xh53t4ADQTbyKTAbExXCx7DqGdzxfRGaojMrsbooGSGECHM6HTy1IA) SC-5 was Active, SC-2 was Standby, IMMND on SC-1 was exiting ~~~ 18:35:03 SC-1 osafimmnd[441]: exiting for shutdown 18:35:03 SC-2 osafrded[413]: NO RDE role set to STANDBY 18:35:03 SC-2 osafimmd[430]: NO MDS event from svc_id 25 (change:3, dest:568511936070075) 18:35:03 SC-2 osafimmd[430]: NO MDS event from svc_id 25 (change:3, dest:567412424442298) 18:35:03 SC-2 osafimmd[430]: NO MDS event from svc_id 25 (change:3, dest:566312912814523) 18:35:03 SC-2 osafimmd[430]: NO MDS event from svc_id 25 (change:3, dest:565213401186744) 18:35:03 SC-5 osafimmd[433]: NO MDS event from svc_id 25 (change:4, dest:564113889558969) ~~~ Down event for IMMND@SC-1 was received on SC-5 but not on SC-2. **The symptoms:** 1. If the down IMMND is the corrdinator, that results in when that Standby IMMD becomes Active, it fails to elect new coordinator as there's already a coordinator in the **immnd_tree**. ~~~ 18:35:11 SC-2 osafimmd[430]: WA IMMND coordinator at 2050f apparently crashed => electing new coord ~~~ No more logs about newly elected coordinator were printed out. 2. When IMMND@SC-1 is up again, it will fail to introduce to IMMD because the IMMD already have IMMND@SC-1 in **immnd_tree** with a wrong epoch. ~~~ 18:35:29 SC-1 osafimmnd[441]: NO SERVER STATE: IMM_SERVER_ANONYMOUS --> IMM_SERVER_CLUSTER_WAITING 18:35:29 SC-1 osafimmnd[441]: NO This IMMND is now the NEW Coord 18:35:29 SC-1 osafimmnd[441]: ER 3 > 0, exiting ~~~ --- 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] #2418 imm: Info of dead IMMND remains in standby IMMD
I the defect only occurs in a headless system, then I think the ticket slogan, or at least the description sholud say so. --- ** [tickets:#2418] imm: Info of dead IMMND remains in standby IMMD** **Status:** review **Milestone:** 5.0.2 **Created:** Mon Apr 10, 2017 10:23 AM UTC by Hung Nguyen **Last Updated:** Thu Apr 13, 2017 09:49 AM UTC **Owner:** Hung Nguyen **Attachments:** - [log.tgz](https://sourceforge.net/p/opensaf/tickets/2418/attachment/log.tgz) (149.4 kB; application/x-compressed) When Standby IMMD is up at the same time with a IMMND exiting, the info of that IMMND might not be removed from **immnd_tree** of the Standby IMMD. Details of the problem is explained in the sequence diagram below [sequence diagram](http://sequencediagram.org/index.html?initialData=A4QwTgLglgxloDsIAICCBhAKgWgJIFl8ARAKFElnhCWQGVMAhPQ0kkAIwHsAPZTgNwCmYOo2bFkAYjCCAJgC5kRAPIB1AHLJBQmgDMwnALbIC+dUT4JkCTrMHIAGiRJdeA4aKamii3AigoxLQAOgh+Acj4DOjI1LLIAM6CgdHIBgA29hCcdBBx7ACezvReLMjYAHxoWOIW8uic6bIJBQgwaYIAjgCuggkQziQYON7lVSW1ig1NLW0dCcCcCEmhEAAW9qbmyOlQ-chQbenddgnI65uE20vWtvZOzhw8fEIiw7VSMgpKapragnoDMYthYbjY7I5nK4Xh53t4ADQTbyKTAbExXCx7DqGdzxfRGaojMrsbooGSGECHM6HTy1IA) SC-5 was Active, SC-2 was Standby, IMMND on SC-1 was exiting ~~~ 18:35:03 SC-1 osafimmnd[441]: exiting for shutdown 18:35:03 SC-2 osafrded[413]: NO RDE role set to STANDBY 18:35:03 SC-2 osafimmd[430]: NO MDS event from svc_id 25 (change:3, dest:568511936070075) 18:35:03 SC-2 osafimmd[430]: NO MDS event from svc_id 25 (change:3, dest:567412424442298) 18:35:03 SC-2 osafimmd[430]: NO MDS event from svc_id 25 (change:3, dest:566312912814523) 18:35:03 SC-2 osafimmd[430]: NO MDS event from svc_id 25 (change:3, dest:565213401186744) 18:35:03 SC-5 osafimmd[433]: NO MDS event from svc_id 25 (change:4, dest:564113889558969) ~~~ Down event for IMMND@SC-1 was received on SC-5 but not on SC-2. **The symptoms:** 1. If the down IMMND is the corrdinator, that results in when that Standby IMMD becomes Active, it fails to elect new coordinator as there's already a coordinator in the **immnd_tree**. ~~~ 18:35:11 SC-2 osafimmd[430]: WA IMMND coordinator at 2050f apparently crashed => electing new coord ~~~ No more logs about newly elected coordinator were printed out. 2. When IMMND@SC-1 is up again, it will fail to introduce to IMMD because the IMMD already have IMMND@SC-1 in **immnd_tree** with a wrong epoch. ~~~ 18:35:29 SC-1 osafimmnd[441]: NO SERVER STATE: IMM_SERVER_ANONYMOUS --> IMM_SERVER_CLUSTER_WAITING 18:35:29 SC-1 osafimmnd[441]: NO This IMMND is now the NEW Coord 18:35:29 SC-1 osafimmnd[441]: ER 3 > 0, exiting ~~~ --- 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] #2426 mds: MDS send failure
--- ** [tickets:#2426] mds: MDS send failure** **Status:** unassigned **Milestone:** 5.17.08 **Created:** Thu Apr 13, 2017 11:22 AM UTC by Hung Nguyen **Last Updated:** Thu Apr 13, 2017 11:22 AM UTC **Owner:** nobody **Attachments:** - [logs.tgz](https://sourceforge.net/p/opensaf/tickets/2426/attachment/logs.tgz) (1.8 MB; application/x-compressed) IMMD@SC-2 recived a message from IMMND@SC-1 but failed to send a message back to IMMND@SC-1. Both IMMD and IMMND use MDS_SENDTYPE_SND. RDE also got that failure. ~~~ 18:33:18 SC-1 osafrded[183]: WA Failed to send RDE_MSG_PEER_INFO_RESP(4) to 2020f9d120640 18:33:18 SC-1 osafrded[183]: message repeated 2 times: [ WA Failed to send RDE_MSG_PEER_INFO_RESP(4) to 2020f9d120640] 18:33:18 SC-2 osafrded[183]: WA Failed to send RDE_MSG_PEER_INFO_RESP(4) to 2010fc4b8a390 18:33:18 SC-2 osafimmd[202]: WA IMMD - MDS Send Failed 18:33:18 SC-2 osafimmd[202]: ER Failed to send accept message to IMMND 2010f ~~~ Attached is the logs. --- 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] #1439 log: log file size is not reset to zero (0) when log file is created
- **status**: review --> fixed - **assigned_to**: Canh Truong --> nobody - **Milestone**: 5.17.08 --> 5.17.06 - **Comment**: # Mercurial repos changeset: 8767:7a8fb4ee6f4c branch: opensaf-5.1.x parent: 8758:92cbf69f8591 user:Canh Van Truong date:Tue Apr 11 16:27:20 2017 +0200 summary: log: fix log file size not reset to zero when creating [#1439] changeset: 8768:c1cc2a915e72 tag: tip parent: 8766:8374cdffbd62 user:Canh Van Truong date:Thu Apr 13 10:53:28 2017 +0200 summary: log: fix log file size not reset to zero when creating [#1439] # Git repos release [[code: 150bfc](https://sourceforge.net/p/opensaf/code/ci/150bfc886b301d026e6ef3fa48d1ffb325bbda26)] commit 150bfc886b301d026e6ef3fa48d1ffb325bbda26 Author: Vu Minh Nguyen Date: Thu Apr 13 13:55:34 2017 +0200 log: fix log file size not reset to zero when creating [#1439] release [[code: 906c76](https://sourceforge.net/p/opensaf/code/ci/906c768bd69b48965188ab4102214aef2a04af4e)] commit 906c768bd69b48965188ab4102214aef2a04af4e Author: Vu Minh Nguyen Date: Thu Apr 13 14:08:13 2017 +0200 log: fix log file size not reset to zero when creating [#1439] --- ** [tickets:#1439] log: log file size is not reset to zero (0) when log file is created** **Status:** fixed **Milestone:** 5.17.06 **Created:** Mon Aug 10, 2015 07:23 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Apr 10, 2017 01:40 PM UTC **Owner:** nobody When updating attributes (e.g: logFileFmt, pathname, filename, etc.), log server closes the openining cfg/log files and creates new ones. The problem is that logsv keeps the log file size of previous one instead of reseting to zero (0) for the newly created log file. --- 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] #2409 amf: Issues with the printing of CLC CLI command environment variables in traces
- **status**: assigned --> review --- ** [tickets:#2409] amf: Issues with the printing of CLC CLI command environment variables in traces** **Status:** review **Milestone:** 5.17.06 **Created:** Mon Apr 03, 2017 07:07 AM UTC by Nguyen TK Luu **Last Updated:** Thu Apr 13, 2017 02:27 AM UTC **Owner:** Nguyen TK Luu There are following 2 issues with the printing of CLC CLI command environment variables of a component in amfnd traces: - Environment variables set in both CompType and Comp got doubly printed. - Environment variables with incorrect format (i.e not 'var=value') got printed with weird output. Reproduce using amf_demo testapp with the following set of environment variables: safVersion=1,safCompType=AmfDemo1 ... saAmfCtDefCmdEnv AMF_DEMO_VAR1=CT_VALUE1 AMF_DEMO_VAR2=CT_VALUE2 safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1 ... saAmfCompCmdEnv AMF_DEMO_VAR2=COMP1_OVERLOAD_VALUE2 AMF_DEMO_VAR3 AMF_DEMO_VAR4 = COMP1_VALUE4 Apr 3 13:21:15.680056 osafamfnd [290:290:src/amf/amfnd/clc.cc:2927] >> avnd_comp_clc_cmd_execute: 'safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1':CLC CLI command type:'AVND_COMP_CLC_CMD_TYPE_INSTANTIATE(1)' Apr 3 13:21:15.680147 osafamfnd [290:290:src/amf/amfnd/clc.cc:2984] ER Unknown enviroment variable format 'AMF_DEMO_VAR3'. Should be 'var=value' Apr 3 13:21:15.680168 osafamfnd [290:290:src/amf/amfnd/clc.cc:3091] T1 CLC CLI script:'/opt/amf_demo/amf_demo_script' Apr 3 13:21:15.680173 osafamfnd [290:290:src/amf/amfnd/clc.cc:3093] T1 CLC CLI command arguments[1] ='instantiate' Apr 3 13:21:15.680176 osafamfnd [290:290:src/amf/amfnd/clc.cc:3096] T1 CLC CLI command timeout: In nano secs:100 In milli secs: 1 Apr 3 13:21:15.680180 osafamfnd [290:290:src/amf/amfnd/clc.cc:3100] T1 CLC CLI command env variable name = 'AMF_DEMO_VAR2': value ='CT_VALUE2' Apr 3 13:21:15.680183 osafamfnd [290:290:src/amf/amfnd/clc.cc:3100] T1 CLC CLI command env variable name = 'AMF_DEMO_VAR1': value ='CT_VALUE1' Apr 3 13:21:15.680187 osafamfnd [290:290:src/amf/amfnd/clc.cc:3100] T1 CLC CLI command env variable name = 'AMF_DEMO_VAR4 ': value =' COMP1_VALUE4' Apr 3 13:21:15.680191 osafamfnd [290:290:src/amf/amfnd/clc.cc:3100] T1 CLC CLI command env variable name = '(null)': value ='(null)' Apr 3 13:21:15.680194 osafamfnd [290:290:src/amf/amfnd/clc.cc:3100] T1 CLC CLI command env variable name = 'AMF_DEMO_VAR2': value ='COMP1_OVERLOAD_VALUE2' Apr 3 13:21:15.680197 osafamfnd [290:290:src/amf/amfnd/clc.cc:3100] T1 CLC CLI command env variable name = 'SA_AMF_COMPONENT_NAME': value ='safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1' Apr 3 13:21:15.680455 osafamfnd [290:290:src/amf/amfnd/clc.cc:3132] T2 The CLC CLI command execution success Apr 3 13:21:15.680505 osafamfnd [290:290:src/amf/amfnd/clc.cc:3136] T2 success Apr 3 13:21:15.680511 osafamfnd [290:290:src/amf/amfnd/clc.cc:3145] << avnd_comp_clc_cmd_execute: 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] #2410 samples: amf_demo_script missed to define $piddir
- **Milestone**: 5.17.06 --> future
---
** [tickets:#2410] samples: amf_demo_script missed to define $piddir**
**Status:** review
**Milestone:** future
**Created:** Mon Apr 03, 2017 11:43 AM UTC by Nguyen TK Luu
**Last Updated:** Thu Apr 13, 2017 01:19 AM UTC
**Owner:** Nguyen TK Luu
The $piddir variable (containing path to amf_demo component's pid file) is
missed to be defined in amf_demo_script. This could lead to the amf_demo
process not getting truely killed in some cases when cleanup is called (e.g
when invoking saAmfComponentErrorReport()), leaving the process unmanaged by
AMF.
~~~
samples/amf/sa_aware/amf_demo_script:
# Source LSB functions library
. /lib/lsb/init-functions
compname=`echo $SA_AMF_COMPONENT_NAME | md5sum | awk '{print $1}'`
pidfile="$piddir/${compname}.pid"
stop()
{
echo -n "Stopping $prog: "
killproc -p $pidfile $binary
RETVAL=$?
if [ $RETVAL -ne 0 ]; then
logger -st $name "killproc $binary failed"
fi
return $RETVAL
}
~~~
---
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] #2410 samples: amf_demo_script missed to define $piddir
- **Milestone**: future --> 5.17.06
---
** [tickets:#2410] samples: amf_demo_script missed to define $piddir**
**Status:** review
**Milestone:** 5.17.06
**Created:** Mon Apr 03, 2017 11:43 AM UTC by Nguyen TK Luu
**Last Updated:** Thu Apr 13, 2017 01:08 PM UTC
**Owner:** Nguyen TK Luu
The $piddir variable (containing path to amf_demo component's pid file) is
missed to be defined in amf_demo_script. This could lead to the amf_demo
process not getting truely killed in some cases when cleanup is called (e.g
when invoking saAmfComponentErrorReport()), leaving the process unmanaged by
AMF.
~~~
samples/amf/sa_aware/amf_demo_script:
# Source LSB functions library
. /lib/lsb/init-functions
compname=`echo $SA_AMF_COMPONENT_NAME | md5sum | awk '{print $1}'`
pidfile="$piddir/${compname}.pid"
stop()
{
echo -n "Stopping $prog: "
killproc -p $pidfile $binary
RETVAL=$?
if [ $RETVAL -ne 0 ]; then
logger -st $name "killproc $binary failed"
fi
return $RETVAL
}
~~~
---
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] #2427 Debian building framework
--- ** [tickets:#2427] Debian building framework** **Status:** accepted **Milestone:** future **Created:** Thu Apr 13, 2017 04:23 PM UTC by Jonas Arndt **Last Updated:** Thu Apr 13, 2017 04:23 PM UTC **Owner:** Jonas Arndt This ticker aims to enhance the build framework so that it also produces Debian packages. Further details will go into this tickets as details are uncovered. --- 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] #2390 lck: integrate with CLM
- **status**: accepted --> review --- ** [tickets:#2390] lck: integrate with CLM** **Status:** review **Milestone:** 5.17.08 **Created:** Tue Mar 21, 2017 04:19 PM UTC by Alex Jones **Last Updated:** Mon Apr 10, 2017 01:40 PM UTC **Owner:** Alex Jones According to LCK-B-03-01, the lock service should not provide service to processes on cluster nodes which are not in the cluster membership. --- 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
