opensaf-tickets — Notifications from the ticket system

[tickets] [opensaf:tickets] #3397 MDS: Explicit subscription replay uses wrong state/version after implicit subscribe

[Thien M. H. <thi...@us...>]

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

commit ea0c7cce3fa4593f556016fa3506126c6d3f5c21 (HEAD -> develop, origin/develop, ticket-3397-1, ticket-3397)
Author: Thien Minh Huynh <thi...@en...>
Date:   Wed Apr 15 06:25:48 2026 +0200
 
    mds: add test case for explicit replay [#3397]
 
commit 6cbda59cf873e54cd7d67334e48dac562b187504
Author: Thien Minh Huynh <thi...@en...>
Date:   Thu Apr 9 10:03:34 2026 +0700
 
    mds: fix explicit replay callback metadata [#3397]



---

**[tickets:#3397] MDS: Explicit subscription replay uses wrong state/version after implicit subscribe**

**Status:** fixed
**Milestone:** 5.27.01
**Created:** Mon Apr 13, 2026 08:31 AM UTC by Thien Minh Huynh
**Last Updated:** Thu Apr 23, 2026 03:09 AM UTC
**Owner:** Thien Minh Huynh


Steps to reproduce
------------------
1. Start an MDS test setup with an ADEST subscriber and a VDEST providing NCSMDS_SVC_ID_INTERNAL_MIN.
2. Create an implicit subscription by sending a message from NCSMDS_SVC_ID_EXTERNAL_MIN to NCSMDS_SVC_ID_INTERNAL_MIN on the active VDEST.
3. Convert that existing implicit subscription into an explicit subscription using mds_service_subscribe().
4. Retrieve the replayed service event with mds_service_retrieve().
5. Verify the replayed event/version.
6. Variant A: leave the VDEST active and expect an NCSMDS_UP replay with the current active version.
7. Variant B: demote the active VDEST to standby first, let await-active run, then expect an NCSMDS_NO_ACTIVE replay with the last active version.
 
Observed behaviour
------------------

When an implicit subscription is converted to an explicit subscription, the replayed service event does not reliably reflect the correct state/version of the remote service.
There are two incorrect replay scenarios:
 
- the explicit replay may fail to return the current active UP version
- the explicit replay may fail to return the last-active NO_ACTIVE version during await-active
 
Expected behaviour
------------------
Converting an implicit subscription to an explicit subscription should replay the correct current service state:
 
- if the remote service is active, replay NCSMDS_UP with the current active version
- if the active instance has gone away and await-active is running, replay NCSMDS_NO_ACTIVE with the last active version

use testapi to reproduce


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3396 MDS: NEW_ACTIVE metadata is incorrect after MxN VDEST active-to-standby transition

[Thien M. H. <thi...@us...>]

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

commit 8ec9b8dbac32390ffb7b97833842007bc6aaef6f (HEAD -> develop, origin/develop, ticket-3396)

Author: Thien Minh Huynh <thi...@en...>

Date:   Thu Apr 9 11:30:52 2026 +0700
 
    mds: fix MxN standby on service operation down [#3396]
 
commit 544764998d9ec61060e8dd1f5a81f2e8bdb7c690

Author: Thien Minh Huynh <thi...@en...>

Date:   Thu Apr 9 10:06:41 2026 +0700
 
    mds: add test case for verify replacement active [#3396]
 
commit c99a9e0a8a1bb4c89f5c8af3504558934093f9bc

Author: Thien Minh Huynh <thi...@en...>

Date:   Thu Apr 9 10:06:31 2026 +0700
 
    mds: fix replacement active callback metadata [#3396]
 



---

**[tickets:#3396] MDS: NEW\_ACTIVE metadata is incorrect after MxN VDEST active-to-standby transition**

**Status:** fixed
**Milestone:** 5.27.01
**Created:** Mon Apr 13, 2026 08:08 AM UTC by Thien Minh Huynh
**Last Updated:** Wed Apr 22, 2026 09:44 AM UTC
**Owner:** Thien Minh Huynh


Steps to reproduce
------------------
1. Start MDS in two separate processes.
2. In the first process, create MxN VDEST 1001 and install service 600 with private version 1.
3. Change VDEST 1001 to ACTIVE in the first process.
4. In the subscriber process, install service 500 and subscribe to service 600 with INTRACHASSIS scope.
5. Verify that subscriber 500 receives an initial UP event for service 600 with private version 1.
6. In the second process, create the same MxN VDEST 1001 and install a replacement instance of service 600 with private version 2.
7. Promote the second process VDEST 1001 to ACTIVE and demote the first process VDEST 1001 to STANDBY.
8. Retrieve subscription events on service 500 after the role transition.
 
Observed behaviour
------------------
After the ACTIVE to STANDBY handover on MxN VDEST 1001, the subscriber does receive the expected sequence of service-change notifications, including NO_ACTIVE followed by NEW_ACTIVE. However, the payload associated with the NEW_ACTIVE notification is
not preserved from the replacement active instance.
 
 
Expected behaviour
------------------
When the original ACTIVE instance of service 600 is demoted to STANDBY and the replacement instance becomes ACTIVE on the same MxN VDEST, the subscriber should receive:
1. a NO_ACTIVE event reflecting the demoted instance, then
2. a NEW_ACTIVE event reflecting the replacement instance.
 
The NEW_ACTIVE metadata  must report the replacement service attributes, specifically:
- role = ACTIVE
- private version = 2


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3397 MDS: Explicit subscription replay uses wrong state/version after implicit subscribe

[Thien M. H. <thi...@us...>]

Thank you. I will update in the next version.


---

**[tickets:#3397] MDS: Explicit subscription replay uses wrong state/version after implicit subscribe**

**Status:** review
**Milestone:** 5.27.01
**Created:** Mon Apr 13, 2026 08:31 AM UTC by Thien Minh Huynh
**Last Updated:** Fri Apr 17, 2026 06:03 AM UTC
**Owner:** Thien Minh Huynh


Steps to reproduce
------------------
1. Start an MDS test setup with an ADEST subscriber and a VDEST providing NCSMDS_SVC_ID_INTERNAL_MIN.
2. Create an implicit subscription by sending a message from NCSMDS_SVC_ID_EXTERNAL_MIN to NCSMDS_SVC_ID_INTERNAL_MIN on the active VDEST.
3. Convert that existing implicit subscription into an explicit subscription using mds_service_subscribe().
4. Retrieve the replayed service event with mds_service_retrieve().
5. Verify the replayed event/version.
6. Variant A: leave the VDEST active and expect an NCSMDS_UP replay with the current active version.
7. Variant B: demote the active VDEST to standby first, let await-active run, then expect an NCSMDS_NO_ACTIVE replay with the last active version.
 
Observed behaviour
------------------

When an implicit subscription is converted to an explicit subscription, the replayed service event does not reliably reflect the correct state/version of the remote service.
There are two incorrect replay scenarios:
 
- the explicit replay may fail to return the current active UP version
- the explicit replay may fail to return the last-active NO_ACTIVE version during await-active
 
Expected behaviour
------------------
Converting an implicit subscription to an explicit subscription should replay the correct current service state:
 
- if the remote service is active, replay NCSMDS_UP with the current active version
- if the active instance has gone away and await-active is running, replay NCSMDS_NO_ACTIVE with the last active version

use testapi to reproduce


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3396 MDS: NEW_ACTIVE metadata is incorrect after MxN VDEST active-to-standby transition

[Thien M. H. <thi...@us...>]

- **summary**: MDS: NEW\_ACTIVE payload is incorrect after MxN VDEST active-to-standby transition --> MDS: NEW\_ACTIVE metadata is incorrect after MxN VDEST active-to-standby transition
- Description has changed:

Diff:

~~~~

--- old
+++ new
@@ -21,6 +21,6 @@
 1. a NO_ACTIVE event reflecting the demoted instance, then
 2. a NEW_ACTIVE event reflecting the replacement instance.
  
-The NEW_ACTIVE payload must report the replacement service attributes, specifically:
+The NEW_ACTIVE metadata  must report the replacement service attributes, specifically:
 - role = ACTIVE
 - private version = 2

~~~~




---

**[tickets:#3396] MDS: NEW\_ACTIVE metadata is incorrect after MxN VDEST active-to-standby transition**

**Status:** review
**Milestone:** 5.27.01
**Created:** Mon Apr 13, 2026 08:08 AM UTC by Thien Minh Huynh
**Last Updated:** Tue Apr 14, 2026 10:36 AM UTC
**Owner:** Thien Minh Huynh


Steps to reproduce
------------------
1. Start MDS in two separate processes.
2. In the first process, create MxN VDEST 1001 and install service 600 with private version 1.
3. Change VDEST 1001 to ACTIVE in the first process.
4. In the subscriber process, install service 500 and subscribe to service 600 with INTRACHASSIS scope.
5. Verify that subscriber 500 receives an initial UP event for service 600 with private version 1.
6. In the second process, create the same MxN VDEST 1001 and install a replacement instance of service 600 with private version 2.
7. Promote the second process VDEST 1001 to ACTIVE and demote the first process VDEST 1001 to STANDBY.
8. Retrieve subscription events on service 500 after the role transition.
 
Observed behaviour
------------------
After the ACTIVE to STANDBY handover on MxN VDEST 1001, the subscriber does receive the expected sequence of service-change notifications, including NO_ACTIVE followed by NEW_ACTIVE. However, the payload associated with the NEW_ACTIVE notification is
not preserved from the replacement active instance.
 
 
Expected behaviour
------------------
When the original ACTIVE instance of service 600 is demoted to STANDBY and the replacement instance becomes ACTIVE on the same MxN VDEST, the subscriber should receive:
1. a NO_ACTIVE event reflecting the demoted instance, then
2. a NEW_ACTIVE event reflecting the replacement instance.
 
The NEW_ACTIVE metadata  must report the replacement service attributes, specifically:
- role = ACTIVE
- private version = 2


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3397 MDS: Explicit subscription replay uses wrong state/version after implicit subscribe

[Thang D. N. <th...@us...>]

There is a similar use case that client receive wrong version on MDS_DOWN event.
1. Install server service ver 5 on a vdest then set role to active.
2. Client subscribe  server service.
3. Client receive MDS_UP event with ver 5.
4. Change role server service from active to standby then wait await-active timer expired.
5. Client receives MDS_DOWN event with ver always 0.


---

**[tickets:#3397] MDS: Explicit subscription replay uses wrong state/version after implicit subscribe**

**Status:** review
**Milestone:** 5.27.01
**Created:** Mon Apr 13, 2026 08:31 AM UTC by Thien Minh Huynh
**Last Updated:** Tue Apr 14, 2026 10:36 AM UTC
**Owner:** Thien Minh Huynh


Steps to reproduce
------------------
1. Start an MDS test setup with an ADEST subscriber and a VDEST providing NCSMDS_SVC_ID_INTERNAL_MIN.
2. Create an implicit subscription by sending a message from NCSMDS_SVC_ID_EXTERNAL_MIN to NCSMDS_SVC_ID_INTERNAL_MIN on the active VDEST.
3. Convert that existing implicit subscription into an explicit subscription using mds_service_subscribe().
4. Retrieve the replayed service event with mds_service_retrieve().
5. Verify the replayed event/version.
6. Variant A: leave the VDEST active and expect an NCSMDS_UP replay with the current active version.
7. Variant B: demote the active VDEST to standby first, let await-active run, then expect an NCSMDS_NO_ACTIVE replay with the last active version.
 
Observed behaviour
------------------

When an implicit subscription is converted to an explicit subscription, the replayed service event does not reliably reflect the correct state/version of the remote service.
There are two incorrect replay scenarios:
 
- the explicit replay may fail to return the current active UP version
- the explicit replay may fail to return the last-active NO_ACTIVE version during await-active
 
Expected behaviour
------------------
Converting an implicit subscription to an explicit subscription should replay the correct current service state:
 
- if the remote service is active, replay NCSMDS_UP with the current active version
- if the active instance has gone away and await-active is running, replay NCSMDS_NO_ACTIVE with the last active version

use testapi to reproduce


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3396 MDS: NEW_ACTIVE payload is incorrect after MxN VDEST active-to-standby transition

[Thien M. H. <thi...@us...>]

- **status**: accepted --> review



---

**[tickets:#3396] MDS: NEW\_ACTIVE payload is incorrect after MxN VDEST active-to-standby transition**

**Status:** review
**Milestone:** 5.27.01
**Created:** Mon Apr 13, 2026 08:08 AM UTC by Thien Minh Huynh
**Last Updated:** Mon Apr 13, 2026 08:08 AM UTC
**Owner:** Thien Minh Huynh


Steps to reproduce
------------------
1. Start MDS in two separate processes.
2. In the first process, create MxN VDEST 1001 and install service 600 with private version 1.
3. Change VDEST 1001 to ACTIVE in the first process.
4. In the subscriber process, install service 500 and subscribe to service 600 with INTRACHASSIS scope.
5. Verify that subscriber 500 receives an initial UP event for service 600 with private version 1.
6. In the second process, create the same MxN VDEST 1001 and install a replacement instance of service 600 with private version 2.
7. Promote the second process VDEST 1001 to ACTIVE and demote the first process VDEST 1001 to STANDBY.
8. Retrieve subscription events on service 500 after the role transition.
 
Observed behaviour
------------------
After the ACTIVE to STANDBY handover on MxN VDEST 1001, the subscriber does receive the expected sequence of service-change notifications, including NO_ACTIVE followed by NEW_ACTIVE. However, the payload associated with the NEW_ACTIVE notification is
not preserved from the replacement active instance.
 
 
Expected behaviour
------------------
When the original ACTIVE instance of service 600 is demoted to STANDBY and the replacement instance becomes ACTIVE on the same MxN VDEST, the subscriber should receive:
1. a NO_ACTIVE event reflecting the demoted instance, then
2. a NEW_ACTIVE event reflecting the replacement instance.
 
The NEW_ACTIVE payload must report the replacement service attributes, specifically:
- role = ACTIVE
- private version = 2


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3397 MDS: Explicit subscription replay uses wrong state/version after implicit subscribe

[Thien M. H. <thi...@us...>]

- Description has changed:

Diff:

~~~~

--- old
+++ new
@@ -1,4 +1,3 @@
-
 Steps to reproduce
 ------------------
 1. Start an MDS test setup with an ADEST subscriber and a VDEST providing NCSMDS_SVC_ID_INTERNAL_MIN.

~~~~

- **status**: accepted --> review



---

**[tickets:#3397] MDS: Explicit subscription replay uses wrong state/version after implicit subscribe**

**Status:** review
**Milestone:** 5.27.01
**Created:** Mon Apr 13, 2026 08:31 AM UTC by Thien Minh Huynh
**Last Updated:** Mon Apr 13, 2026 08:33 AM UTC
**Owner:** Thien Minh Huynh


Steps to reproduce
------------------
1. Start an MDS test setup with an ADEST subscriber and a VDEST providing NCSMDS_SVC_ID_INTERNAL_MIN.
2. Create an implicit subscription by sending a message from NCSMDS_SVC_ID_EXTERNAL_MIN to NCSMDS_SVC_ID_INTERNAL_MIN on the active VDEST.
3. Convert that existing implicit subscription into an explicit subscription using mds_service_subscribe().
4. Retrieve the replayed service event with mds_service_retrieve().
5. Verify the replayed event/version.
6. Variant A: leave the VDEST active and expect an NCSMDS_UP replay with the current active version.
7. Variant B: demote the active VDEST to standby first, let await-active run, then expect an NCSMDS_NO_ACTIVE replay with the last active version.
 
Observed behaviour
------------------

When an implicit subscription is converted to an explicit subscription, the replayed service event does not reliably reflect the correct state/version of the remote service.
There are two incorrect replay scenarios:
 
- the explicit replay may fail to return the current active UP version
- the explicit replay may fail to return the last-active NO_ACTIVE version during await-active
 
Expected behaviour
------------------
Converting an implicit subscription to an explicit subscription should replay the correct current service state:
 
- if the remote service is active, replay NCSMDS_UP with the current active version
- if the active instance has gone away and await-active is running, replay NCSMDS_NO_ACTIVE with the last active version

use testapi to reproduce


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3394 IMM: OM agent cannot recovery when create agent fail

[Thien M. H. <thi...@us...>]

- **summary**: OM agent cannot recovery when create agent fail --> IMM: OM agent cannot recovery when create agent fail



---

**[tickets:#3394] IMM: OM agent cannot recovery when create agent fail**

**Status:** accepted
**Milestone:** 5.27.01
**Created:** Tue Mar 03, 2026 03:39 AM UTC by Thien Minh Huynh
**Last Updated:** Tue Mar 03, 2026 03:39 AM UTC
**Owner:** Thien Minh Huynh


Since ticket #3265 removed the assert failure, the OM agent is no longer able to recover when agent creation fails. 

~~~

2026-02-18 06:22:30.315 SC-1 test_bind: MDTM: bind fail: <p:3368456377,s:1442907162,i:2685009919> errno: Invalid argument
2026-02-18 06:22:30.315 SC-1 test_bind: MDTM: install_tipc fail: svc_id = IMMA_OM(26), vdest=65535
2026-02-18 06:22:30.315 SC-1 test_bind: WA cb->sv_id is NOT ZERO (1a) on first time entry IMMA svid:1a
~~~

There is a duplicate bind issue on tipc. That leads to create OM agent fail.

In this situation, the OM agent should terminate the process instead of ignoring the error and repeatedly returning SA_ERR_LIBRARY. Exiting the process will allow the AMF framework to trigger its recovery mechanism when agent creation fails, which also improves overall system availability and resilience.


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3397 MDS: Explicit subscription replay uses wrong state/version after implicit subscribe

[Thien M. H. <thi...@us...>]

- Description has changed:

Diff:

~~~~

--- old
+++ new
@@ -1,6 +1,6 @@
-use testapi to reproduce
+
 Steps to reproduce
------------------- 
+------------------
 1. Start an MDS test setup with an ADEST subscriber and a VDEST providing NCSMDS_SVC_ID_INTERNAL_MIN.
 2. Create an implicit subscription by sending a message from NCSMDS_SVC_ID_EXTERNAL_MIN to NCSMDS_SVC_ID_INTERNAL_MIN on the active VDEST.
 3. Convert that existing implicit subscription into an explicit subscription using mds_service_subscribe().
@@ -10,7 +10,8 @@
 7. Variant B: demote the active VDEST to standby first, let await-active run, then expect an NCSMDS_NO_ACTIVE replay with the last active version.
  
 Observed behaviour
- ------------------
+------------------
+
 When an implicit subscription is converted to an explicit subscription, the replayed service event does not reliably reflect the correct state/version of the remote service.
 There are two incorrect replay scenarios:
  
@@ -18,8 +19,10 @@
 - the explicit replay may fail to return the last-active NO_ACTIVE version during await-active
  
 Expected behaviour
- ------------------
+------------------
 Converting an implicit subscription to an explicit subscription should replay the correct current service state:
  
 - if the remote service is active, replay NCSMDS_UP with the current active version
 - if the active instance has gone away and await-active is running, replay NCSMDS_NO_ACTIVE with the last active version
+
+use testapi to reproduce

~~~~




---

**[tickets:#3397] MDS: Explicit subscription replay uses wrong state/version after implicit subscribe**

**Status:** accepted
**Milestone:** 5.27.01
**Created:** Mon Apr 13, 2026 08:31 AM UTC by Thien Minh Huynh
**Last Updated:** Mon Apr 13, 2026 08:31 AM UTC
**Owner:** Thien Minh Huynh



Steps to reproduce
------------------
1. Start an MDS test setup with an ADEST subscriber and a VDEST providing NCSMDS_SVC_ID_INTERNAL_MIN.
2. Create an implicit subscription by sending a message from NCSMDS_SVC_ID_EXTERNAL_MIN to NCSMDS_SVC_ID_INTERNAL_MIN on the active VDEST.
3. Convert that existing implicit subscription into an explicit subscription using mds_service_subscribe().
4. Retrieve the replayed service event with mds_service_retrieve().
5. Verify the replayed event/version.
6. Variant A: leave the VDEST active and expect an NCSMDS_UP replay with the current active version.
7. Variant B: demote the active VDEST to standby first, let await-active run, then expect an NCSMDS_NO_ACTIVE replay with the last active version.
 
Observed behaviour
------------------

When an implicit subscription is converted to an explicit subscription, the replayed service event does not reliably reflect the correct state/version of the remote service.
There are two incorrect replay scenarios:
 
- the explicit replay may fail to return the current active UP version
- the explicit replay may fail to return the last-active NO_ACTIVE version during await-active
 
Expected behaviour
------------------
Converting an implicit subscription to an explicit subscription should replay the correct current service state:
 
- if the remote service is active, replay NCSMDS_UP with the current active version
- if the active instance has gone away and await-active is running, replay NCSMDS_NO_ACTIVE with the last active version

use testapi to reproduce


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3397 MDS: Explicit subscription replay uses wrong state/version after implicit subscribe

[Thien M. H. <thi...@us...>]

---

**[tickets:#3397] MDS: Explicit subscription replay uses wrong state/version after implicit subscribe**

**Status:** accepted
**Milestone:** 5.27.01
**Created:** Mon Apr 13, 2026 08:31 AM UTC by Thien Minh Huynh
**Last Updated:** Mon Apr 13, 2026 08:31 AM UTC
**Owner:** Thien Minh Huynh


use testapi to reproduce
Steps to reproduce
------------------ 
1. Start an MDS test setup with an ADEST subscriber and a VDEST providing NCSMDS_SVC_ID_INTERNAL_MIN.
2. Create an implicit subscription by sending a message from NCSMDS_SVC_ID_EXTERNAL_MIN to NCSMDS_SVC_ID_INTERNAL_MIN on the active VDEST.
3. Convert that existing implicit subscription into an explicit subscription using mds_service_subscribe().
4. Retrieve the replayed service event with mds_service_retrieve().
5. Verify the replayed event/version.
6. Variant A: leave the VDEST active and expect an NCSMDS_UP replay with the current active version.
7. Variant B: demote the active VDEST to standby first, let await-active run, then expect an NCSMDS_NO_ACTIVE replay with the last active version.
 
Observed behaviour
 ------------------
When an implicit subscription is converted to an explicit subscription, the replayed service event does not reliably reflect the correct state/version of the remote service.
There are two incorrect replay scenarios:
 
- the explicit replay may fail to return the current active UP version
- the explicit replay may fail to return the last-active NO_ACTIVE version during await-active
 
Expected behaviour
 ------------------
Converting an implicit subscription to an explicit subscription should replay the correct current service state:
 
- if the remote service is active, replay NCSMDS_UP with the current active version
- if the active instance has gone away and await-active is running, replay NCSMDS_NO_ACTIVE with the last active version


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3396 MDS: NEW_ACTIVE payload is incorrect after MxN VDEST active-to-standby transition

[Thien M. H. <thi...@us...>]

---

**[tickets:#3396] MDS: NEW\_ACTIVE payload is incorrect after MxN VDEST active-to-standby transition**

**Status:** accepted
**Milestone:** 5.27.01
**Created:** Mon Apr 13, 2026 08:08 AM UTC by Thien Minh Huynh
**Last Updated:** Mon Apr 13, 2026 08:08 AM UTC
**Owner:** Thien Minh Huynh


Steps to reproduce
------------------
1. Start MDS in two separate processes.
2. In the first process, create MxN VDEST 1001 and install service 600 with private version 1.
3. Change VDEST 1001 to ACTIVE in the first process.
4. In the subscriber process, install service 500 and subscribe to service 600 with INTRACHASSIS scope.
5. Verify that subscriber 500 receives an initial UP event for service 600 with private version 1.
6. In the second process, create the same MxN VDEST 1001 and install a replacement instance of service 600 with private version 2.
7. Promote the second process VDEST 1001 to ACTIVE and demote the first process VDEST 1001 to STANDBY.
8. Retrieve subscription events on service 500 after the role transition.
 
Observed behaviour
------------------
After the ACTIVE to STANDBY handover on MxN VDEST 1001, the subscriber does receive the expected sequence of service-change notifications, including NO_ACTIVE followed by NEW_ACTIVE. However, the payload associated with the NEW_ACTIVE notification is
not preserved from the replacement active instance.
 
 
Expected behaviour
------------------
When the original ACTIVE instance of service 600 is demoted to STANDBY and the replacement instance becomes ACTIVE on the same MxN VDEST, the subscriber should receive:
1. a NO_ACTIVE event reflecting the demoted instance, then
2. a NEW_ACTIVE event reflecting the replacement instance.
 
The NEW_ACTIVE payload must report the replacement service attributes, specifically:
- role = ACTIVE
- private version = 2


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3395 amf: Component failed instanttiation while immnd down

[Nguyen H. T. <tai...@us...>]

- **status**: assigned --> fixed



---

**[tickets:#3395] amf: Component failed instanttiation while immnd down**

**Status:** fixed
**Milestone:** 5.27.01
**Created:** Tue Mar 31, 2026 04:26 AM UTC by Nguyen Huynh Tai
**Last Updated:** Fri Apr 10, 2026 03:35 AM UTC
**Owner:** Nguyen Huynh Tai


During component instantiation, if immnd is down, the component cannot retrieve configuration from the IMM object, which leads to the state INSTANTIATION_FAILED.
Syslog of issue:
~~~
src/amf/amfnd/susm.cc:2144 TR Running the component CLC FSM 
src/amf/amfnd/clc.cc:777 >> avnd_comp_clc_fsm_run: Comp 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test', Ev '1'
src/amf/amfnd/clc.cc:883 T1 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test':Entering CLC FSM: presence state:'SA_AMF_PRESENCE_UNINSTANTIATED(1)', Event:'AVND_COMP_CLC_PRES_FSM_EV_INST'
src/amf/amfnd/clc.cc:1581 >> avnd_comp_clc_uninst_inst_hdler: 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test' : Instantiate event in the Uninstantiated state
src/amf/amfnd/compdb.cc:1724 >> avnd_comp_config_reinit: 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test'
src/amf/amfnd/compdb.cc:1737 T1 safComp=A,safSu=1,safSg=2N,safApp=opensaf-test
src/amf/amfnd/compdb.cc:850 >> avnd_comptype_create: 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/compdb.cc:860 ER amf_saImmOmAccessorGet_o2 FAILED for 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/compdb.cc:1323 ER comp_init: avnd_comptype_create FAILED for 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/hcdb.cc:199 >> avnd_hctype_config_get: 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/clc.cc:890 NO Component CLC fsm exited with error for comp:safComp=A,safSu=1,safSg=2N,safApp=opensaf-test
src/amf/amfnd/su.cc:742 NO 'safSu=1,safSg=2N,safApp=opensaf-test' Presence State UNINSTANTIATED => INSTANTIATION_FAILED
~~~


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3395 amf: Component failed instanttiation while immnd down

[Nguyen H. T. <tai...@us...>]

~~~
commit 8a0101f670badb5743af0ca9d49329ac8bbeb256 (HEAD -> develop, origin/develop)
Author: tai.h.nguyen <tai...@en...>
Date:   Tue Apr 7 07:51:57 2026 +0000

    amfnd: Reuse cached config when immnd is unavailable [#3395]

    A component can fail to instantiate while immnd is unavailable.

    The refresh path did not preserve the original IMM error and could
    not distinguish between cases where reusing the old config is allowed
    and upgrade handling where the legacy component failure must be kept.

    Preserve the IMM error through the refresh helpers so the handler can
    reuse the last known config only when immnd is down, while keeping the
    legacy failure behavior during upgrade.
~~~


---

**[tickets:#3395] amf: Component failed instanttiation while immnd down**

**Status:** assigned
**Milestone:** 5.27.01
**Created:** Tue Mar 31, 2026 04:26 AM UTC by Nguyen Huynh Tai
**Last Updated:** Tue Mar 31, 2026 04:26 AM UTC
**Owner:** Nguyen Huynh Tai


During component instantiation, if immnd is down, the component cannot retrieve configuration from the IMM object, which leads to the state INSTANTIATION_FAILED.
Syslog of issue:
~~~
src/amf/amfnd/susm.cc:2144 TR Running the component CLC FSM 
src/amf/amfnd/clc.cc:777 >> avnd_comp_clc_fsm_run: Comp 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test', Ev '1'
src/amf/amfnd/clc.cc:883 T1 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test':Entering CLC FSM: presence state:'SA_AMF_PRESENCE_UNINSTANTIATED(1)', Event:'AVND_COMP_CLC_PRES_FSM_EV_INST'
src/amf/amfnd/clc.cc:1581 >> avnd_comp_clc_uninst_inst_hdler: 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test' : Instantiate event in the Uninstantiated state
src/amf/amfnd/compdb.cc:1724 >> avnd_comp_config_reinit: 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test'
src/amf/amfnd/compdb.cc:1737 T1 safComp=A,safSu=1,safSg=2N,safApp=opensaf-test
src/amf/amfnd/compdb.cc:850 >> avnd_comptype_create: 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/compdb.cc:860 ER amf_saImmOmAccessorGet_o2 FAILED for 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/compdb.cc:1323 ER comp_init: avnd_comptype_create FAILED for 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/hcdb.cc:199 >> avnd_hctype_config_get: 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/clc.cc:890 NO Component CLC fsm exited with error for comp:safComp=A,safSu=1,safSg=2N,safApp=opensaf-test
src/amf/amfnd/su.cc:742 NO 'safSu=1,safSg=2N,safApp=opensaf-test' Presence State UNINSTANTIATED => INSTANTIATION_FAILED
~~~


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3341 log: memleak detected by valgrind

[Thien M. H. <thi...@us...>]

- **status**: review --> not-reproducible
- **Comment**:

This is rare case. I cannot reproduce this issue.



---

**[tickets:#3341] log: memleak detected by valgrind**

**Status:** not-reproducible
**Milestone:** 5.27.01
**Created:** Thu Aug 17, 2023 04:41 AM UTC by Thien Minh Huynh
**Last Updated:** Fri Feb 27, 2026 11:05 PM UTC
**Owner:** Thien Minh Huynh


==526== 8,072 (56 direct, 8,016 indirect) bytes in 1 blocks are definitely lost in loss record 172 of 175
==526== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==526== by 0x5B3BC2B: sysf_alloc_pkt (sysf_mem.c:429)
==526== by 0x5B2A9CD: ncs_enc_init_space (hj_ubaid.c:108)
==526== by 0x5B4A03D: ncs_mbcsv_encode_message (mbcsv_util.c:899)
==526== by 0x5B4A56C: mbcsv_send_msg (mbcsv_util.c:1029)
==526== by 0x5B47112: mbcsv_process_events (mbcsv_pr_evts.c:139)
==526== by 0x5B473BA: mbcsv_hdl_dispatch_all (mbcsv_pr_evts.c:271)
==526== by 0x5B41A19: mbcsv_process_dispatch_request (mbcsv_api.c:426)
==526== by 0x13C6AD: lgs_mbcsv_dispatch(unsigned int) (lgs_mbcsv.cc:509)
==526== by 0x119919: main (lgs_main.cc:592)


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3395 amf: Component failed instanttiation while immnd down

[Nguyen H. T. <tai...@us...>]

---

**[tickets:#3395] amf: Component failed instanttiation while immnd down**

**Status:** assigned
**Milestone:** 5.27.01
**Created:** Tue Mar 31, 2026 04:26 AM UTC by Nguyen Huynh Tai
**Last Updated:** Tue Mar 31, 2026 04:26 AM UTC
**Owner:** Nguyen Huynh Tai


During component instantiation, if immnd is down, the component cannot retrieve configuration from the IMM object, which leads to the state INSTANTIATION_FAILED.
Syslog of issue:
~~~
src/amf/amfnd/susm.cc:2144 TR Running the component CLC FSM 
src/amf/amfnd/clc.cc:777 >> avnd_comp_clc_fsm_run: Comp 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test', Ev '1'
src/amf/amfnd/clc.cc:883 T1 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test':Entering CLC FSM: presence state:'SA_AMF_PRESENCE_UNINSTANTIATED(1)', Event:'AVND_COMP_CLC_PRES_FSM_EV_INST'
src/amf/amfnd/clc.cc:1581 >> avnd_comp_clc_uninst_inst_hdler: 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test' : Instantiate event in the Uninstantiated state
src/amf/amfnd/compdb.cc:1724 >> avnd_comp_config_reinit: 'safComp=A,safSu=1,safSg=2N,safApp=opensaf-test'
src/amf/amfnd/compdb.cc:1737 T1 safComp=A,safSu=1,safSg=2N,safApp=opensaf-test
src/amf/amfnd/compdb.cc:850 >> avnd_comptype_create: 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/compdb.cc:860 ER amf_saImmOmAccessorGet_o2 FAILED for 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/compdb.cc:1323 ER comp_init: avnd_comptype_create FAILED for 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/hcdb.cc:199 >> avnd_hctype_config_get: 'safVersion=R1A,safCompType=opensaf-test'
src/amf/amfnd/clc.cc:890 NO Component CLC fsm exited with error for comp:safComp=A,safSu=1,safSg=2N,safApp=opensaf-test
src/amf/amfnd/su.cc:742 NO 'safSu=1,safSg=2N,safApp=opensaf-test' Presence State UNINSTANTIATED => INSTANTIATION_FAILED
~~~


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3390 imm: cannot set implementer after merge network

[Thien M. H. <thi...@us...>]

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

commit 05148767b54a95bfc5171c8a1b0ab42e9c70c8fb (HEAD -> develop, origin/develop, ticket-3390)
Author: Thien Minh Huynh <thi...@en...>
Date:   Wed Jan 7 08:41:10 2026 +0000
 
    immnd: fix cannot set implementer returning SA_AIS_ERR_EXIST [#3390]
    Setting an implementer during cluster merge or split‑brain recovery
    could fail with SA_AIS_ERR_EXIST even though the coord accepted the new
    implementer and the operation should be retried.
    When this happens, visible symptoms include the imm agent timing out or
    receiving a response that later leads to SA_AIS_ERR_EXIST on retries.
    After a network merge, IMMND re-introduces and enters a sync phase with
    the coordinator (mIntroduced == 2). While syncing, IMMND may drop the
    set-implementer response but the coordinator can still accept and set the
    implementer. This creates a mismatch: the imm agent either times out or
    gets a stale/absent response, and when it retries the operation the IMMND
    now reports SA_AIS_ERR_EXIST because the implementer is already set on
    the coordinator.
    Add an early check in case IMMND need to be synced with coord.
    This prevents further processing while IMMND is syncing and makes
    the retryable condition explicit so the agent can try again later.



---

**[tickets:#3390] imm: cannot set implementer after merge network**

**Status:** fixed
**Milestone:** 5.27.01
**Created:** Mon Nov 17, 2025 07:17 AM UTC by Thien Minh Huynh
**Last Updated:** Fri Feb 27, 2026 11:03 PM UTC
**Owner:** Thien Minh Huynh


The issue observes when testing roaming SC with split brain recovery.

~~~
Oct 08 19:07:20 SC-1 immagent[4920]: m_immHandle != 0 - re-init. rc: SA_AIS_OK
Oct 08 19:07:27 SC-1 immagent[4920]: initialize: saImmOiInitialize_2 - SA_AIS_OK
Oct 08 19:07:27 SC-1 immagent[4920]: initialize: saImmOiImplementerSet - SA_AIS_ERR_TRY_AGAIN
Oct 08 19:07:31 SC-1 immagent[4920]: initialize: saImmOiImplementerSet - SA_AIS_ERR_TRY_AGAIN
Oct 08 19:07:39 SC-1 immagent[4920]: initialize: saImmOiImplementerSet - SA_AIS_ERR_TRY_AGAIN
Oct 08 19:07:51 SC-1 immagent[4920]: initialize: saImmOiImplementerSet - SA_AIS_ERR_TRY_AGAIN
Oct 08 19:08:07 SC-1 immagent[4920]: initialize: saImmOiImplementerSet - SA_AIS_ERR_TRY_AGAIN
Oct 08 19:08:37 SC-1 immagent[4920]: initialize: saImmOiImplementerSet - SA_AIS_ERR_TIMEOUT
Oct 08 19:09:01 SC-1 immagent[4920]: initialize: saImmOiImplementerSet - SA_AIS_ERR_BAD_HANDLE
Oct 08 19:09:01 SC-1 immagent[4920]: initialize: init failed, finalize - SA_AIS_OK
Oct 08 19:09:01 SC-1 immagent[4920]: initialize: saImmOiImplementerSet - killing application - SA_AIS_ERR_BAD_HANDLE
Oct 08 19:09:11 SC-1 immagent[25217]: initialize: saImmOiInitialize_2 - SA_AIS_OK
Oct 08 19:09:11 SC-1 immagent[25217]: initialize: saImmOiImplementerSet - SA_AIS_ERR_EXIST
~~~

cannot set implementer even immagent process already restart. It's always return SA_AIS_ERR_EXIST



---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3387 imm: old Simple API for XML interface is deprecated

[Khuong Ba L. <khu...@us...>]

commit 6b74478d0dfd4833cc6ab45b8e7360fa138546e0 (HEAD -> develop, origin/develop)
Author: khuonglb <khu...@en...>
Date:   Mon Mar 16 16:27:12 2026 +0700

    imm: old Simple API for XML interface is deprecated [#3387]
    
    xmlSAXUserParseFile() is deprecated. Replace it with a wrapper based on
    xmlCreateIOParserCtxt() to ensure safer and more controlled parsing.


---

**[tickets:#3387] imm: old Simple API for XML interface is deprecated**

**Status:** fixed
**Milestone:** 5.27.01
**Created:** Tue Nov 11, 2025 03:11 AM UTC by Thang Duc Nguyen
**Last Updated:** Thu Mar 19, 2026 09:29 AM UTC
**Owner:** Khuong Ba Le
**Attachments:**

- [imm_libxml_deprecated_declaration.patch](https://sourceforge.net/p/opensaf/tickets/3387/attachment/imm_libxml_deprecated_declaration.patch) (2.0 kB; application/octet-stream)


Error log for API xmlSAXUserParseFile()
~~~
src/imm/immloadd/imm_loader.cc: In function 'int loadImmXML(std::__cxx11::string, std::__cxx11::string, SaUint32T*)':

src/imm/immloadd/imm_loader.cc:2046:68: error: 'int xmlSAXUserParseFile(xmlSAXHandlerPtr, void*, const char*)' is deprecated [-Werror=deprecated-declarations]

   error = xmlSAXUserParseFile(&my_handler, &state, filename.c_str());
                                                                    ^

In file included from src/imm/immloadd/imm_loader.cc:26:0:

/usr/include/libxml2/libxml/parser.h:1005:3: note: declared here

   xmlSAXUserParseFile (xmlSAXHandlerPtr sax,

   ^~~~~~~~~~~~~~~~~~~
~~~
 It’s deprecated because:
 - It uses global parser state (not thread-safe).
 - It’s less flexible than the newer xmlReader and xmlParserCtxt APIs.
 - It doesn’t handle modern XML features (entities, encodings) as cleanly.

Patch reference attached.


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3387 imm: old Simple API for XML interface is deprecated

[Khuong Ba L. <khu...@us...>]

- **status**: assigned --> fixed



---

**[tickets:#3387] imm: old Simple API for XML interface is deprecated**

**Status:** fixed
**Milestone:** 5.27.01
**Created:** Tue Nov 11, 2025 03:11 AM UTC by Thang Duc Nguyen
**Last Updated:** Fri Feb 27, 2026 11:02 PM UTC
**Owner:** Khuong Ba Le
**Attachments:**

- [imm_libxml_deprecated_declaration.patch](https://sourceforge.net/p/opensaf/tickets/3387/attachment/imm_libxml_deprecated_declaration.patch) (2.0 kB; application/octet-stream)


Error log for API xmlSAXUserParseFile()
~~~
src/imm/immloadd/imm_loader.cc: In function 'int loadImmXML(std::__cxx11::string, std::__cxx11::string, SaUint32T*)':

src/imm/immloadd/imm_loader.cc:2046:68: error: 'int xmlSAXUserParseFile(xmlSAXHandlerPtr, void*, const char*)' is deprecated [-Werror=deprecated-declarations]

   error = xmlSAXUserParseFile(&my_handler, &state, filename.c_str());
                                                                    ^

In file included from src/imm/immloadd/imm_loader.cc:26:0:

/usr/include/libxml2/libxml/parser.h:1005:3: note: declared here

   xmlSAXUserParseFile (xmlSAXHandlerPtr sax,

   ^~~~~~~~~~~~~~~~~~~
~~~
 It’s deprecated because:
 - It uses global parser state (not thread-safe).
 - It’s less flexible than the newer xmlReader and xmlParserCtxt APIs.
 - It doesn’t handle modern XML features (entities, encodings) as cleanly.

Patch reference attached.


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3393 build: support config runstatedir when build opensaf package

[Thien M. H. <thi...@us...>]

Current, We cannot config with autoconf 2.7 or later. Because OpenSAF does not support and adapt to use runstatedir


---

**[tickets:#3393] build: support config runstatedir when build opensaf package**

**Status:** accepted
**Milestone:** 5.27.01
**Created:** Thu Dec 18, 2025 06:14 AM UTC by Thien Minh Huynh
**Last Updated:** Thu Mar 19, 2026 03:53 AM UTC
**Owner:** Nguyen Huynh Tai


/var/run is deprecated in most modern Linux distributions
The use of the /var/run directory is deprecated in favor of the /run directory on modern Linux systems, as formalized in version 3.0 of the Filesystem Hierarchy Standard (FHS).

Current opensaf harcode directly base on  localstatedir variable $(localstatedir)/run.
It's better to support config runstatedir, default value is $(localstatedir)/run.

Since Autoconf 2.70 already support runstatedir. But opensaf does not support at the moment.

https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
‘runstatedir’
The directory for installing data files which the programs modify while they run, that pertain to one specific machine, and which need not persist longer than the execution of the program—which is generally long-lived, for example, until the next reboot. PID files for system daemons are a typical use. In addition, this directory should not be cleaned except perhaps at reboot, while the general /tmp (TMPDIR) may be cleaned arbitrarily. This should normally be /var/run, but write it as $(localstatedir)/run. Having it as a separate variable allows the use of /run if desired, for example. (If you are using Autoconf 2.70 or later, write it as ‘@runstatedir@’.)



---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3393 build: support config runstatedir when build opensaf package

[Thang D. N. <th...@us...>]

I think we can leave it once  user can use the autoconf 2.7 or later to config it. 


---

**[tickets:#3393] build: support config runstatedir when build opensaf package**

**Status:** accepted
**Milestone:** 5.27.01
**Created:** Thu Dec 18, 2025 06:14 AM UTC by Thien Minh Huynh
**Last Updated:** Fri Feb 27, 2026 11:03 PM UTC
**Owner:** Nguyen Huynh Tai


/var/run is deprecated in most modern Linux distributions
The use of the /var/run directory is deprecated in favor of the /run directory on modern Linux systems, as formalized in version 3.0 of the Filesystem Hierarchy Standard (FHS).

Current opensaf harcode directly base on  localstatedir variable $(localstatedir)/run.
It's better to support config runstatedir, default value is $(localstatedir)/run.

Since Autoconf 2.70 already support runstatedir. But opensaf does not support at the moment.

https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
‘runstatedir’
The directory for installing data files which the programs modify while they run, that pertain to one specific machine, and which need not persist longer than the execution of the program—which is generally long-lived, for example, until the next reboot. PID files for system daemons are a typical use. In addition, this directory should not be cleaned except perhaps at reboot, while the general /tmp (TMPDIR) may be cleaned arbitrarily. This should normally be /var/run, but write it as $(localstatedir)/run. Having it as a separate variable allows the use of /run if desired, for example. (If you are using Autoconf 2.70 or later, write it as ‘@runstatedir@’.)



---

Sent from sourceforge.net because ope...@li... 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.

Re: [tickets] [users] Build error with glibc 2.43

[Nagendra K. <nag...@ge...>]

Hi Liu,
I think, you should create a ticket and float the fix for review.

Best regards,
Nagendra Kumar,
High Availability Solutions
https://GetHighAvailability.com/


-----Original Message-----
From: Yiding Liu (Fujitsu) via Opensaf-users
<ope...@li...> 
Sent: 18 March 2026 14:09
To: ope...@li...
Cc: ope...@li...
Subject: [users] Build error with glibc 2.43

Hi All
   I have tried to build opensaf_5.26.02 with glibc 2.43, but it shows
following error:

   opensaf/src/osaf/immutil/immutil.c:339:12: error: assignment discards
'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
|   339 |         cp = strstr(buffer, key);

   And I tried to  fix it with this patch
---
 src/amf/common/util.c      | 8 ++++----
 src/ckpt/ckptd/cpd_imm.c   | 4 ++--
 src/osaf/immutil/immutil.c | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/amf/common/util.c b/src/amf/common/util.c index
d17b766..56c1a50 100644
--- a/src/amf/common/util.c
+++ b/src/amf/common/util.c
@@ -252,8 +252,8 @@ void avsv_sanamet_init_from_association_dn(const SaNameT
*haystack, SaNameT *dn,
                                           const char *needle,
                                           const char *parent)  {
-       char *p;
-       char *pp;
+       const char *p;
+       const char *pp;
        int i = 0;

        osaf_extended_name_clear(dn);
@@ -270,8 +270,8 @@ void avsv_sanamet_init_from_association_dn(const SaNameT
*haystack, SaNameT *dn,

        /* copy the value upto parent but skip escape chars */
        int size = 0;
-       char *p1 = p;
-       char *pp1 = pp;
+       const char *p1 = p;
+       const char *pp1 = pp;
        while (p != pp) {
                if (*p != '\\')
                        size++;
diff --git a/src/ckpt/ckptd/cpd_imm.c b/src/ckpt/ckptd/cpd_imm.c index
e2dee0c..7c25d02 100644
--- a/src/ckpt/ckptd/cpd_imm.c
+++ b/src/ckpt/ckptd/cpd_imm.c
@@ -117,7 +117,7 @@ cpd_saImmOiRtAttrUpdateCallback(SaImmOiHandleT
immOiHandle,
        /* Extract ckpt_name and node_name */
        if (strncmp(object_name, "safReplica=", 11) == 0) {
                /* Extract ckpt_name */
-               char *p_char = strchr(object_name, ',');
+               const char *p_char = strchr(object_name, ',');
                if (p_char) {
                        p_char++; /* escaping first ',' of the associated
class
                                     DN name */ @@ -657,7 +657,7 @@
SaAisErrorT create_runtime_ckpt_object(CPD_CKPT_INFO_NODE *ckpt_node,
        SaNameT parentName;
        SaAisErrorT rc = SA_AIS_OK;
        char *dndup = strdup(ckpt_node->ckpt_name);
-       char *parent_name = strchr(ckpt_node->ckpt_name, ',');
+       const char *parent_name = strchr(ckpt_node->ckpt_name, ',');
        char *rdnstr;
        const SaImmAttrValuesT_2 *attrValues[7];
        SaImmAttrValueT dn[1], create_time[1], creat_flags[1],
max_sections[1], diff --git a/src/osaf/immutil/immutil.c
b/src/osaf/immutil/immutil.c index 1ca1fbb..d3a5b63 100644
--- a/src/osaf/immutil/immutil.c
+++ b/src/osaf/immutil/immutil.c
@@ -336,7 +336,7 @@ char const *immutil_getStringValue(char const *key,
SaNameT const *name)
        klen = strlen(key);
        assert(klen > 1 || key[klen - 1] == '=');

-       cp = strstr(buffer, key);
+       cp = (char*)strstr(buffer, key);
        while (cp != NULL) {
                if (cp == buffer || cp[-1] == ',') {
                        char *value = cp + klen;
--
2.43.0

  Does anyone meet the same issue and have tried to fix it?

Liu


_______________________________________________
Opensaf-users mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensaf-users

[tickets] Build error with glibc 2.43

[Yiding L. (Fujitsu) <liu...@fu...>]

Hi All
   I have tried to build opensaf_5.26.02 with glibc 2.43, but it shows following error:

   opensaf/src/osaf/immutil/immutil.c:339:12: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
|   339 |         cp = strstr(buffer, key);

   And I tried to  fix it with this patch
---
 src/amf/common/util.c      | 8 ++++----
 src/ckpt/ckptd/cpd_imm.c   | 4 ++--
 src/osaf/immutil/immutil.c | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/amf/common/util.c b/src/amf/common/util.c
index d17b766..56c1a50 100644
--- a/src/amf/common/util.c
+++ b/src/amf/common/util.c
@@ -252,8 +252,8 @@ void avsv_sanamet_init_from_association_dn(const SaNameT *haystack, SaNameT *dn,
                                           const char *needle,
                                           const char *parent)
 {
-       char *p;
-       char *pp;
+       const char *p;
+       const char *pp;
        int i = 0;

        osaf_extended_name_clear(dn);
@@ -270,8 +270,8 @@ void avsv_sanamet_init_from_association_dn(const SaNameT *haystack, SaNameT *dn,

        /* copy the value upto parent but skip escape chars */
        int size = 0;
-       char *p1 = p;
-       char *pp1 = pp;
+       const char *p1 = p;
+       const char *pp1 = pp;
        while (p != pp) {
                if (*p != '\\')
                        size++;
diff --git a/src/ckpt/ckptd/cpd_imm.c b/src/ckpt/ckptd/cpd_imm.c
index e2dee0c..7c25d02 100644
--- a/src/ckpt/ckptd/cpd_imm.c
+++ b/src/ckpt/ckptd/cpd_imm.c
@@ -117,7 +117,7 @@ cpd_saImmOiRtAttrUpdateCallback(SaImmOiHandleT immOiHandle,
        /* Extract ckpt_name and node_name */
        if (strncmp(object_name, "safReplica=", 11) == 0) {
                /* Extract ckpt_name */
-               char *p_char = strchr(object_name, ',');
+               const char *p_char = strchr(object_name, ',');
                if (p_char) {
                        p_char++; /* escaping first ',' of the associated class
                                     DN name */
@@ -657,7 +657,7 @@ SaAisErrorT create_runtime_ckpt_object(CPD_CKPT_INFO_NODE *ckpt_node,
        SaNameT parentName;
        SaAisErrorT rc = SA_AIS_OK;
        char *dndup = strdup(ckpt_node->ckpt_name);
-       char *parent_name = strchr(ckpt_node->ckpt_name, ',');
+       const char *parent_name = strchr(ckpt_node->ckpt_name, ',');
        char *rdnstr;
        const SaImmAttrValuesT_2 *attrValues[7];
        SaImmAttrValueT dn[1], create_time[1], creat_flags[1], max_sections[1],
diff --git a/src/osaf/immutil/immutil.c b/src/osaf/immutil/immutil.c
index 1ca1fbb..d3a5b63 100644
--- a/src/osaf/immutil/immutil.c
+++ b/src/osaf/immutil/immutil.c
@@ -336,7 +336,7 @@ char const *immutil_getStringValue(char const *key, SaNameT const *name)
        klen = strlen(key);
        assert(klen > 1 || key[klen - 1] == '=');

-       cp = strstr(buffer, key);
+       cp = (char*)strstr(buffer, key);
        while (cp != NULL) {
                if (cp == buffer || cp[-1] == ',') {
                        char *value = cp + klen;
--
2.43.0

  Does anyone meet the same issue and have tried to fix it?

Liu

[tickets] [opensaf:tickets] #3394 OM agent cannot recovery when create agent fail

[Thien M. H. <thi...@us...>]

---

**[tickets:#3394] OM agent cannot recovery when create agent fail**

**Status:** accepted
**Milestone:** 5.27.01
**Created:** Tue Mar 03, 2026 03:39 AM UTC by Thien Minh Huynh
**Last Updated:** Tue Mar 03, 2026 03:39 AM UTC
**Owner:** Thien Minh Huynh


Since ticket #3265 removed the assert failure, the OM agent is no longer able to recover when agent creation fails. 

~~~

2026-02-18 06:22:30.315 SC-1 test_bind: MDTM: bind fail: <p:3368456377,s:1442907162,i:2685009919> errno: Invalid argument
2026-02-18 06:22:30.315 SC-1 test_bind: MDTM: install_tipc fail: svc_id = IMMA_OM(26), vdest=65535
2026-02-18 06:22:30.315 SC-1 test_bind: WA cb->sv_id is NOT ZERO (1a) on first time entry IMMA svid:1a
~~~

There is a duplicate bind issue on tipc. That leads to create OM agent fail.

In this situation, the OM agent should terminate the process instead of ignoring the error and repeatedly returning SA_ERR_LIBRARY. Exiting the process will allow the AMF framework to trigger its recovery mechanism when agent creation fails, which also improves overall system availability and resilience.


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3375 osaf: etcd3.plugin does not work well with etcd 3.4

[Gary L. <gar...@us...>]

- **Milestone**: 5.27.01 --> 5.26.02



---

**[tickets:#3375] osaf: etcd3.plugin does not work well with etcd 3.4**

**Status:** fixed
**Milestone:** 5.26.02
**Created:** Fri May 23, 2025 05:13 AM UTC by Thang Duc Nguyen
**Last Updated:** Fri Feb 27, 2026 11:14 PM UTC
**Owner:** Thang Duc Nguyen


On etcd 3.4, there are some changes compare with etcd 3.3
* Introduced automatic retries for failed RPCs.
* Can hang on a dead/unreachable etcd server, especially during txn, watch, or lock.
* Behaves differently than etcd 3.3, which usually failed fast on such cases.

The simple solution is to add the timeout Shell Command to etcdctl command.


---

Sent from sourceforge.net because ope...@li... 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.

[tickets] [opensaf:tickets] #3375 osaf: etcd3.plugin does not work well with etcd 3.4

[Gary L. <gar...@us...>]

- **Milestone**: 5.26.02 --> 5.27.01



---

**[tickets:#3375] osaf: etcd3.plugin does not work well with etcd 3.4**

**Status:** fixed
**Milestone:** 5.27.01
**Created:** Fri May 23, 2025 05:13 AM UTC by Thang Duc Nguyen
**Last Updated:** Fri Feb 27, 2026 10:59 PM UTC
**Owner:** Thang Duc Nguyen


On etcd 3.4, there are some changes compare with etcd 3.3
* Introduced automatic retries for failed RPCs.
* Can hang on a dead/unreachable etcd server, especially during txn, watch, or lock.
* Behaves differently than etcd 3.3, which usually failed fast on such cases.

The simple solution is to add the timeout Shell Command to etcdctl command.


---

Sent from sourceforge.net because ope...@li... 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.