[tickets] [opensaf:tickets] #3154 IMM: immlist --pretty-print=yes option does not work with -a
- **status**: assigned --> wontfix - **Comment**: Explicitly add a note in immlist that the --pretty-print is disabled when using with option '-a'. This note will be added in the ticket [#3115] --- ** [tickets:#3154] IMM: immlist --pretty-print=yes option does not work with -a ** **Status:** wontfix **Milestone:** 5.20.05 **Created:** Fri Feb 14, 2020 11:16 AM UTC by Chau Hoang Phuc **Last Updated:** Sat Feb 15, 2020 01:57 AM UTC **Owner:** Chau Hoang Phuc When using the recommended calling immlist -a to query for specific attributes of an IMM object, the --pretty-print option is ignored and always forced to no, which breaks the behavior of the command. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3155 imm: make delimiter of muliple attribute value from immlist configurable
--- ** [tickets:#3155] imm: make delimiter of muliple attribute value from immlist configurable** **Status:** unassigned **Milestone:** 5.20.05 **Created:** Mon Feb 17, 2020 07:40 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Feb 17, 2020 07:40 AM UTC **Owner:** nobody This ticket is to make the delimiter from immlist format for multiple attribute value by adding an option `-d string, --delimiter=string`. The delimiter value can be a character or a string; e.g: here is the legacy output ~~~ $ immlist dn=1 macAddressSA_STRING_T x1:x2:x3:x4 x1:x2:x3:x4 ~~~ ~~~ $ immlist -a macAddress dn=1 macAddress=x1:x2:x3:x4:x1:x2:x3:x4 ~~~ e.g: here is the output with the new option ~~~ $ immlist -d '|' dn=1 macAddress SA_STRING_T x1:x2:x3:x4|x1:x2:x3:x4 ~~~ ~~~ $ immlist -d 'abc' -a macAddress dn=1 macAddress=x1:x2:x3:x4abcx1:x2:x3:x4 ~~~ --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3144 dtm: time value of a trace record should be generated before acquiring mutex
--- ** [tickets:#3144] dtm: time value of a trace record should be generated before acquiring mutex** **Status:** unassigned **Milestone:** 5.20.01 **Created:** Thu Jan 16, 2020 04:55 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Jan 16, 2020 04:55 AM UTC **Owner:** nobody There is a mutex in trace agent in order to synchronize trace-writings from multiple threads and the time value of each trace record is generated after acquiring the mutex. If there is one taking the mutex, the time value of that trace record may not reflect the exact timestamp when the trace is actually triggered. To be more accurate, the time value should be generated before acquiring the mutex. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3131 log: make fixed facility ID configurable
- **assigned_to**: Huynh Minh Thien --- ** [tickets:#3131] log: make fixed facility ID configurable** **Status:** assigned **Milestone:** 5.20.01 **Created:** Tue Dec 17, 2019 07:08 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Jan 13, 2020 03:42 AM UTC **Owner:** Huynh Minh Thien Streaming log record is packaged in RFC5424 format and currently they all carry a fixed facility ID. This ticket intends to make that facility ID configurable. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3131 log: make fixed facility ID configurable
- **assigned_to**: Vu Minh Nguyen --> nobody --- ** [tickets:#3131] log: make fixed facility ID configurable** **Status:** assigned **Milestone:** 5.20.01 **Created:** Tue Dec 17, 2019 07:08 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Dec 17, 2019 07:08 AM UTC **Owner:** nobody Streaming log record is packaged in RFC5424 format and currently they all carry a fixed facility ID. This ticket intends to make that facility ID configurable. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3139 log: update PR documentation for configurable facility ID
--- ** [tickets:#3139] log: update PR documentation for configurable facility ID** **Status:** assigned **Milestone:** 5.20.01 **Created:** Fri Jan 10, 2020 03:32 AM UTC by Vu Minh Nguyen **Last Updated:** Fri Jan 10, 2020 03:32 AM UTC **Owner:** Huynh Minh Thien The OpenSAF LOG PR documention should be updated according to changes in [#3131]. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3124 log: update PR document for log resilient improvement
- **status**: review --> fixed - **Comment**: commit d73f9ca4d1ebe334589b31c748a36ff539735a41 (HEAD -> master, origin/master, origin/HEAD) Author: Vu Minh Nguyen Date: Fri Jan 10 10:26:06 2020 +0700 log: update PR document for log resilient improvement [#312 --- ** [tickets:#3124] log: update PR document for log resilient improvement** **Status:** fixed **Milestone:** 5.20.01 **Created:** Thu Nov 28, 2019 08:27 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Dec 26, 2019 09:12 AM UTC **Owner:** Vu Minh Nguyen This ticket is to update the LOG PR documentation according to changes introduced in [#3116]. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3138 log: memory leak that was introduced in 3116 ticket
- **status**: review --> fixed - **Comment**: commit 740100f2ebfb5458a8052dea29b5583b3dc8df5a (HEAD -> develop, origin/develop, ticket-3138) Author: Vu Minh Nguyen Date: Thu Jan 9 17:06:05 2020 +0700 log: fix memory leak that was introduced in 3116 [#3138] --- ** [tickets:#3138] log: memory leak that was introduced in 3116 ticket** **Status:** fixed **Milestone:** 5.20.01 **Created:** Thu Jan 09, 2020 09:42 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Jan 09, 2020 10:51 AM UTC **Owner:** Vu Minh Nguyen The write log async data that comes from log agent is not freed in `proc_write_log_async_msg` and in few abnormal cases that was introduced in [#3116]. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3138 log: memory leak that was introduced in 3116 ticket
- **status**: unassigned --> review --- ** [tickets:#3138] log: memory leak that was introduced in 3116 ticket** **Status:** review **Milestone:** 5.20.01 **Created:** Thu Jan 09, 2020 09:42 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Jan 09, 2020 10:02 AM UTC **Owner:** Vu Minh Nguyen The write log async data that comes from log agent is not freed in `proc_write_log_async_msg` and in few abnormal cases that was introduced in [#3116]. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3138 log: memory leak that was introduced in 3116 ticket
- **summary**: log: memory leak in abnormal cases --> log: memory leak that was introduced in 3116 ticket - Description has changed: Diff: --- old +++ new @@ -1 +1 @@ -Memories are not freed in few abnormal cases that was introduced in [#3116]. +The write log async data that comes from log agent is not freed in `proc_write_log_async_msg` and in few abnormal cases that was introduced in [#3116]. --- ** [tickets:#3138] log: memory leak that was introduced in 3116 ticket** **Status:** unassigned **Milestone:** 5.20.01 **Created:** Thu Jan 09, 2020 09:42 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Jan 09, 2020 09:42 AM UTC **Owner:** Vu Minh Nguyen The write log async data that comes from log agent is not freed in `proc_write_log_async_msg` and in few abnormal cases that was introduced in [#3116]. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3138 log: memory leak in abnormal cases
--- ** [tickets:#3138] log: memory leak in abnormal cases** **Status:** unassigned **Milestone:** 5.20.01 **Created:** Thu Jan 09, 2020 09:42 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Jan 09, 2020 09:42 AM UTC **Owner:** Vu Minh Nguyen Memories are not freed in few abnormal cases that was introduced in [#3116]. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3137 log: accessing unacked invocation list is not thread-safe
- **status**: review --> fixed - **Comment**: commit d3b3bd1fb4bb3afe5d8252641bc68029f91b69b3 (HEAD -> develop, origin/develop, ticket-3137) Author: Vu Minh Nguyen Date: Mon Jan 6 10:12:56 2020 +0700 log: fix segmentation fault in log agent [#3137] log agent did not protect the resource `unacked_invocations_ list` from accessing by multiple threads, so caused segmentation fault. This patch introduces a mutex in order to synchronize the access to that common resource. --- ** [tickets:#3137] log: accessing unacked invocation list is not thread-safe** **Status:** fixed **Milestone:** 5.20.01 **Created:** Fri Jan 03, 2020 09:49 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Jan 06, 2020 03:16 AM UTC **Owner:** Vu Minh Nguyen Coredump is generated; here is part of the backtrace. ~~~ Program terminated with signal SIGSEGV, Segmentation fault. #0 std::list >::remove (__value=@0x7fff770051f8: 1024193, this=0x15f2930) at /usr/include/c++/4.8/bits/list.tcc:248 [Current thread is 1 (Thread 0x7f94914d4780 (LWP 7167))] ### BT ### #0 std::list >::remove (__value=@0x7fff770051f8: 1024193, this=0x15f2930) at /usr/include/c++/4.8/bits/list.tcc:248 #1 LogClient::RemoveTrack (inv=1024193, this=0x15f2890) at ./src/log/agent/lga_client.h:181 #2 LogClient::InvokeCallback (this=this@entry=0x15f2890, msg=msg@entry=0x7f9480001cf0) at src/log/agent/lga_client.cc:135 ~~~ --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3137 log: accessing unacked invocation list is not thread-safe
- **status**: assigned --> review --- ** [tickets:#3137] log: accessing unacked invocation list is not thread-safe** **Status:** review **Milestone:** 5.20.01 **Created:** Fri Jan 03, 2020 09:49 AM UTC by Vu Minh Nguyen **Last Updated:** Fri Jan 03, 2020 09:49 AM UTC **Owner:** Vu Minh Nguyen Coredump is generated; here is part of the backtrace. ~~~ Program terminated with signal SIGSEGV, Segmentation fault. #0 std::list >::remove (__value=@0x7fff770051f8: 1024193, this=0x15f2930) at /usr/include/c++/4.8/bits/list.tcc:248 [Current thread is 1 (Thread 0x7f94914d4780 (LWP 7167))] ### BT ### #0 std::list >::remove (__value=@0x7fff770051f8: 1024193, this=0x15f2930) at /usr/include/c++/4.8/bits/list.tcc:248 #1 LogClient::RemoveTrack (inv=1024193, this=0x15f2890) at ./src/log/agent/lga_client.h:181 #2 LogClient::InvokeCallback (this=this@entry=0x15f2890, msg=msg@entry=0x7f9480001cf0) at src/log/agent/lga_client.cc:135 ~~~ --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3137 log: accessing unacked invocation list is not thread-safe
--- ** [tickets:#3137] log: accessing unacked invocation list is not thread-safe** **Status:** assigned **Milestone:** 5.20.01 **Created:** Fri Jan 03, 2020 09:49 AM UTC by Vu Minh Nguyen **Last Updated:** Fri Jan 03, 2020 09:49 AM UTC **Owner:** Vu Minh Nguyen Coredump is generated; here is part of the backtrace. ~~~ Program terminated with signal SIGSEGV, Segmentation fault. #0 std::list >::remove (__value=@0x7fff770051f8: 1024193, this=0x15f2930) at /usr/include/c++/4.8/bits/list.tcc:248 [Current thread is 1 (Thread 0x7f94914d4780 (LWP 7167))] ### BT ### #0 std::list >::remove (__value=@0x7fff770051f8: 1024193, this=0x15f2930) at /usr/include/c++/4.8/bits/list.tcc:248 #1 LogClient::RemoveTrack (inv=1024193, this=0x15f2890) at ./src/log/agent/lga_client.h:181 #2 LogClient::InvokeCallback (this=this@entry=0x15f2890, msg=msg@entry=0x7f9480001cf0) at src/log/agent/lga_client.cc:135 ~~~ --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3124 log: update PR document for log resilient improvement
- **status**: assigned --> review --- ** [tickets:#3124] log: update PR document for log resilient improvement** **Status:** review **Milestone:** 5.20.01 **Created:** Thu Nov 28, 2019 08:27 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Nov 28, 2019 08:27 AM UTC **Owner:** Vu Minh Nguyen This ticket is to update the LOG PR documentation according to changes introduced in [#3116]. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3133 dtm: add a new option '--all' to rotate all existing logtrace
- **Type**: defect --> enhancement --- ** [tickets:#3133] dtm: add a new option '--all' to rotate all existing logtrace** **Status:** unassigned **Milestone:** 5.20.01 **Created:** Thu Dec 19, 2019 09:54 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Dec 19, 2019 09:54 AM UTC **Owner:** nobody Adding a new option '--all' that means to rotate all existing logtrace if given along with the '--rotate' option. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3133 dtm: add a new option '--all' to rotate all existing logtrace
--- ** [tickets:#3133] dtm: add a new option '--all' to rotate all existing logtrace** **Status:** unassigned **Milestone:** 5.20.01 **Created:** Thu Dec 19, 2019 09:54 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Dec 19, 2019 09:54 AM UTC **Owner:** nobody Adding a new option '--all' that means to rotate all existing logtrace if given along with the '--rotate' option. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3131 log: make fixed facility ID configurable
--- ** [tickets:#3131] log: make fixed facility ID configurable** **Status:** assigned **Milestone:** 5.20.01 **Created:** Tue Dec 17, 2019 07:08 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Dec 17, 2019 07:08 AM UTC **Owner:** Vu Minh Nguyen Streaming log record is packaged in RFC5424 format and currently they all carry a fixed facility ID. This ticket intends to make that facility ID configurable. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3128 AMFD: stack memory is corrupted inside Configuration::get_config()
- Description has changed: Diff: --- old +++ new @@ -1,4 +1,4 @@ -The data types of these attributes `osafAmfDelayNodeFailoverTimeout` and `osafAmfDelayNodeFailoverNodeWaitTimeout` are `time_t`, but the method `Configuration::get_config()` uses an incorrect container, it is `uint32_t`, to hold the values of those attributes and it leads to the stack memory corrupted. Actually, it is the local variable `searchHandle` that is corrupted; since the second searchnext interation, the value of this handle is changed to a wrong number, so the searchhandle is leaked with below message in syslog: +The data types of these attributes `osafAmfDelayNodeFailoverTimeout` and `osafAmfDelayNodeFailoverNodeWaitTimeout` are `time_t`, but the method `Configuration::get_config()` uses an incorrect container, it is `uint32_t`, to hold the values of those attributes and it leads to the stack memory corrupted. Actually, it is the local variable `searchHandle` that is corrupted; since the second searchnext interation, the value of this handle is changed to an invalid number, so the searchhandle is leaked with below message in syslog: > Dec 5 18:25:24 SC-1 local0.notice osafimmnd[510]: NO Clear 1 search > result(s) for OM handle 140002010f. Search timeout 600sec --- ** [tickets:#3128] AMFD: stack memory is corrupted inside Configuration::get_config()** **Status:** assigned **Milestone:** 5.20.01 **Created:** Mon Dec 09, 2019 02:59 AM UTC by Chau Hoang Phuc **Last Updated:** Mon Dec 09, 2019 03:14 AM UTC **Owner:** Chau Hoang Phuc The data types of these attributes `osafAmfDelayNodeFailoverTimeout` and `osafAmfDelayNodeFailoverNodeWaitTimeout` are `time_t`, but the method `Configuration::get_config()` uses an incorrect container, it is `uint32_t`, to hold the values of those attributes and it leads to the stack memory corrupted. Actually, it is the local variable `searchHandle` that is corrupted; since the second searchnext interation, the value of this handle is changed to an invalid number, so the searchhandle is leaked with below message in syslog: > Dec 5 18:25:24 SC-1 local0.notice osafimmnd[510]: NO Clear 1 search > result(s) for OM handle 140002010f. Search timeout 600sec Steps to reproduce : 1. Start uml cluster 2. Wait for sometime and you will see that msg in syslog --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3128 AMFD: stack memory is corrupted inside Configuration::get_config()
- Description has changed: Diff: --- old +++ new @@ -1,6 +1,8 @@ -Dec 5 18:25:24 SC-1 local0.notice osafimmnd[510]: NO Clear 1 search result(s) for OM handle 140002010f. Search timeout 600sec +The data types of these attributes `osafAmfDelayNodeFailoverTimeout` and `osafAmfDelayNodeFailoverNodeWaitTimeout` are `time_t`, but the method `Configuration::get_config()` uses an incorrect container, it is `uint32_t`, to hold the values of those attributes and it leads to the stack memory corrupted. Actually, it is the local variable `searchHandle` that is corrupted; since the second searchnext interation, the value of this handle is changed to a wrong number, so the searchhandle is leaked with below message in syslog: -Step to reproduce : -1. Run uml cluster +> Dec 5 18:25:24 SC-1 local0.notice osafimmnd[510]: NO Clear 1 search result(s) for OM handle 140002010f. Search timeout 600sec + +Steps to reproduce : +1. Start uml cluster 2. Wait for sometime and you will see that msg in syslog --- ** [tickets:#3128] AMFD: stack memory is corrupted inside Configuration::get_config()** **Status:** assigned **Milestone:** 5.20.01 **Created:** Mon Dec 09, 2019 02:59 AM UTC by Chau Hoang Phuc **Last Updated:** Mon Dec 09, 2019 02:59 AM UTC **Owner:** Chau Hoang Phuc The data types of these attributes `osafAmfDelayNodeFailoverTimeout` and `osafAmfDelayNodeFailoverNodeWaitTimeout` are `time_t`, but the method `Configuration::get_config()` uses an incorrect container, it is `uint32_t`, to hold the values of those attributes and it leads to the stack memory corrupted. Actually, it is the local variable `searchHandle` that is corrupted; since the second searchnext interation, the value of this handle is changed to a wrong number, so the searchhandle is leaked with below message in syslog: > Dec 5 18:25:24 SC-1 local0.notice osafimmnd[510]: NO Clear 1 search > result(s) for OM handle 140002010f. Search timeout 600sec Steps to reproduce : 1. Start uml cluster 2. Wait for sometime and you will see that msg in syslog --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3116 log: improve the resilience of log service
- **status**: accepted --> review --- ** [tickets:#3116] log: improve the resilience of log service** **Status:** review **Milestone:** 5.20.01 **Created:** Tue Nov 05, 2019 07:22 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Nov 05, 2019 07:23 AM UTC **Owner:** Vu Minh Nguyen When the file system is unresponsive, log client gets try-again from write callback very shortly after I/O timeout reaches the setting; the value of I/O timeout is configurable via the attribute `logFileIoTimeout` within this valid range [500ms – 5000ms]. This ticket is going to improve the resilience of LOG service, so that log service can cache the write requests up to 30 seconds or so before giving up and returning status to caller. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3122 nid: unable to start UML cluster with tipc transport
- **status**: review --> fixed - **Comment**: commit 452b5163ccddf6cdef951d9b8ff283bbabd7c49e (HEAD -> develop, origin/develop, ticket-3122) Author: Vu Minh Nguyen Date: Mon Nov 25 13:41:43 2019 +0700 nid: fix unable to start UML cluster with tipc transport [#3122] --- ** [tickets:#3122] nid: unable to start UML cluster with tipc transport** **Status:** fixed **Milestone:** 5.20.01 **Created:** Mon Nov 25, 2019 06:35 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Nov 25, 2019 06:46 AM UTC **Owner:** Vu Minh Nguyen The below is nid.log: > Inserting TIPC mdoule... > insmod: can't insert '/lib/modules/4.18.20/kernel/net/tipc/tipc.ko': unknown > symbol in module, or unknown parameter > Configuring TIPC in Networking Mode... > error: No such file or directory > Unable to get TIPC nl family id (module loaded?) > error, message initialisation failed > error: No such file or directory > Unable to get TIPC nl family id (module loaded?) > error, message initialisation failed > error: No such file or directory > Unable to get TIPC nl family id (module loaded?) > error: message initialisation failed --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3122 nid: unable to start UML cluster with tipc transport
- **status**: accepted --> review --- ** [tickets:#3122] nid: unable to start UML cluster with tipc transport** **Status:** review **Milestone:** 5.20.01 **Created:** Mon Nov 25, 2019 06:35 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Nov 25, 2019 06:35 AM UTC **Owner:** Vu Minh Nguyen The below is nid.log: > Inserting TIPC mdoule... > insmod: can't insert '/lib/modules/4.18.20/kernel/net/tipc/tipc.ko': unknown > symbol in module, or unknown parameter > Configuring TIPC in Networking Mode... > error: No such file or directory > Unable to get TIPC nl family id (module loaded?) > error, message initialisation failed > error: No such file or directory > Unable to get TIPC nl family id (module loaded?) > error, message initialisation failed > error: No such file or directory > Unable to get TIPC nl family id (module loaded?) > error: message initialisation failed --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3122 nid: unable to start UML cluster with tipc transport
--- ** [tickets:#3122] nid: unable to start UML cluster with tipc transport** **Status:** accepted **Milestone:** 5.20.01 **Created:** Mon Nov 25, 2019 06:35 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Nov 25, 2019 06:35 AM UTC **Owner:** Vu Minh Nguyen The below is nid.log: > Inserting TIPC mdoule... > insmod: can't insert '/lib/modules/4.18.20/kernel/net/tipc/tipc.ko': unknown > symbol in module, or unknown parameter > Configuring TIPC in Networking Mode... > error: No such file or directory > Unable to get TIPC nl family id (module loaded?) > error, message initialisation failed > error: No such file or directory > Unable to get TIPC nl family id (module loaded?) > error, message initialisation failed > error: No such file or directory > Unable to get TIPC nl family id (module loaded?) > error: message initialisation failed --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3116 log: improve the resilience of log service
--- ** [tickets:#3116] log: improve the resilience of log service** **Status:** accepted **Milestone:** 5.20.01 **Created:** Tue Nov 05, 2019 07:22 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Nov 05, 2019 07:22 AM UTC **Owner:** Vu Minh Nguyen When the file system is unresponsive, log client gets try-again from write callback very shortly after I/O timeout reaches the setting; the value of I/O timeout is configurable via the attribute `logFileIoTimeout` within this valid range [500ms – 5000ms]. This ticket is going to improve the resilience of LOG service, so that log service can cache the write requests up to 30 seconds or so before giving up and returning status to caller. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3110 nid: the path to tipc.ko is incorrect
--- ** [tickets:#3110] nid: the path to tipc.ko is incorrect** **Status:** unassigned **Milestone:** 5.20.01 **Created:** Thu Oct 31, 2019 04:22 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Oct 31, 2019 04:22 AM UTC **Owner:** nobody In the `configure_tipc.in`, the variable `TIPC_MODULE` points to the wrong location of tipc kernel module: TIPC_MODULE=/lib/modules/$(uname -r)/kernel/net/tipc.ko It should be: TIPC_MODULE=/lib/modules/$(uname -r)/kernel/net/*tipc*/tipc.ko To avoid this mistake, it is better to use `modinfo` to get the path to a kernel module instead of using the fixed path. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3106 dtm: flush the logtrace asap when the logtrace owner is terminated
- **status**: assigned --> review --- ** [tickets:#3106] dtm: flush the logtrace asap when the logtrace owner is terminated** **Status:** review **Milestone:** 5.20.01 **Created:** Thu Oct 24, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Oct 24, 2019 04:26 AM UTC **Owner:** Vu Minh Nguyen This ticket will add a machanism in logtrace server, so that it can detect the logtrace owner terminated and does the flush right away to avoid losing traces from trace files. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3086 dtm: rotate logtrace on demand
- **status**: review --> fixed - **Comment**: commit 5fe2c27d116770696710468c0ef3c88cf342a894 (HEAD -> develop, origin/develop, ticket-3086) Author: Vu Minh Nguyen Date: Fri Oct 25 11:02:53 2019 +0700 dtm: rotate logtraces on demand [#3086] Introducing a new option '--rotate' to rotate given logtrace stream(s). This patch also cleans the code of LogServer::ExecuteCommand(). --- ** [tickets:#3086] dtm: rotate logtrace on demand** **Status:** fixed **Milestone:** 5.20.01 **Created:** Fri Sep 20, 2019 08:04 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Oct 21, 2019 03:30 AM UTC **Owner:** Vu Minh Nguyen Adding one new option to `osaflog` command that requests logtrace server to rotate trace file(s) of given stream(s) on demand. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3106 dtm: flush the logtrace asap when the logtrace owner is terminated
- Description has changed: Diff: --- old +++ new @@ -1,7 +1 @@ -Logtrace server flushes traces from its own buffers into trace files in two cases: -1) The size of trace buffer is big enough -2) It is over 15second from last flush - -So, there is a possibility of losing traces from trace files when the logtrace owner process is terminated, and short time later the node is rebooted before the logtrace server does the flush. - -This ticket adds a machanism in logtrace server, so that it can detect the logtrace owner terminated and do the flush right away to avoid losing traces. +This ticket will add a machanism in logtrace server, so that it can detect the logtrace owner terminated and does the flush right away to avoid losing traces from trace files. --- ** [tickets:#3106] dtm: flush the logtrace asap when the logtrace owner is terminated** **Status:** assigned **Milestone:** 5.20.01 **Created:** Thu Oct 24, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Oct 24, 2019 04:06 AM UTC **Owner:** Vu Minh Nguyen This ticket will add a machanism in logtrace server, so that it can detect the logtrace owner terminated and does the flush right away to avoid losing traces from trace files. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3106 dtm: flush the logtrace asap when the logtrace owner is terminated
- Description has changed: Diff: --- old +++ new @@ -2,6 +2,6 @@ 1) The size of trace buffer is big enough 2) It is over 15second from last flush -So, there is a possibility of losing traces from trace files when the logtrace owner process is terminated, and short time later the node is rebooted; and the reboot happens before the logtrace server does the flush. +So, there is a possibility of losing traces from trace files when the logtrace owner process is terminated, and short time later the node is rebooted before the logtrace server does the flush. This ticket adds a machanism in logtrace server, so that it can detect the logtrace owner terminated and do the flush right away to avoid losing traces. --- ** [tickets:#3106] dtm: flush the logtrace asap when the logtrace owner is terminated** **Status:** assigned **Milestone:** 5.20.01 **Created:** Thu Oct 24, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Oct 24, 2019 03:57 AM UTC **Owner:** Vu Minh Nguyen Logtrace server flushes traces from its own buffers into trace files in two cases: 1) The size of trace buffer is big enough 2) It is over 15second from last flush So, there is a possibility of losing traces from trace files when the logtrace owner process is terminated, and short time later the node is rebooted before the logtrace server does the flush. This ticket adds a machanism in logtrace server, so that it can detect the logtrace owner terminated and do the flush right away to avoid losing traces. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3106 dtm: flush the logtrace asap when the logtrace owner is terminated
--- ** [tickets:#3106] dtm: flush the logtrace asap when the logtrace owner is terminated** **Status:** assigned **Milestone:** 5.20.01 **Created:** Thu Oct 24, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Oct 24, 2019 03:57 AM UTC **Owner:** Vu Minh Nguyen Logtrace server flushes traces from its own buffers into trace files in two cases: 1) The size of trace buffer is big enough 2) It is over 15second from last flush So, there is a possibility of losing traces from trace files when the logtrace owner process is terminated, and short time later the node is rebooted; and the reboot happens before the logtrace server does the flush. This ticket adds a machanism in logtrace server, so that it can detect the logtrace owner terminated and do the flush right away to avoid losing traces. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3105 nid: remove the absolute path to tipc command in tipc-config script
- **Priority**: major --> minor --- ** [tickets:#3105] nid: remove the absolute path to tipc command in tipc-config script** **Status:** assigned **Milestone:** 5.20.01 **Created:** Tue Oct 22, 2019 07:38 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Oct 22, 2019 07:38 AM UTC **Owner:** Vu Minh Nguyen In /scripts/tipc-config script, it is referring to the absolute path of tipc command which is`/sbin/tipc`. It is better to use `which tipc` to locate the tipc command. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3105 nid: remove the absolute path to tipc command in tipc-config script
--- ** [tickets:#3105] nid: remove the absolute path to tipc command in tipc-config script** **Status:** assigned **Milestone:** 5.20.01 **Created:** Tue Oct 22, 2019 07:38 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Oct 22, 2019 07:38 AM UTC **Owner:** Vu Minh Nguyen In /scripts/tipc-config script, it is referring to the absolute path of tipc command which is`/sbin/tipc`. It is better to use `which tipc` to locate the tipc command. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3086 dtm: rotate logtrace on demand
- **status**: assigned --> review - **Priority**: minor --> major --- ** [tickets:#3086] dtm: rotate logtrace on demand** **Status:** review **Milestone:** 5.19.10 **Created:** Fri Sep 20, 2019 08:04 AM UTC by Vu Minh Nguyen **Last Updated:** Fri Sep 20, 2019 08:04 AM UTC **Owner:** Vu Minh Nguyen Adding one new option to `osaflog` command that requests logtrace server to rotate trace file(s) of given stream(s) on demand. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2642 dtm: Close unused log streams
- **status**: review --> fixed - **Comment**: commit 82b6d90d724d6e246ebd6661524012d059adeac8 (HEAD -> develop, origin/develop, ticket-2642) Author: Vu Minh Nguyen Date: Wed Oct 2 10:13:59 2019 +0700 dtm: close unused log streams [#2642] Providing a new option '--max-idle' to configure the maximum idle time of logtrace streams. If a stream has not been used for such time, logtrace server will close the stream from its database. --- ** [tickets:#2642] dtm: Close unused log streams** **Status:** fixed **Milestone:** 5.19.10 **Created:** Thu Oct 19, 2017 10:46 AM UTC by Anders Widell **Last Updated:** Tue Sep 24, 2019 02:58 AM UTC **Owner:** Vu Minh Nguyen Consider closing and freeing resources for log streams (except mds.log) that have not been used for a while (probably because trace was disabled using SIGUSR2). --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2642 dtm: Close unused log streams
- **status**: accepted --> review --- ** [tickets:#2642] dtm: Close unused log streams** **Status:** review **Milestone:** 5.19.10 **Created:** Thu Oct 19, 2017 10:46 AM UTC by Anders Widell **Last Updated:** Fri Sep 20, 2019 08:18 AM UTC **Owner:** Vu Minh Nguyen Consider closing and freeing resources for log streams (except mds.log) that have not been used for a while (probably because trace was disabled using SIGUSR2). --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3085 dtm: no_of_log_streams_ is not decreased when deleting a stream
- Description has changed: Diff: --- old +++ new @@ -1 +1,3 @@ Logtrace server increases no_of_log_streams when adding a stream into the list, but does not decrease when removing the stream; If we do adding and deleting log stream for sometime (31), logtrace server won't be able to log any trace. + +Besides, the allocated memory for the deleted stream is not freed when logtrace server removes the stream from the list. --- ** [tickets:#3085] dtm: no_of_log_streams_ is not decreased when deleting a stream** **Status:** accepted **Milestone:** 5.19.10 **Created:** Fri Sep 20, 2019 07:57 AM UTC by Vu Minh Nguyen **Last Updated:** Fri Sep 20, 2019 08:07 AM UTC **Owner:** Khanh Hoang Dang Logtrace server increases no_of_log_streams when adding a stream into the list, but does not decrease when removing the stream; If we do adding and deleting log stream for sometime (31), logtrace server won't be able to log any trace. Besides, the allocated memory for the deleted stream is not freed when logtrace server removes the stream from the list. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2642 dtm: Close unused log streams
- **status**: unassigned --> accepted - **assigned_to**: Vu Minh Nguyen - **Milestone**: future --> 5.19.10 --- ** [tickets:#2642] dtm: Close unused log streams** **Status:** accepted **Milestone:** 5.19.10 **Created:** Thu Oct 19, 2017 10:46 AM UTC by Anders Widell **Last Updated:** Wed Jan 09, 2019 09:48 PM UTC **Owner:** Vu Minh Nguyen Consider closing and freeing resources for log streams (except mds.log) that have not been used for a while (probably because trace was disabled using SIGUSR2). --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3085 dtm: no_of_log_streams_ is not decreased when deleting a stream
--- ** [tickets:#3085] dtm: no_of_log_streams_ is not decreased when deleting a stream** **Status:** unassigned **Milestone:** 5.19.10 **Created:** Fri Sep 20, 2019 07:57 AM UTC by Vu Minh Nguyen **Last Updated:** Fri Sep 20, 2019 07:57 AM UTC **Owner:** nobody Logtrace server increases no_of_log_streams when adding a stream into the list, but does not decrease when removing the stream; If we do adding and deleting log stream for sometime (31), logtrace server won't be able to log any trace. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3079 nid: flush internal log messages before stopping OpenSAF
--- ** [tickets:#3079] nid: flush internal log messages before stopping OpenSAF** **Status:** unassigned **Milestone:** 5.19.10 **Created:** Thu Sep 05, 2019 07:17 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Sep 05, 2019 07:17 AM UTC **Owner:** nobody Flush internal log server messages such as MDS log before stopping OpenSAF. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3075 imm: immdump is crashed
--- ** [tickets:#3075] imm: immdump is crashed** **Status:** unassigned **Milestone:** 5.19.10 **Created:** Thu Aug 29, 2019 03:17 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Aug 29, 2019 03:17 AM UTC **Owner:** nobody In the function `cacheRDNs`, there is no check the error code returned by saImmOmClassDescriptionGet_2(). If that call returns an error, immtool will access an unitialized buffer and crashed. Part of the coredump is below: ~~~ Program terminated with signal SIGSEGV, Segmentation fault. #0 cacheRDNs (selectedClassList=..., immHandle=2439541555471) at src/imm/tools/imm_dumper.cc:397 (gdb) bt #0 cacheRDNs (selectedClassList=..., immHandle=2439541555471) at src/imm/tools/imm_dumper.cc:397 #1 main (argc=, argv=) at src/imm/tools/imm_dumper.cc:346 ~~~ --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3066 scripts: use tipc instead of obsolute tipc-config in opensaf_reboot
- **status**: accepted --> fixed - **Comment**: commit 4f510540b9c3c0f9ff466cb2b8d7c03302094611 (HEAD -> develop, origin/develop, ticket-3066) Author: Vu Minh Nguyen Date: Wed Aug 14 16:48:51 2019 +0700 scripts: use tipc instead of obsolute tipc-config in opensaf_reboot [#3066] --- ** [tickets:#3066] scripts: use tipc instead of obsolute tipc-config in opensaf_reboot ** **Status:** fixed **Milestone:** 5.19.10 **Created:** Thu Aug 08, 2019 04:43 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Aug 08, 2019 04:43 AM UTC **Owner:** Vu Minh Nguyen Use `tipc` instead of obsolute `tipc-config` in opensaf_reboot script. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3066 scripts: use tipc instead of obsolute tipc-config in opensaf_reboot
--- ** [tickets:#3066] scripts: use tipc instead of obsolute tipc-config in opensaf_reboot ** **Status:** accepted **Milestone:** 5.19.10 **Created:** Thu Aug 08, 2019 04:43 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Aug 08, 2019 04:43 AM UTC **Owner:** Vu Minh Nguyen Use `tipc` instead of obsolute `tipc-config` in opensaf_reboot script. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2104 nid: Use the tipc command instead of tipc-config
- **status**: review --> fixed - **assigned_to**: Vu Minh Nguyen --> nobody - **Milestone**: future --> 5.19.10 - **Comment**: commit d843f0e711230e97eaa0cb99ba2527b79ec106e5 (HEAD -> develop, origin/develop) Author: Vu Minh Nguyen Date: Tue Aug 6 10:08:25 2019 +0700 nid: use the tipc command instead of tipc-config [#2104] The tipc-config command is obsolete and no longer being maintained. We should switch to using the "tipc" command instead --- ** [tickets:#2104] nid: Use the tipc command instead of tipc-config** **Status:** fixed **Milestone:** 5.19.10 **Created:** Fri Oct 07, 2016 04:58 PM UTC by Anders Widell **Last Updated:** Wed Jul 31, 2019 09:17 AM UTC **Owner:** nobody The tipc-config command is obsolete and no longer being maintained. We should switch to using the "tipc" command instead. In addition, the printout of `tipc node get addr` has been changed since kernel version 4.17 - no longer uses the Z.C.N format 1) Old printout SC-1@~ # tipc node get addr <1.1.1> 2) New printout ~~~ SC-1@~ # tipc node get addr 01001001 ~~~ So, the the wrapper script `tipc-config` also needs to be updated to work with these printouts. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3065 smf: warnings when compiling code with clang
- **summary**: smf: warnings when compling code with clang --> smf: warnings when compiling code with clang --- ** [tickets:#3065] smf: warnings when compiling code with clang** **Status:** unassigned **Milestone:** 5.19.10 **Created:** Tue Aug 06, 2019 08:01 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Aug 06, 2019 08:01 AM UTC **Owner:** nobody ./src/smf/smfd/SmfUtils.h:65:20: warning: 'smf_valueToString' has C-linkage specified, but returns user-defined type 'std::string' (aka 'basic_string') which is incompatible with C [-Wreturn-type-c-linkage] extern std::string smf_valueToString(SaImmAttrValueT value, ^ ./src/smf/smfd/SmfUtils.h:72:26: warning: 'smfStateToString' has C-linkage specified, but returns user-defined type 'const std::string' (aka 'const basic_string') which is incompatible with C [-Wreturn-type-c-linkage] extern const std::string smfStateToString(const uint32_t& i_stateId, ^ src/smf/smfd/SmfUpgradeCampaign.cc:933:61: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] std::string error = "To many campaign restarts, max " + cnt; ~~^ src/smf/smfd/SmfUpgradeCampaign.cc:933:61: note: use array indexing to silence this warning std::string error = "To many campaign restarts, max " + cnt; ^ & [] --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3065 smf: warnings when compling code with clang
--- ** [tickets:#3065] smf: warnings when compling code with clang** **Status:** unassigned **Milestone:** 5.19.10 **Created:** Tue Aug 06, 2019 08:01 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Aug 06, 2019 08:01 AM UTC **Owner:** nobody ./src/smf/smfd/SmfUtils.h:65:20: warning: 'smf_valueToString' has C-linkage specified, but returns user-defined type 'std::string' (aka 'basic_string') which is incompatible with C [-Wreturn-type-c-linkage] extern std::string smf_valueToString(SaImmAttrValueT value, ^ ./src/smf/smfd/SmfUtils.h:72:26: warning: 'smfStateToString' has C-linkage specified, but returns user-defined type 'const std::string' (aka 'const basic_string') which is incompatible with C [-Wreturn-type-c-linkage] extern const std::string smfStateToString(const uint32_t& i_stateId, ^ src/smf/smfd/SmfUpgradeCampaign.cc:933:61: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] std::string error = "To many campaign restarts, max " + cnt; ~~^ src/smf/smfd/SmfUpgradeCampaign.cc:933:61: note: use array indexing to silence this warning std::string error = "To many campaign restarts, max " + cnt; ^ & [] --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2770 imm: data size mismatches in pbe code
- **status**: review --> unassigned
- **assigned_to**: Vu Minh Nguyen --> nobody
---
** [tickets:#2770] imm: data size mismatches in pbe code**
**Status:** unassigned
**Milestone:** 5.19.10
**Created:** Wed Jan 24, 2018 03:42 PM UTC by Vu Minh Nguyen
**Last Updated:** Tue Jul 23, 2019 12:26 AM UTC
**Owner:** nobody
Object ID and Class ID are `unsigned int` data type, but they are not used
consistently through the codes (local variables and function parameters) - few
places use `int`.
If the values of these IDs reach over MAX_INT, we may have problem when doing
sqlite queries.
::: C++
static void valuesToPBE(const SaImmAttrValuesT_2 *p, SaImmAttrFlagsT
attrFlags, int objId, void *db_handle) {}
void objectModifyDiscardMatchingValuesOfAttrToPBE(
void *db_handle, std::string objName, const SaImmAttrValuesT_2 *attrValue,
SaUint64T ccb_id) {
int object_id;
int class_id;
}
---
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.___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2104 nid: Use the tipc command instead of tipc-config
- **status**: accepted --> review --- ** [tickets:#2104] nid: Use the tipc command instead of tipc-config** **Status:** review **Milestone:** future **Created:** Fri Oct 07, 2016 04:58 PM UTC by Anders Widell **Last Updated:** Tue Jul 09, 2019 08:18 AM UTC **Owner:** Vu Minh Nguyen The tipc-config command is obsolete and no longer being maintained. We should switch to using the "tipc" command instead. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2104 nid: Use the tipc command instead of tipc-config
We already has `tipc_config` script under `tools/cluster_sim_uml/archive/scripts/`. I will make it valid for other uses such as in configure_tipc. --- ** [tickets:#2104] nid: Use the tipc command instead of tipc-config** **Status:** accepted **Milestone:** future **Created:** Fri Oct 07, 2016 04:58 PM UTC by Anders Widell **Last Updated:** Tue Jul 09, 2019 08:14 AM UTC **Owner:** Vu Minh Nguyen The tipc-config command is obsolete and no longer being maintained. We should switch to using the "tipc" command instead. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2104 nid: Use the tipc command instead of tipc-config
- **status**: unassigned --> accepted --- ** [tickets:#2104] nid: Use the tipc command instead of tipc-config** **Status:** accepted **Milestone:** future **Created:** Fri Oct 07, 2016 04:58 PM UTC by Anders Widell **Last Updated:** Tue Jul 09, 2019 08:14 AM UTC **Owner:** Vu Minh Nguyen The tipc-config command is obsolete and no longer being maintained. We should switch to using the "tipc" command instead. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2104 nid: Use the tipc command instead of tipc-config
- **assigned_to**: Vu Minh Nguyen - **Blocker**: --> False --- ** [tickets:#2104] nid: Use the tipc command instead of tipc-config** **Status:** unassigned **Milestone:** future **Created:** Fri Oct 07, 2016 04:58 PM UTC by Anders Widell **Last Updated:** Thu Jul 20, 2017 07:59 AM UTC **Owner:** Vu Minh Nguyen The tipc-config command is obsolete and no longer being maintained. We should switch to using the "tipc" command instead. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1606 mbc: No error handling when sending peer-discovery messages
- Attachments has changed: Diff: --- old +++ new @@ -1 +0,0 @@ -mbcsv.7z (3.1 MB; application/octet-stream) --- ** [tickets:#1606] mbc: No error handling when sending peer-discovery messages** **Status:** fixed **Milestone:** 4.6.2 **Created:** Fri Nov 20, 2015 07:14 AM UTC by Hung Nguyen **Last Updated:** Wed Jan 06, 2016 12:09 PM UTC **Owner:** Neelakanta Reddy When a standby peer is up, it will: 1. send PEER_UP_MSG to active peer 2. receive PEER_INFO_MSG from active peer 3. send PEER_INFO_RSP_MSG to active peer But if the active peer fails to send PEER_INFO_MSG, the standby peer will also never send PEER_INFO_RSP_MSG to the active peer. --- trace on active peer --- osafimmd [4477:mbcsv_peer.c:0897] >> mbcsv_send_peer_disc_msg osafimmd [4477:mbcsv_peer.c:0908] TR peer info msg osafimmd [4477:mbcsv_mds.c:0185] >> mbcsv_mds_send_msg: sending to vdest:d osafimmd [4477:mbcsv_mds.c:0201] TR send type MDS_SENDTYPE_RED osafimmd [4477:mbcsv_mds.c:0247] << mbcsv_mds_send_msg: failure osafimmd [4477:mbcsv_peer.c:0942] << mbcsv_send_peer_disc_msg That resulted in the active peer kept the standby peer in 'NCS_MBCSV_ACT_STATE_IDLE' state. The state would have been changed to 'NCS_MBCSV_ACT_STATE_WAIT_FOR_COLD_WARM_SYNC' if the standby had been able to send the PEER_INFO_RSP_MSG to the active peer. And that made the active peer failed to dispatch on NCSMBCSV_EVENT_COLD_SYNC_REQ. --- trace on standby peer --- osafimmd [4645:mbcsv_act.c:0293] TR sending cold sync req. myrole: 2, svc_id: 42, pwe_hdl: 65549 ... osafimmd [4645:mbcsv_tmr.c:0250] TR Timer expired. my role:2, svc_id:42, pwe_hdl:65549, peer_anchor:565213722578604, tmr type:NCS_MBCSV_TMR_SEND_COLD_SYNC --- trace on active peer --- osafimmd [4477:mbcsv_pr_evts.c:0068] >> mbcsv_process_events: mbcsv hdl: 4293918753 osafimmd [4477:mbcsv_pr_evts.c:0160] TR Internal event osafimmd [4477:mbcsv_act.c:0079] TR Illegal dispatch event. role:1, svc_id: 42, pwe_hdl:65549 osafimmd [4477:mbcsv_pr_evts.c:0222] << mbcsv_process_events MBC should somehow retry mbcsv_mds_send_msg when it fails. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1776 imm: IMMND crashes when receiving update-rt-attribute response after it is timed out
- Attachments has changed: Diff: --- old +++ new @@ -1 +0,0 @@ -src.zip (3.0 kB; application/x-zip-compressed) --- ** [tickets:#1776] imm: IMMND crashes when receiving update-rt-attribute response after it is timed out** **Status:** fixed **Milestone:** 4.6.2 **Created:** Fri Apr 22, 2016 04:50 AM UTC by Hung Nguyen **Last Updated:** Thu Apr 28, 2016 09:35 AM UTC **Owner:** Hung Nguyen Source code of test application is attached to this ticket. Import the 'Test' class and create some objects of it. root@SC-1:~# immcfg -f test_class.xml root@SC-1:~# immpopulate -p 10 Test Run the OI. The OI has a sleep of 7 seconds in SaImmOiRtAttrUpdateCallbackT. root@SC-1:~# ./test_oi & Try to read all objects of 'Test' class root@SC-1:~# ./test_search IMMND crashes when receiving respose from the OI. Apr 22 11:27:51 SC-2 osafimmnd[431]: immnd_evt.c:1080: search_req_continue: Assertion 'strncmp((const char *)rsp->objectName.buf, (const char *)reply->runtimeAttrs.objectName.buf, rsp->objectName.size) == 0' failed. - Analysis: When the upcall to OI is timed out, IMMND erases the Continuation from the sSearchReqContinuationMap but it still keeps the search-node (and the searchOp). On the search client, after getting timeout, it doesn't finalize the search handle and continues to do SearchNext(). That makes the searchOp in IMMND pop out a new object and store it to mLastResult. When the response from OI arrives at IMMND, it fails to assert because a new object in searchOp has been popped out. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1776 imm: IMMND crashes when receiving update-rt-attribute response after it is timed out
--- ** [tickets:#1776] imm: IMMND crashes when receiving update-rt-attribute response after it is timed out** **Status:** fixed **Milestone:** 4.6.2 **Created:** Fri Apr 22, 2016 04:50 AM UTC by Hung Nguyen **Last Updated:** Thu Apr 28, 2016 09:35 AM UTC **Owner:** Hung Nguyen Source code of test application is attached to this ticket. Import the 'Test' class and create some objects of it. root@SC-1:~# immcfg -f test_class.xml root@SC-1:~# immpopulate -p 10 Test Run the OI. The OI has a sleep of 7 seconds in SaImmOiRtAttrUpdateCallbackT. root@SC-1:~# ./test_oi & Try to read all objects of 'Test' class root@SC-1:~# ./test_search IMMND crashes when receiving respose from the OI. Apr 22 11:27:51 SC-2 osafimmnd[431]: immnd_evt.c:1080: search_req_continue: Assertion 'strncmp((const char *)rsp->objectName.buf, (const char *)reply->runtimeAttrs.objectName.buf, rsp->objectName.size) == 0' failed. - Analysis: When the upcall to OI is timed out, IMMND erases the Continuation from the sSearchReqContinuationMap but it still keeps the search-node (and the searchOp). On the search client, after getting timeout, it doesn't finalize the search handle and continues to do SearchNext(). That makes the searchOp in IMMND pop out a new object and store it to mLastResult. When the response from OI arrives at IMMND, it fails to assert because a new object in searchOp has been popped out. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1817 imm: IMMND crashes when receiving ccb-apply request for purged ccb
- Attachments has changed: Diff: --- old +++ new @@ -1 +0,0 @@ -logs_n_testapp.tgz (26.1 MB; application/x-compressed) --- ** [tickets:#1817] imm: IMMND crashes when receiving ccb-apply request for purged ccb** **Status:** fixed **Milestone:** 4.7.2 **Created:** Tue May 10, 2016 03:20 AM UTC by Hung Nguyen **Last Updated:** Thu May 19, 2016 04:43 AM UTC **Owner:** Hung Nguyen The application tried to delete an config object. While waiting for response from OI for the delete operation, timeout occurred. It seemed that the IMMA_SYNCR_TIMEOUT is smaller than IMMA_OI_CALLBACK_TIMEOUT. CcbObjectDelete() returned ERR_TIMEOUT and the library sent A2ND_CL_TIMEOUT to server. ~~~ library trace 14:12:13.100461 imma [24022:imma_om_api.c:2682] >> ccb_object_delete_common 14:12:23.109589 imma [24022:imma_om_api.c:2901] TR objectDelete send RETURNED:5 14:12:23.109622 imma [24022:imma_om_api.c:2995] TR objectDelete really RETURNING:5 14:12:23.109632 imma [24022:imma_om_api.c:2996] << ccb_object_delete_common server trace 14:12:23.109681 osafimmnd [5140:immsv_evt.c:5457] T8 Received: IMMND_EVT_A2ND_CL_TIMEOUT (93) from 2010f 14:12:23.109708 osafimmnd [5140:immnd_evt.c:2019] >> immnd_evt_proc_cl_imma_timeout 14:12:23.109721 osafimmnd [5140:immnd_evt.c:2021] T2 timeout in imma library for handle: 4622010f 14:12:23.109728 osafimmnd [5140:ImmModel.cc:12697] >> purgeSyncRequest 14:12:23.109736 osafimmnd [5140:ImmModel.cc:12801] T5 Purged Ccb continuation for ccb:354 in state 5 14:12:23.109742 osafimmnd [5140:ImmModel.cc:12804] << purgeSyncRequest 14:12:23.109779 osafimmnd [5140:immnd_evt.c:2049] << immnd_evt_proc_cl_imma_timeout ~~~ Later the timeout occurred in IMM server (::cleanTheBasement). ~~~ 14:12:23.387649 osafimmnd [5140:ImmModel.cc:12874] TR Checking active ccb 354 for deadlock or blocked implementer 14:12:23.387655 osafimmnd [5140:ImmModel.cc:12876] TR state:5 waitsart:1462363933 PberestartId:0 14:12:23.387660 osafimmnd [5140:ImmModel.cc:12905] T5 CCB 354 timeout while waiting on implementer reply ... 14:12:23.389093 osafimmnd [5140:immnd_proc.c:1244] WA Timeout while waiting for implementer, aborting ccb:354 14:12:23.389116 osafimmnd [5140:immsv_evt.c:5438] T8 Sending: IMMD_EVT_ND2D_ABORT_CCB to 0 ... 14:12:23.394866 osafimmnd [5140:immsv_evt.c:5457] T8 Received: IMMND_EVT_D2ND_ABORT_CCB (62) from 0 14:12:23.394871 osafimmnd [5140:immnd_evt.c:7488] >> immnd_evt_proc_ccb_finalize 14:12:23.394876 osafimmnd [5140:immnd_evt.c:6730] >> immnd_evt_ccb_abort 14:12:23.394880 osafimmnd [5140:immnd_evt.c:6734] TR We expect there to be a PBE 14:12:23.394949 osafimmnd [5140:ImmModel.cc:5792] >> ccbAbort 14:12:23.394973 osafimmnd [5140:ImmModel.cc:5801] T5 ABORT CCB 354 14:12:23.394987 osafimmnd [5140:ImmModel.cc:5822] NO Aborting ccb 354 while waiting for replies from implementers on DELETE-OP 14:12:23.394997 osafimmnd [5140:ImmModel.cc:5870] NO Ccb 354 ABORTED (immcfg_SC-2-1_24022) 14:12:23.395008 osafimmnd [5140:immnd_evt.c:6752] T2 ccb:354 is originated from this node 14:12:23.395036 osafimmnd [5140:immnd_evt.c:6862] << immnd_evt_ccb_abort 14:12:23.395043 osafimmnd [5140:immnd_evt.c:7506] T2 ccbFinalize originated at this node => Send reply 14:12:23.395047 osafimmnd [5140:immnd_evt.c:7513] T2 client == m_IMMSV_UNPACK_HANDLE_HIGH(clnt_hdl))??: 0 == 0 14:12:23.395064 osafimmnd [5140:immnd_evt.c:7517] WA IMMND - Client went down so no response 14:12:23.395069 osafimmnd [5140:ImmModel.cc:5951] >> ccbTerminate 14:12:23.395073 osafimmnd [5140:ImmModel.cc:5960] T5 terminate the CCB 354 14:12:23.395078 osafimmnd [5140:ImmModel.cc:6019] T2 Aborting Delete of safAmfNodeGroup=scale_in_shutdown,safAmfCluster=myAmfCluster 14:12:23.395084 osafimmnd [5140:ImmModel.cc:6025] T5 Flags after remove delete lock:0 14:12:23.395089 osafimmnd [5140:ImmModel.cc:6148] T5 Ccb Wait-time for GC set. State: 12/ABORTED 14:12:23.395095 osafimmnd [5140:ImmModel.cc:6178] << ccbTerminate 14:12:23.395099 osafimmnd [5140:immnd_evt.c:7535] << immnd_evt_proc_ccb_finalize ~~~ The application then invoked CcbApply() and IMMND crashed. ~~~ 14:12:26.113187 osafimmnd [5140:immsv_evt.c:5457] T8 Received: IMMND_EVT_A2ND_CCB_APPLY (33) from 0 14:12:26.113195 osafimmnd [5140:immnd_evt.c:7578] >> immnd_evt_proc_ccb_apply 14:12:26.113204 osafimmnd [5140:immnd_evt.c:7599] TR We expect there to be a PBE 14:12:26.113211 osafimmnd [5140:ImmModel.cc:5176] >> ccbApply 14:12:26.113217 osafimmnd [5140:ImmModel.cc:5180] T5 APPLYING CCB ID:354 14:12:26 SC-2-1 osafimmnd[5140]: ImmModel.cc:5242: ccbApply: Assertion 'reqConn==0 || (ccb->mOriginatingConn == reqConn)' failed. ~~~ --- testapp to reproduce the problem root@SC-1:~# immcfg -f ./test_class.xml root@SC-1:~# ./test_oi & [1] 1256 root@SC-1:~# export IMMA_SYNCR_TIMEOUT=300 root@SC-1:~# ./test_ccb saImmOmCcbObjectCreate_2 5 --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To
[tickets] [opensaf:tickets] #194 AMF: Creating new comp/csi in existing N-way active SG does not work
- Attachments has changed: Diff: --- old +++ new @@ -1 +0,0 @@ -H:\CoreMW\OSS\OSSRCJIT\ticket.tgz (3.3 kB; application/x-gzip-compressed) --- ** [tickets:#194] AMF: Creating new comp/csi in existing N-way active SG does not work** **Status:** fixed **Milestone:** 4.2.5 **Created:** Tue May 14, 2013 09:09 AM UTC by Bertil Engelholm **Last Updated:** Mon Nov 18, 2013 09:23 AM UTC **Owner:** nobody I'm trying to add a new component (and csi for it) in an existing N-way active SG and it does not work. If I create all new objects in the same IMM CCB AMF complains about missing Compcsi. If the new CSI is created in a separate CCB the creating works but the new component is not started. If I in this state locks/unlocks (amf-adm lock/unlock) the SuA1 all components comes up. But if I in this state also try to lock/unlock SuA2, the amf-adm lock hangs. I have attached a tar file that contains three campaigns that creates the configurations. install_JavaSgA_campaign.xml installs a basic simulated Java configuration. addCompCsi-1_campaign.xml tries to add the comp/csi in one CCB which fails. addCompCsi-2_campaign.xml adds the csi in a separate CCB which works but comp does not start and SU lock/unlock hangs. So first run the install campaign and then either addCompCsi-1 or addCompCsi-2. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1702 Coredump in mdstest when executing "mdstest 11 1"
- Attachments has changed: Diff: --- old +++ new @@ -1 +0,0 @@ -C:\Users\uabrode\Downloads\Ticket\osaftestLog-2016-03-16_00-09-20.tgz (4.1 MB; application/x-gzip-compressed) --- ** [tickets:#1702] Coredump in mdstest when executing "mdstest 11 1"** **Status:** fixed **Milestone:** 5.0.FC **Created:** Thu Mar 17, 2016 12:14 PM UTC by Per Rodenvall **Last Updated:** Wed Mar 30, 2016 03:53 AM UTC **Owner:** A V Mahesh (AVM) **Steps to reproduce** Execute mdstest 11 1 on opensaf 5.0 **Observed behaviour** Coredump in mdstest **Expected behaviour** Test will finish successfully **Error messages** core.1457468950.mdstest.1477.SC-1 This fault has been observed now and then after #1522 was implemented in opensaf default (5.0). Coredumps could be found inside attached files under for example: osaftestLog-2016-03-08_23-11-26\osaftestLog-2016-03-08_23-11-26~\osaftestLog-2016-03-08_23-11-26\SC-1\core Description: Testcase start@: 2016-03-08 21:23:05,172 INFO - TestCase:setUp Start | test_mds_suite (osaftest.tests.mds.test.Test) Testcase failed@: 2016-03-08 21:29:10, INFO - Printing stack trace of core.1457468950.mdstest.1477.SC-1 which occurs on 2016-03-08 21:29: 10 - OpenSAF 5.0.M0 - 4543:1eb9275e08ad:default 2016-03-08 21:35:16,856 INFO - MDS test result: 2016-03-08 21:35:16,857 INFO - Total number of succeed_testcases: 110 2016-03-08 21:35:16,857 ERROR - Nr of testcases failed: 1. Failed testcases => 2016-03-08 21:35:16,857 ERROR - Node: SC-1, Suite: 11, Test: 1 :Svc EXTMIN on ADEST sends a LOW Priority message to Svc EXTMIN on VDEST=200 and expects a Response 2016-03-08 21:35:16,918 DEBUG - TestCase:tearDown Start | test_mds_suite (osaftest.tests.mds.test.Test) 2016-03-08 21:35:17,215 WARNING - 1 coredump have been generated unexpectedly 2016-03-08 21:35:17,232 INFO - Printing stack trace of core.1457468950.mdstest.1477.SC-1 which occurs on 2016-03-08 21: 29:10 - OpenSAF 5.0.M0 - 4543:1eb9275e08ad:default 2016-03-08 21:35:17,257 DEBUG - exec cmd 'ls /usr/local/lib/opensaf/mdstest' on SC-1 2016-03-08 21:35:17,785 INFO - Stack trace of core.1457468950.mdstest.1477.SC-1 [New LWP 1487] [New LWP 1485] [New LWP 1477] [New LWP 1484] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `mdstest 11 1'. Program terminated with signal SIGABRT, Aborted. 2016-03-08 21:29:10,746 DEBUG - *** FAILED in suite-11, test-1,command: "mdstest 11 1" return_code-134 2016-03-08 21:29:10,746 DEBUG - Output: Suite 11: Send Responce Ack test cases /ntet_initialise_setup: Get an ADEST handle,Create PWE=2 on ADEST,Install EXTMIN and INTMIN svc on ADEST,Install INTMIN, EXTMIN services on ADEST's PWE=2, Create VDEST 100 and VDEST 200,Change the role of VDEST 200 to ACTIVE, Install EXTMIN service on VDEST 100,Install INTMIN, EXTMIN services on VDEST 200 ADEST <2010f05c5 > : GET_HDLS is SUCCESSFUL 100 : VDEST_CREATE is SUCCESSFUL 200 : VDEST_CREATE is SUCCESSFUL VDEST_CHANGE ROLE to 1 is SUCCESSFULL PWE_CREATE is SUCCESSFUL : PWE = 2 256 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL 256 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL 256 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL Test Case 1: Svc EXTMIN on ADEST sends a LOW Priority message to Svc EXTMIN on VDEST=200 and expects a Response MDS SERVICE SUBSCRIBE is SUCCESSFULL MDS RETRIEVE is SUCCESSFULLTask has been Created The service which is sending the message is = 512 The service to which the message needs to be delivered = 512 Inside Receiver Thread The Sender service = 512 is on destination =<2010f05c5> with anchor = <2010f05c5> Node 2010f and msg fmt ver = 1 The Receiver service = 512 is on destination =<2010f05c5> Received Message len = 30 The message is= Hi Receiver! Are you there? MDS RETRIEVE is SUCCESSFULL The service which is sending the message is = 512 The service to which the message needs to be delivered = 512 MDS SEND RESPONSE is SUCCESSFULL The response got from the receiver is : message length = 41 message = Yes Sender! I am in. Message Delivered? Success TASK is released MDS CANCEL SUBSCRIBE is SUCCESSFULLUninstalling the services on both VDESTs and ADEST UnInstalling the Services on both the VDESTs MDS RETRIEVE is SUCCESSFULL 512 : SERVICE UNINSTALL is SUCCESSFULL MDS RETRIEVE is SUCCESSFULL 256 : SERVICE UNINSTALL is SUCCESSFULL MDS RETRIEVE is SUCCESSFULL 512 : SERVICE UNINSTALL is SUCCESSFULL Destroying the VDESTS Destroying both the VDESTs and PWE=2 on ADEST VDEST_CHANGE ROLE to 2 is SUCCESSFULL 200 : VDEST_DESTROY is SUCCESSFUL --- 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
[tickets] [opensaf:tickets] #1702 Coredump in mdstest when executing "mdstest 11 1"
- Attachments has changed: Diff: --- old +++ new @@ -1,3 +1,2 @@ -C:\Users\uabrode\Downloads\Ticket\osaftestLog-2016-03-08_23-11-26.gz (4.6 MB; application/x-gzip) C:\Users\uabrode\Downloads\Ticket\osaftestLog-2016-03-12_00-00-23.tgz (4.5 MB; application/x-gzip-compressed) C:\Users\uabrode\Downloads\Ticket\osaftestLog-2016-03-16_00-09-20.tgz (4.1 MB; application/x-gzip-compressed) --- ** [tickets:#1702] Coredump in mdstest when executing "mdstest 11 1"** **Status:** fixed **Milestone:** 5.0.FC **Created:** Thu Mar 17, 2016 12:14 PM UTC by Per Rodenvall **Last Updated:** Wed Mar 30, 2016 03:53 AM UTC **Owner:** A V Mahesh (AVM) **Attachments:** - [C:\Users\uabrode\Downloads\Ticket\osaftestLog-2016-03-12_00-00-23.tgz](https://sourceforge.net/p/opensaf/tickets/1702/attachment/C%3A%5CUsers%5Cuabrode%5CDownloads%5CTicket%5CosaftestLog-2016-03-12_00-00-23.tgz) (4.5 MB; application/x-gzip-compressed) - [C:\Users\uabrode\Downloads\Ticket\osaftestLog-2016-03-16_00-09-20.tgz](https://sourceforge.net/p/opensaf/tickets/1702/attachment/C%3A%5CUsers%5Cuabrode%5CDownloads%5CTicket%5CosaftestLog-2016-03-16_00-09-20.tgz) (4.1 MB; application/x-gzip-compressed) **Steps to reproduce** Execute mdstest 11 1 on opensaf 5.0 **Observed behaviour** Coredump in mdstest **Expected behaviour** Test will finish successfully **Error messages** core.1457468950.mdstest.1477.SC-1 This fault has been observed now and then after #1522 was implemented in opensaf default (5.0). Coredumps could be found inside attached files under for example: osaftestLog-2016-03-08_23-11-26\osaftestLog-2016-03-08_23-11-26~\osaftestLog-2016-03-08_23-11-26\SC-1\core Description: Testcase start@: 2016-03-08 21:23:05,172 INFO - TestCase:setUp Start | test_mds_suite (osaftest.tests.mds.test.Test) Testcase failed@: 2016-03-08 21:29:10, INFO - Printing stack trace of core.1457468950.mdstest.1477.SC-1 which occurs on 2016-03-08 21:29: 10 - OpenSAF 5.0.M0 - 4543:1eb9275e08ad:default 2016-03-08 21:35:16,856 INFO - MDS test result: 2016-03-08 21:35:16,857 INFO - Total number of succeed_testcases: 110 2016-03-08 21:35:16,857 ERROR - Nr of testcases failed: 1. Failed testcases => 2016-03-08 21:35:16,857 ERROR - Node: SC-1, Suite: 11, Test: 1 :Svc EXTMIN on ADEST sends a LOW Priority message to Svc EXTMIN on VDEST=200 and expects a Response 2016-03-08 21:35:16,918 DEBUG - TestCase:tearDown Start | test_mds_suite (osaftest.tests.mds.test.Test) 2016-03-08 21:35:17,215 WARNING - 1 coredump have been generated unexpectedly 2016-03-08 21:35:17,232 INFO - Printing stack trace of core.1457468950.mdstest.1477.SC-1 which occurs on 2016-03-08 21: 29:10 - OpenSAF 5.0.M0 - 4543:1eb9275e08ad:default 2016-03-08 21:35:17,257 DEBUG - exec cmd 'ls /usr/local/lib/opensaf/mdstest' on SC-1 2016-03-08 21:35:17,785 INFO - Stack trace of core.1457468950.mdstest.1477.SC-1 [New LWP 1487] [New LWP 1485] [New LWP 1477] [New LWP 1484] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `mdstest 11 1'. Program terminated with signal SIGABRT, Aborted. 2016-03-08 21:29:10,746 DEBUG - *** FAILED in suite-11, test-1,command: "mdstest 11 1" return_code-134 2016-03-08 21:29:10,746 DEBUG - Output: Suite 11: Send Responce Ack test cases /ntet_initialise_setup: Get an ADEST handle,Create PWE=2 on ADEST,Install EXTMIN and INTMIN svc on ADEST,Install INTMIN, EXTMIN services on ADEST's PWE=2, Create VDEST 100 and VDEST 200,Change the role of VDEST 200 to ACTIVE, Install EXTMIN service on VDEST 100,Install INTMIN, EXTMIN services on VDEST 200 ADEST <2010f05c5 > : GET_HDLS is SUCCESSFUL 100 : VDEST_CREATE is SUCCESSFUL 200 : VDEST_CREATE is SUCCESSFUL VDEST_CHANGE ROLE to 1 is SUCCESSFULL PWE_CREATE is SUCCESSFUL : PWE = 2 256 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL 256 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL 256 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL Test Case 1: Svc EXTMIN on ADEST sends a LOW Priority message to Svc EXTMIN on VDEST=200 and expects a Response MDS SERVICE SUBSCRIBE is SUCCESSFULL MDS RETRIEVE is SUCCESSFULLTask has been Created The service which is sending the message is = 512 The service to which the message needs to be delivered = 512 Inside Receiver Thread The Sender service = 512 is on destination =<2010f05c5> with anchor = <2010f05c5> Node 2010f and msg fmt ver = 1 The Receiver service = 512 is on destination =<2010f05c5> Received Message len = 30 The message is= Hi Receiver! Are you there? MDS RETRIEVE is SUCCESSFULL The service which is sending the message is = 512 The service to which the message needs to be delivered = 512 MDS SEND RESPONSE is SUCCESSFULL The response got from the receiver is : message length = 41 message = Yes Sender!
[tickets] [opensaf:tickets] #1702 Coredump in mdstest when executing "mdstest 11 1"
- Attachments has changed: Diff: --- old +++ new @@ -1,2 +1 @@ -C:\Users\uabrode\Downloads\Ticket\osaftestLog-2016-03-12_00-00-23.tgz (4.5 MB; application/x-gzip-compressed) C:\Users\uabrode\Downloads\Ticket\osaftestLog-2016-03-16_00-09-20.tgz (4.1 MB; application/x-gzip-compressed) --- ** [tickets:#1702] Coredump in mdstest when executing "mdstest 11 1"** **Status:** fixed **Milestone:** 5.0.FC **Created:** Thu Mar 17, 2016 12:14 PM UTC by Per Rodenvall **Last Updated:** Wed Mar 30, 2016 03:53 AM UTC **Owner:** A V Mahesh (AVM) **Attachments:** - [C:\Users\uabrode\Downloads\Ticket\osaftestLog-2016-03-16_00-09-20.tgz](https://sourceforge.net/p/opensaf/tickets/1702/attachment/C%3A%5CUsers%5Cuabrode%5CDownloads%5CTicket%5CosaftestLog-2016-03-16_00-09-20.tgz) (4.1 MB; application/x-gzip-compressed) **Steps to reproduce** Execute mdstest 11 1 on opensaf 5.0 **Observed behaviour** Coredump in mdstest **Expected behaviour** Test will finish successfully **Error messages** core.1457468950.mdstest.1477.SC-1 This fault has been observed now and then after #1522 was implemented in opensaf default (5.0). Coredumps could be found inside attached files under for example: osaftestLog-2016-03-08_23-11-26\osaftestLog-2016-03-08_23-11-26~\osaftestLog-2016-03-08_23-11-26\SC-1\core Description: Testcase start@: 2016-03-08 21:23:05,172 INFO - TestCase:setUp Start | test_mds_suite (osaftest.tests.mds.test.Test) Testcase failed@: 2016-03-08 21:29:10, INFO - Printing stack trace of core.1457468950.mdstest.1477.SC-1 which occurs on 2016-03-08 21:29: 10 - OpenSAF 5.0.M0 - 4543:1eb9275e08ad:default 2016-03-08 21:35:16,856 INFO - MDS test result: 2016-03-08 21:35:16,857 INFO - Total number of succeed_testcases: 110 2016-03-08 21:35:16,857 ERROR - Nr of testcases failed: 1. Failed testcases => 2016-03-08 21:35:16,857 ERROR - Node: SC-1, Suite: 11, Test: 1 :Svc EXTMIN on ADEST sends a LOW Priority message to Svc EXTMIN on VDEST=200 and expects a Response 2016-03-08 21:35:16,918 DEBUG - TestCase:tearDown Start | test_mds_suite (osaftest.tests.mds.test.Test) 2016-03-08 21:35:17,215 WARNING - 1 coredump have been generated unexpectedly 2016-03-08 21:35:17,232 INFO - Printing stack trace of core.1457468950.mdstest.1477.SC-1 which occurs on 2016-03-08 21: 29:10 - OpenSAF 5.0.M0 - 4543:1eb9275e08ad:default 2016-03-08 21:35:17,257 DEBUG - exec cmd 'ls /usr/local/lib/opensaf/mdstest' on SC-1 2016-03-08 21:35:17,785 INFO - Stack trace of core.1457468950.mdstest.1477.SC-1 [New LWP 1487] [New LWP 1485] [New LWP 1477] [New LWP 1484] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `mdstest 11 1'. Program terminated with signal SIGABRT, Aborted. 2016-03-08 21:29:10,746 DEBUG - *** FAILED in suite-11, test-1,command: "mdstest 11 1" return_code-134 2016-03-08 21:29:10,746 DEBUG - Output: Suite 11: Send Responce Ack test cases /ntet_initialise_setup: Get an ADEST handle,Create PWE=2 on ADEST,Install EXTMIN and INTMIN svc on ADEST,Install INTMIN, EXTMIN services on ADEST's PWE=2, Create VDEST 100 and VDEST 200,Change the role of VDEST 200 to ACTIVE, Install EXTMIN service on VDEST 100,Install INTMIN, EXTMIN services on VDEST 200 ADEST <2010f05c5 > : GET_HDLS is SUCCESSFUL 100 : VDEST_CREATE is SUCCESSFUL 200 : VDEST_CREATE is SUCCESSFUL VDEST_CHANGE ROLE to 1 is SUCCESSFULL PWE_CREATE is SUCCESSFUL : PWE = 2 256 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL 256 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL 256 : SERVICE INSTALL is SUCCESSFULL 512 : SERVICE INSTALL is SUCCESSFULL Test Case 1: Svc EXTMIN on ADEST sends a LOW Priority message to Svc EXTMIN on VDEST=200 and expects a Response MDS SERVICE SUBSCRIBE is SUCCESSFULL MDS RETRIEVE is SUCCESSFULLTask has been Created The service which is sending the message is = 512 The service to which the message needs to be delivered = 512 Inside Receiver Thread The Sender service = 512 is on destination =<2010f05c5> with anchor = <2010f05c5> Node 2010f and msg fmt ver = 1 The Receiver service = 512 is on destination =<2010f05c5> Received Message len = 30 The message is= Hi Receiver! Are you there? MDS RETRIEVE is SUCCESSFULL The service which is sending the message is = 512 The service to which the message needs to be delivered = 512 MDS SEND RESPONSE is SUCCESSFULL The response got from the receiver is : message length = 41 message = Yes Sender! I am in. Message Delivered? Success TASK is released MDS CANCEL SUBSCRIBE is SUCCESSFULLUninstalling the services on both VDESTs and ADEST UnInstalling the Services on both the VDESTs MDS RETRIEVE is SUCCESSFULL 512 : SERVICE UNINSTALL is SUCCESSFULL MDS RETRIEVE is SUCCESSFULL 256 : SERVICE UNINSTALL is SUCCESSFULL MDS RETRIEVE is
[tickets] [opensaf:tickets] #2205 imm: IMMND crashes when receiving D2ND_ABORT_CCB
- Attachments has changed: Diff: --- old +++ new @@ -1 +0,0 @@ -osafNode.immnd.bz2 (18.9 MB; application/octet-stream) --- ** [tickets:#2205] imm: IMMND crashes when receiving D2ND_ABORT_CCB** **Status:** fixed **Milestone:** 5.0.2 **Created:** Thu Nov 24, 2016 07:23 AM UTC by Hung Nguyen **Last Updated:** Wed Nov 30, 2016 03:46 AM UTC **Owner:** Hung Nguyen ~~~ Nov 16 10:06:17 SC-2-1 osafimmnd[5608]: ../../../../../../../opensaf/osaf/services/saf/immsv/immnd/ImmModel.cc:6169: ccbAbort: Assertion '*nodeId == ccb->mAugCcbParent->mOriginatingNode' failed. ~~~ ~~~ Nov 16 10:06:17.260296 osafimmnd [5608:immsv_evt.c:5473] T8 Received: IMMND_EVT_A2ND_OI_CCB_AUG_INIT (91) from 0 Nov 16 10:06:17.260303 osafimmnd [5608:immnd_evt.c:10304] >> immnd_evt_ccb_augment_init Nov 16 10:06:17.260310 osafimmnd [5608:ImmModel.cc:6502] >> ccbAugmentInit Nov 16 10:06:17.260323 osafimmnd [5608:ImmModel.cc:6555] TR Augment CCB in state MODIFY_OP Nov 16 10:06:17.260329 osafimmnd [5608:ImmModel.cc:6592] TR omuti->second:0x14051f0 Nov 16 10:06:17.260359 osafimmnd [5608:ImmModel.cc:6593] TR omuti->second->mContinuationId:24 == rsp->inv:24 Nov 16 10:06:17.260366 osafimmnd [5608:ImmModel.cc:6600] TR obj:0x1405460 Nov 16 10:06:17.260371 osafimmnd [5608:ImmModel.cc:6658] << ccbAugmentInit Nov 16 10:06:17.261479 osafimmnd [5608:immsv_evt.c:5473] T8 Received: IMMND_EVT_D2ND_ABORT_CCB (62) from 0 Nov 16 10:06:17.261486 osafimmnd [5608:immnd_evt.c:7684] >> immnd_evt_proc_ccb_finalize Nov 16 10:06:17.261490 osafimmnd [5608:immnd_evt.c:6921] >> immnd_evt_ccb_abort Nov 16 10:06:17.261495 osafimmnd [5608:immnd_evt.c:6925] TR We expect there to be a PBE Nov 16 10:06:17.261501 osafimmnd [5608:ImmModel.cc:6079] >> ccbAbort Nov 16 10:06:17.261506 osafimmnd [5608:ImmModel.cc:6088] T5 ABORT CCB 79 Nov 16 10:06:17.261539 osafimmnd [5608:ImmModel.cc:6151] NO Ccb 79 ABORTED (immcfg_SC-2-1_9735) ~~~ When IMMND received A2ND_OI_CCB_AUG_INIT the ccbstate was changed to CCB_READY. Then when D2ND_ABORT_CCB message came, in ImmModel::ccbAbort() \*nodeId is not updated and later it failed to assert ~~~ osafassert(*nodeId == ccb->mAugCcbParent->mOriginatingNode); ~~~ Attached is IMMND traces. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1820 imm: Veteran IMMND crashes when verifying dying adm owner
- Attachments has changed: Diff: --- old +++ new @@ -1 +0,0 @@ -logs_n_bt.tgz (23.4 MB; application/x-compressed) --- ** [tickets:#1820] imm: Veteran IMMND crashes when verifying dying adm owner** **Status:** fixed **Milestone:** 4.7.2 **Created:** Tue May 10, 2016 11:20 AM UTC by Hung Nguyen **Last Updated:** Fri May 13, 2016 04:32 PM UTC **Owner:** Hung Nguyen A2ND_SYNC_FINALIZE is sent directly from sync process to coord IMMND. ADMO_HARD_FINALIZE is broadcasted to all IMMND over fevs. There's a chance that the coord receives admo-hard-finalize message after generating the sync-finalize message while the veterans receive admo-hard-finalize message before sync-finalize message. That results in some admo are marked as dying on veteran IMMND but not in coord. ~~~ 02:23:52 SC-1 osafimmnd[16257]: WA Postponing hard delete of admin owner with id:154 when imm is not writable state 02:23:52 SC-1 osafimmnd[16257]: ER Sync-verify: Established node has different isDying flag (1) for AdminOwner LDE, should be 0. 02:23:52 PL-3 osafimmnd[24743]: WA Postponing hard delete of admin owner with id:154 when imm is not writable state 02:23:52 PL-3 osafimmnd[24743]: ER Sync-verify: Established node has different isDying flag (1) for AdminOwner LDE, should be 0. 02:23:52 PL-5 osafimmnd[27437]: WA Postponing hard delete of admin owner with id:154 when imm is not writable state 02:23:52 PL-5 osafimmnd[27437]: ER Sync-verify: Established node has different isDying flag (1) for AdminOwner LDE, should be 0. ~~~ --- ### Reproduce: On the coord node, create a gdb script 'test.gdb' like this. Replace 'SC-2' with a veteran node. ~~~ break immnd_evt_proc_sync_finalize commands shell ssh SC-2 pkill -9 immcfg shell sleep 2 continue end continue ~~~ run gdb on coord ~~~ root@SC-1:~# gdb --command=test.gdb /usr/local/lib/opensaf/osafimmnd `pidof osafimmnd` ~~~ On the veteran node, run immcfg in explicit commit mode and leave it there to create an admo. ~~~ root@SC-2:~# immcfg > ~~~ Now let a node join the cluster, the veteran IMMND will crash. You may need to configure opensaf with -O0 to make gdb work correctly. ./configure CFLAGS='-g -O0' CXXFLAGS='-g -O0' --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2029 imm: fevs message lost during failover
- Attachments has changed: Diff: --- old +++ new @@ -1 +0,0 @@ -logs.7z (250.9 kB; application/octet-stream) --- ** [tickets:#2029] imm: fevs message lost during failover** **Status:** fixed **Milestone:** 4.7.2 **Created:** Tue Sep 13, 2016 11:05 AM UTC by Hung Nguyen **Last Updated:** Thu Sep 22, 2016 12:03 PM UTC **Owner:** Hung Nguyen There's fevs message loss when failing over between 2 SCs. ~~~ Sep 8 11:50:00 SC-2-1 osafimmnd[4241]: NO Implementer locally disconnected. Marking it as doomed 232 <754, 2010f> (@OpenSafImmPBE) Sep 8 11:50:00 SC-2-1 osafimmnd[4241]: NO Implementer locally disconnected. Marking it as doomed 233 <755, 2010f> (OsafImmPbeRt_B) ... Sep 8 11:50:00 SC-2-1 osafimmnd[4241]: NO Implementer disconnected 233 <755, 2010f> (OsafImmPbeRt_B) ~~~ The IMMNDs never receive the D2ND_DISCARD_IMPL for @OpenSafImmPBE, so that applier keeps being mark as dying ~~~ Sep 8 11:50:02 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports missing PbeBSlave locally => unsafe Sep 8 11:50:03 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports missing PbeBSlave locally => unsafe Sep 8 11:50:04 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports missing PbeBSlave locally => unsafe ... Sep 8 11:59:08 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports missing PbeBSlave locally => unsafe Sep 8 11:59:09 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports missing PbeBSlave locally => unsafe Sep 8 11:59:10 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports missing PbeBSlave locally => unsafe ... ~~~ The main problem is the standby IMMD also broadcast D2ND_DISCARD_NODE message when it receives an NCSMDS_DOWN from IMMND. See immd_process_immnd_down(). If the NCSMDS_DOWN event comes to the 2 IMMDs at the same time, the 2 D2ND_DISCARD_NODE messages will be stamped with the same number. One of the 2 will be discarded by IMMNDs, no problem here. But if there's a latency of NCSMDS_DOWN event, an other fevs message (in this case it's D2ND_DISCARD_IMPL for @OpenSafImmPBE) will be discarded by IMMNDs, that will cause fevs message loss. Details of the problem is explained here http://sequencediagram.org/index.html?initialData=A4QwTgLglgxloDsIAICSBZdARAjACgGUAVAIQEoAoUSWeEJNTLAJjwEEBhIy66ORFBnQA5LAGcKFMACMA9gA9ksgG4BTMI2z5i5ADRCW7LmQBcMAK5gwqhgDNVysQRsATDrPNITyHAAYALADMAGySMgpKahpComImMVhKCMgEHMzIUGLILrIA7ghhcooq6pq4hKSmwhwE2AQA+lgA8gDqwsgONhCSkgbalQC0AMTWLgB8CXEsoo2oqWwASlj1wk1YAKLIYhAgALbAqi7IuVAQABY+AYEA7L1MrJzcADxD0gA25qoDkyaizMtYOYcRbLDAABQAMshbLINAABJoHBAEEC2VC7XZgkjrQoRErRe5GbgmeyOZwINweBiZZAIWQoczAFwgCCHZAQWQAc1U51KJ3OZRwAB0ECKxLIMihtntgFlechdqoxGIQNzjqcLn4grcKAYHsZhqMJphYiZpgCgSD6uCodL9mz+Zqrjq+hVyC9OdYbN9CY9TOgSBwxMoFUqVWqYRotTdccUooK3aYwWAoAwPCh5blwAhU5yRSKWmxkOgw6rVMgYFSICZo9dkABqHzIACEAF5LtqeuE46UfkQzuXJtlMjBwEdzbN5ktrehIaHlWX8whpKpR+YxOXZLZsoy3rAWWzSVkEOZdiuwEv+yyAORZXJnACeyARSJRaIxWM2NLpKFs5jebxPi4I5jocsaRL2vrGL8NR1I0rTtJ0SCXmcNJISglaKnKEp6sgbwHho5z0IKQA ~~~ Sep 8 11:50:00 SC-2-1 osafimmd[4226]: WA IMMND DOWN on active controller 2 detected at standby immd!! 1. Possible failover ... Sep 8 11:50:00 SC-2-1 osafimmd[4226]: WA Message count:10437 + 1 != 10437 Sep 8 11:50:00 SC-2-1 osafimmnd[4241]: WA DISCARD DUPLICATE FEVS message:10437 Sep 8 11:50:00 SC-2-1 osafimmnd[4241]: WA Error code 2 returned for message type 82 - ignoring ~~~ 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3053 imm: not respawned when immnd terminated during start up
https://sourceforge.net/p/opensaf/mailman/message/36698160/ --- ** [tickets:#3053] imm: not respawned when immnd terminated during start up ** **Status:** review **Milestone:** 5.19.06 **Created:** Tue Jun 18, 2019 11:43 PM UTC by Thang Duc Nguyen **Last Updated:** Mon Jun 24, 2019 02:57 AM UTC **Owner:** Thang Duc Nguyen During SC-1 is going up, SCC-2 was down. And immnd on SC-1 was terminated (e.i, exit(0)) but before exiting, it does not send respond error to nid to respawn. 2019-06-18 13:38:20.637 SC-1 opensafd: Starting OpenSAF Services(5.19.06 - 9d64c986706f31ef15d40faffc1cfbed61d6217b) (Using TIPC) 2019-06-18 13:38:20.643 SC-1 opensafd[111]: /etc/init.d/opensafd: 121: /etc/init.d/opensafd: cannot create /proc/sys/kernel/core_pattern: Read-only file system 2019-06-18 13:38:20.657 SC-1 opensafd: Reboot file /var/log/opensaf/clm_cluster_reboot_in_progress not found, startup continue... 2019-06-18 13:38:20.659 SC-1 opensafd[144]: logtrace: trace enabled to file 'opensafd.log', mask=0x0 2019-06-18 13:38:20.764 SC-1 opensafd[144]: NO svc_monitor_thread is up and in ready state 2019-06-18 13:38:20.933 SC-1 opensaf: TIPC node address not yet configured , Configuring... 2019-06-18 13:38:21.010 SC-1 osaftransportd[176]: Started 2019-06-18 13:38:21.070 SC-1 osafclmna[182]: Started 2019-06-18 13:38:21.113 SC-1 opensafd[144]: NO Monitoring of TRANSPORT started 2019-06-18 13:38:21.115 SC-1 opensafd[144]: NO Monitoring of CLMNA started 2019-06-18 13:38:21.286 SC-1 osafrded[191]: Started 2019-06-18 13:38:21.288 SC-1 osafclmna[182]: NO Starting to promote this node to a system controller 2019-06-18 13:38:21.333 SC-1 opensafd[144]: NO Monitoring of RDE started 2019-06-18 13:38:21.429 SC-1 osafclmna[182]: NO safNode=SC-1,safCluster=myClmCluster Joined cluster, nodeid=2010f 2019-06-18 13:38:21.512 SC-1 osaffmd[200]: Started 2019-06-18 13:38:21.521 SC-1 osaffmd[200]: NO Configuration file located at /etc/opensaf/fmd.conf 2019-06-18 13:38:21.536 SC-1 opensafd[144]: NO Monitoring of HLFM started 2019-06-18 13:38:21.588 SC-1 osafimmd[210]: Started 2019-06-18 13:38:21.591 SC-1 opensafd[144]: NO Monitoring of IMMD started 2019-06-18 13:38:21.592 SC-1 osafimmd[210]: NO *** SC_ABSENCE_ALLOWED (Headless Hydra) is configured: 900 *** 2019-06-18 13:38:21.659 SC-1 osafimmnd[221]: Started 2019-06-18 13:38:21.667 SC-1 osafimmnd[221]: NO Use default reserved class names. 2019-06-18 13:38:21.667 SC-1 osafimmnd[221]: NO Persistent Back-End capability configured, Pbe file:imm.db (suffix may get added) 2019-06-18 13:38:21.682 SC-1 osafimmnd[221]: NO IMMD service is UP ... ScAbsenseAllowed?:0 introduced?:0 2019-06-18 13:38:21.683 SC-1 osafimmnd[221]: NO SERVER STATE: IMM_SERVER_ANONYMOUS --> IMM_SERVER_CLUSTER_WAITING 2019-06-18 13:38:21.696 SC-1 osafimmnd[221]: NO Fevs count adjusted to 1241 preLoadPid: 0 2019-06-18 13:38:21.788 SC-1 osafimmnd[221]: NO SERVER STATE: IMM_SERVER_CLUSTER_WAITING --> IMM_SERVER_LOADING_PENDING 2019-06-18 13:38:21.844 SC-1 osafimmnd[221]: WA SC Absence IS allowed:900 IMMD service is DOWN 2019-06-18 13:38:21.848 SC-1 osafimmnd[221]: NO IMMD SERVICE IS DOWN, HYDRA IS CONFIGURED => UNREGISTERING IMMND form MDS 2019-06-18 13:38:21.861 SC-1 osafimmnd[221]: NO SC abscence interrupted sync of this IMMND - 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3043 imm: non-local user cannot access IMM when accessControlMode is in ENFORCED
- **assigned_to**: Vu Minh Nguyen --- ** [tickets:#3043] imm: non-local user cannot access IMM when accessControlMode is in ENFORCED** **Status:** unassigned **Milestone:** 5.19.06 **Created:** Wed May 22, 2019 08:20 AM UTC by Vu Minh Nguyen **Last Updated:** Wed May 22, 2019 08:24 AM UTC **Owner:** Vu Minh Nguyen Users that are remote to the system but can log in to the system such as users in external databases like NIS or LDAP are not able to access IMM when accessControlMode is in ENFORCED. The information of these users does not exist in /etc/passwd or /etc/group. Looking at syslog, IMM gets correct uid but claims 'user id does not exist'. However, when restarting the IMMND, IMM is able to find user information for such user uid, but can't fetch groups that belong to the non-local user. testme@SC-1:~> id uid=702(testme) gid=325(system-test) groups=325(system-test),315(imm-users),316(test-users) > Apr 30 13:30:37 SC-1 osafimmnd[14419]: WA osaf_user_is_member_of_group: user > id 702 does not exist > Apr 30 13:30:37 SC-1: NOTICE: immlist -t 3600 > opensafImm=opensafImm,safApp=safImmService returned error - saImmOmInitialize > FAILED: SA_AIS_ERR_ACCESS_DENIED (38) --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3043 imm: non-local user cannot access IMM when accessControlMode is in ENFORCED
- Description has changed: Diff: --- old +++ new @@ -6,4 +6,4 @@ uid=702(testme) gid=325(system-test) groups=325(system-test),315(imm-users),316(test-users) > Apr 30 13:30:37 SC-1 osafimmnd[14419]: WA osaf_user_is_member_of_group: user > id 702 does not exist -> Apr 30 13:30:37 SC-1 CMW: NOTICE: immlist -t 3600 opensafImm=opensafImm,safApp=safImmService returned error - saImmOmInitialize FAILED: SA_AIS_ERR_ACCESS_DENIED (38) +> Apr 30 13:30:37 SC-1: NOTICE: immlist -t 3600 opensafImm=opensafImm,safApp=safImmService returned error - saImmOmInitialize FAILED: SA_AIS_ERR_ACCESS_DENIED (38) --- ** [tickets:#3043] imm: non-local user cannot access IMM when accessControlMode is in ENFORCED** **Status:** unassigned **Milestone:** 5.19.06 **Created:** Wed May 22, 2019 08:20 AM UTC by Vu Minh Nguyen **Last Updated:** Wed May 22, 2019 08:23 AM UTC **Owner:** nobody Users that are remote to the system but can log in to the system such as users in external databases like NIS or LDAP are not able to access IMM when accessControlMode is in ENFORCED. The information of these users does not exist in /etc/passwd or /etc/group. Looking at syslog, IMM gets correct uid but claims 'user id does not exist'. However, when restarting the IMMND, IMM is able to find user information for such user uid, but can't fetch groups that belong to the non-local user. testme@SC-1:~> id uid=702(testme) gid=325(system-test) groups=325(system-test),315(imm-users),316(test-users) > Apr 30 13:30:37 SC-1 osafimmnd[14419]: WA osaf_user_is_member_of_group: user > id 702 does not exist > Apr 30 13:30:37 SC-1: NOTICE: immlist -t 3600 > opensafImm=opensafImm,safApp=safImmService returned error - saImmOmInitialize > FAILED: SA_AIS_ERR_ACCESS_DENIED (38) --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3043 imm: non-local user cannot access IMM when accessControlMode is in ENFORCED
- Description has changed: Diff: --- old +++ new @@ -1,4 +1,4 @@ -Users that are remote to the system but can log in to the system such as users in external databases like NIS or LDAP is not able to access IMM when accessControlMode is in ENFORCED. The information of these users does not exist in /etc/passwd or /etc/group. +Users that are remote to the system but can log in to the system such as users in external databases like NIS or LDAP are not able to access IMM when accessControlMode is in ENFORCED. The information of these users does not exist in /etc/passwd or /etc/group. Looking at syslog, IMM gets correct uid but claims 'user id does not exist'. However, when restarting the IMMND, IMM is able to find user information for such user uid, but can't fetch groups that belong to the non-local user. --- ** [tickets:#3043] imm: non-local user cannot access IMM when accessControlMode is in ENFORCED** **Status:** unassigned **Milestone:** 5.19.06 **Created:** Wed May 22, 2019 08:20 AM UTC by Vu Minh Nguyen **Last Updated:** Wed May 22, 2019 08:22 AM UTC **Owner:** nobody Users that are remote to the system but can log in to the system such as users in external databases like NIS or LDAP are not able to access IMM when accessControlMode is in ENFORCED. The information of these users does not exist in /etc/passwd or /etc/group. Looking at syslog, IMM gets correct uid but claims 'user id does not exist'. However, when restarting the IMMND, IMM is able to find user information for such user uid, but can't fetch groups that belong to the non-local user. testme@SC-1:~> id uid=702(testme) gid=325(system-test) groups=325(system-test),315(imm-users),316(test-users) > Apr 30 13:30:37 SC-1 osafimmnd[14419]: WA osaf_user_is_member_of_group: user > id 702 does not exist > Apr 30 13:30:37 SC-1 CMW: NOTICE: immlist -t 3600 > opensafImm=opensafImm,safApp=safImmService returned error - saImmOmInitialize > FAILED: SA_AIS_ERR_ACCESS_DENIED (38) --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3043 imm: non-local user cannot access IMM when accessControlMode is in ENFORCED
--- ** [tickets:#3043] imm: non-local user cannot access IMM when accessControlMode is in ENFORCED** **Status:** unassigned **Milestone:** 5.19.06 **Created:** Wed May 22, 2019 08:20 AM UTC by Vu Minh Nguyen **Last Updated:** Wed May 22, 2019 08:20 AM UTC **Owner:** nobody Users that are remote to the system but can log in to the system such as users in external databases like NIS or LDAP is not able to access IMM when accessControlMode is in ENFORCED. The information of these users does not exist in /etc/passwd or /etc/group. Looking at syslog, IMM gets correct uid but claims 'user id does not exist'. However, when restarting the IMMND, IMM is able to find user information for such user uid, but can't fetch this non-local user groups. testme@SC-1:~> id uid=702(testme) gid=325(system-test) groups=325(system-test),315(imm-users),316(test-users) > Apr 30 13:30:37 SC-1 osafimmnd[14419]: WA osaf_user_is_member_of_group: user > id 702 does not exist > Apr 30 13:30:37 SC-1 CMW: NOTICE: immlist -t 3600 > opensafImm=opensafImm,safApp=safImmService returned error - saImmOmInitialize > FAILED: SA_AIS_ERR_ACCESS_DENIED (38) --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3024 imm: update PR documentation
- **status**: review --> fixed - **Comment**: changeset: 241:dfceaff7b286 tag: tip user: Vu Minh Nguyen date:Thu May 16 16:59:40 2019 +0700 summary: imm: return try-again on write requests if fs is unavailable [#3024] --- ** [tickets:#3024] imm: update PR documentation** **Status:** fixed **Milestone:** 5.19.06 **Created:** Tue Mar 26, 2019 06:31 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Apr 22, 2019 06:43 AM UTC **Owner:** Vu Minh Nguyen PR documentation should be updated as result of the ticket [#3019] - return try again on write requests while file system is unavailable. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3033 mds: order is not guaranteed if broadcasting a large package
- **status**: review --> fixed - **Comment**: commit d07d6f3363fae78d579bbb37366cc5b814d35f0b (HEAD -> develop, origin/develop) Author: thuan.tran Date: Wed Apr 24 11:31:29 2019 +0700 mds: use TIPC multicast for fragmented messages [#3033] - Sender may send broadcast big messages (> 65K) then small messages (< 65K). Current MDS just loop via all destinations to unicast all fragmented messages to one by one destinations. But sending multicast non-fragment messages to all destinations. Therefore, receivers may get messages with incorrect order, non-fragment messages may come before fragmented messages. For example, it may lead to OUT OF ORDER for IMMNDs during IMMD sync. - Solution: use TIPC multicast instead of unicast for each fragmented messages to avoid disorder of arrived broadcast messages. --- ** [tickets:#3033] mds: order is not guaranteed if broadcasting a large package** **Status:** fixed **Milestone:** 5.19.06 **Created:** Mon Apr 22, 2019 03:18 AM UTC by Vu Minh Nguyen **Last Updated:** Fri Apr 26, 2019 08:50 AM UTC **Owner:** Thuan When *broadcasting a large package* which is over maximum of MDS direct buffer size ( ~ 65K bytes) to list of receivers, the package will be fragmented into smaller chunks at MDS layer, and then *unicast* each of them to a specific receiver; that process is repeated over the receiver list. And if user broadcasts another smaller package which does not require to be fragmented after that big one, there is possibility the smaller package will arrive at destinations before the previous large one as those are transmitted in 02 different channels, unicast and broadcast; the transport layer (e.g. tipc) does not guarantee the order in such case. More details: At MDS user, do: 1) broadcast a large msg1. 2) broadcast a smaller msg2 Then, at MDS layer: with msg1: ~~~ loop: Iterate over destinations having same svd-id msg1 is fragmented into smaller ones. e.g: msg1 = msg11 + msg12 + msg13 tipc unicast msg11 to a destination tipc unicast msg12 to a destination tipc unicast msg13 to an destination end loop ~~~ with msg2: `tipc mcast msg2 to all destination having same svd-id in one go.` as msg1x fragments are transfered with unicast type that is different from msg2 transfered with mcast type, there is chance that msg2 may arrive at desinations sooner than msg1. The patch of this ticket basically does: with msg1: ~~~ msg1 is fragmented into smaller ones. e.g: msg1 = msg11 + msg12 + msg13 tipc mcast msg11 to all adest in one go tipc mcast msg12 to all adest in one go tipc mcast msg13 to all adest in go go ~~~ with msg2: `tipc mcast msg2 to all destination having same svd-id in one go.` With that, all messages including fragmented are transfered with the same mcast type, therefore the message order msg2->msg13->msg12->msg1 (later->sooner) is guaranteed at receiver sides. To reproduce the issue, continuously broadcasting a small package after the large one in a large cluster. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3033 mds: order is not guaranteed if broadcasting a large package
- Description has changed: Diff: --- old +++ new @@ -2,4 +2,42 @@ And if user broadcasts another smaller package which does not require to be fragmented after that big one, there is possibility the smaller package will arrive at destinations before the previous large one as those are transmitted in 02 different channels, unicast and broadcast; the transport layer (e.g. tipc) does not guarantee the order in such case. +More details: + +At MDS user, do: +1) broadcast a large msg1. +2) broadcast a smaller msg2 + +Then, at MDS layer: +with msg1: +~~~ +loop: Iterate over destinations having same svd-id + msg1 is fragmented into smaller ones. e.g: msg1 = msg11 + msg12 + msg13 + tipc unicast msg11 to a destination + tipc unicast msg12 to a destination + tipc unicast msg13 to an destination +end loop +~~~ + +with msg2: +`tipc mcast msg2 to all destination having same svd-id in one go.` + +as msg1x fragments are transfered with unicast type that is different from msg2 transfered with mcast type, there is chance that msg2 may arrive at desinations sooner than msg1. + +The patch of this ticket basically does: + +with msg1: +~~~ +msg1 is fragmented into smaller ones. e.g: msg1 = msg11 + msg12 + msg13 +tipc mcast msg11 to all adest in one go +tipc mcast msg12 to all adest in one go +tipc mcast msg13 to all adest in go go +~~~ + +with msg2: +`tipc mcast msg2 to all destination having same svd-id in one go.` + +With that, all messages including fragmented are transfered with the same mcast type, +therefore the message order msg2->msg13->msg12->msg1 (later->sooner) is guaranteed at receiver sides. + To reproduce the issue, continuously broadcasting a small package after the large one in a large cluster. --- ** [tickets:#3033] mds: order is not guaranteed if broadcasting a large package** **Status:** review **Milestone:** 5.19.06 **Created:** Mon Apr 22, 2019 03:18 AM UTC by Vu Minh Nguyen **Last Updated:** Wed Apr 24, 2019 07:19 AM UTC **Owner:** Thuan When *broadcasting a large package* which is over maximum of MDS direct buffer size ( ~ 65K bytes) to list of receivers, the package will be fragmented into smaller chunks at MDS layer, and then *unicast* each of them to a specific receiver; that process is repeated over the receiver list. And if user broadcasts another smaller package which does not require to be fragmented after that big one, there is possibility the smaller package will arrive at destinations before the previous large one as those are transmitted in 02 different channels, unicast and broadcast; the transport layer (e.g. tipc) does not guarantee the order in such case. More details: At MDS user, do: 1) broadcast a large msg1. 2) broadcast a smaller msg2 Then, at MDS layer: with msg1: ~~~ loop: Iterate over destinations having same svd-id msg1 is fragmented into smaller ones. e.g: msg1 = msg11 + msg12 + msg13 tipc unicast msg11 to a destination tipc unicast msg12 to a destination tipc unicast msg13 to an destination end loop ~~~ with msg2: `tipc mcast msg2 to all destination having same svd-id in one go.` as msg1x fragments are transfered with unicast type that is different from msg2 transfered with mcast type, there is chance that msg2 may arrive at desinations sooner than msg1. The patch of this ticket basically does: with msg1: ~~~ msg1 is fragmented into smaller ones. e.g: msg1 = msg11 + msg12 + msg13 tipc mcast msg11 to all adest in one go tipc mcast msg12 to all adest in one go tipc mcast msg13 to all adest in go go ~~~ with msg2: `tipc mcast msg2 to all destination having same svd-id in one go.` With that, all messages including fragmented are transfered with the same mcast type, therefore the message order msg2->msg13->msg12->msg1 (later->sooner) is guaranteed at receiver sides. To reproduce the issue, continuously broadcasting a small package after the large one in a large cluster. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3033 mds: order is not guaranteed if broadcasting a large package
- **status**: unassigned --> accepted - **assigned_to**: Thuan --- ** [tickets:#3033] mds: order is not guaranteed if broadcasting a large package** **Status:** accepted **Milestone:** 5.19.06 **Created:** Mon Apr 22, 2019 03:18 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Apr 22, 2019 03:18 AM UTC **Owner:** Thuan When *broadcasting a large package* which is over maximum of MDS direct buffer size ( ~ 65K bytes) to list of receivers, the package will be fragmented into smaller chunks at MDS layer, and then *unicast* each of them to a specific receiver; that process is repeated over the receiver list. And if user broadcasts another smaller package which does not require to be fragmented after that big one, there is possibility the smaller package will arrive at destinations before the previous large one as those are transmitted in 02 different channels, unicast and broadcast; the transport layer (e.g. tipc) does not guarantee the order in such case. To reproduce the issue, continuously broadcasting a small package after the large one in a large cluster. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3024 imm: update PR documentation
- **status**: assigned --> review --- ** [tickets:#3024] imm: update PR documentation** **Status:** review **Milestone:** 5.19.06 **Created:** Tue Mar 26, 2019 06:31 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Mar 26, 2019 06:31 AM UTC **Owner:** Vu Minh Nguyen PR documentation should be updated as result of the ticket [#3019] - return try again on write requests while file system is unavailable. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3033 mds: order is not guaranteed if broadcasting a large package
--- ** [tickets:#3033] mds: order is not guaranteed if broadcasting a large package** **Status:** unassigned **Milestone:** 5.19.06 **Created:** Mon Apr 22, 2019 03:18 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Apr 22, 2019 03:18 AM UTC **Owner:** nobody When *broadcasting a large package* which is over maximum of MDS direct buffer size ( ~ 65K bytes) to list of receivers, the package will be fragmented into smaller chunks at MDS layer, and then *unicast* each of them to a specific receiver; that process is repeated over the receiver list. And if user broadcasts another smaller package which does not require to be fragmented after that big one, there is possibility the smaller package will arrive at destinations before the previous large one as those are transmitted in 02 different channels, unicast and broadcast; the transport layer (e.g. tipc) does not guarantee the order in such case. To reproduce the issue, continuously broadcasting a small package after the large one in a large cluster. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3030 imm: coredump on immnd during upgrade
- **status**: review --> fixed - **assigned_to**: Vu Minh Nguyen --> nobody - **Comment**: commit 2847150c3964922e86b5929ff5f5862d74e7075d (HEAD -> develop, origin/develop) Author: Vu Minh Nguyen Date: Fri Apr 19 09:21:43 2019 +0700 imm: fix coredump on immnd during upgrade [#3030] The assertion about the existence of the new added attribute `saImmFileSystemStatus` should be done if the admOp ID is either 400 or 401. Also correct the value of OPENSAF_IMM_FLAG_PRT51906_ALLOW which presents the bitmask index for the new protocol. The index should be 11, and therefore the value is 0x0400. --- ** [tickets:#3030] imm: coredump on immnd during upgrade** **Status:** fixed **Milestone:** 5.19.06 **Created:** Tue Apr 16, 2019 07:32 AM UTC by Vu Minh Nguyen **Last Updated:** Wed Apr 17, 2019 09:40 AM UTC **Owner:** nobody Here is the syslog: > > Apr 16 17:00:32 SC-2-1 osafimmnd[5051]: src/imm/immnd/ImmModel.cc:13876: > > admoImmMngtObject: Assertion 'fs_attr_iter != > > immObject->mAttrValueMap.end()' failed. > Apr 16 17:00:32 SC-2-1 opensafd[4957]: ER Service IMMND has unexpectedly > crashed. Unable to continue, exiting The bug was introduced by the ticket [#3019]. The assertion about existing of `saImmFileSystemStatus` should be checked in case the adminOp is either 400/401. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3030 imm: coredump on immnd during upgrade
- **status**: accepted --> review - **Comment**: https://sourceforge.net/p/opensaf/mailman/message/36642300/ --- ** [tickets:#3030] imm: coredump on immnd during upgrade** **Status:** review **Milestone:** 5.19.06 **Created:** Tue Apr 16, 2019 07:32 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Apr 16, 2019 07:32 AM UTC **Owner:** Vu Minh Nguyen Here is the syslog: > > Apr 16 17:00:32 SC-2-1 osafimmnd[5051]: src/imm/immnd/ImmModel.cc:13876: > > admoImmMngtObject: Assertion 'fs_attr_iter != > > immObject->mAttrValueMap.end()' failed. > Apr 16 17:00:32 SC-2-1 opensafd[4957]: ER Service IMMND has unexpectedly > crashed. Unable to continue, exiting The bug was introduced by the ticket [#3019]. The assertion about existing of `saImmFileSystemStatus` should be checked in case the adminOp is either 400/401. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3030 imm: coredump on immnd during upgrade
--- ** [tickets:#3030] imm: coredump on immnd during upgrade** **Status:** accepted **Milestone:** 5.19.06 **Created:** Tue Apr 16, 2019 07:32 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Apr 16, 2019 07:32 AM UTC **Owner:** Vu Minh Nguyen Here is the syslog: > > Apr 16 17:00:32 SC-2-1 osafimmnd[5051]: src/imm/immnd/ImmModel.cc:13876: > > admoImmMngtObject: Assertion 'fs_attr_iter != > > immObject->mAttrValueMap.end()' failed. > Apr 16 17:00:32 SC-2-1 opensafd[4957]: ER Service IMMND has unexpectedly > crashed. Unable to continue, exiting The bug was introduced by the ticket [#3019]. The assertion about existing of `saImmFileSystemStatus` should be checked in case the adminOp is either 400/401. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3019 imm: return try-again on write requests if FS is unresponsive
- **summary**: imm: return try-again on write requests when FS is unresponsive --> imm: return try-again on write requests if FS is unresponsive - **status**: review --> fixed - **assigned_to**: Vu Minh Nguyen --> nobody - **Comment**: commit ecbdd454813cb2e5994143aa202535374d119392 (HEAD -> develop, origin/develop, ticket-3019) Author: Vu Minh Nguyen Date: Thu Apr 11 15:13:50 2019 +0700 imm: return try-again on write requests if fs is unavailable [#3019] When underlying file system is unresponsive to pbe write request, all IMM write requests that need their changes to be persistent such as apply of ccb or updates to persistent runtime attributes or creation/deletion of classes or creation/deletion of persistent runtime objects likely gets SA_AIS_ERR_TIMEOUT. This patch introduces two administrative operations to let user inform IMM about the availibity of the file system. If the server (IMMND) detects the logical unavailability of the file system through this variable, such write requets will get the honest code SA_AIS_ERR_TRY_AGAIN rather then SA_AIS_ERR_TIMEOUT. Besides, a new IMM attribute, saImmFileSystemStatus, is added to SaImmMngt class; the value shows the current status of the file system according to IMM view --- ** [tickets:#3019] imm: return try-again on write requests if FS is unresponsive** **Status:** fixed **Milestone:** 5.19.06 **Created:** Mon Mar 18, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Mar 26, 2019 06:20 AM UTC **Owner:** nobody With current design, when the file system (FS) is neither available nor responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may be stuck at the activity of writing to sqlite3 database and therefore is not able to respond to IMM in time. With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. Besides, a runtime attribute `saImmFileSystemStatus` is added and owned by IMM to show the status of underlying file system. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3024 imm: update PR documentation
--- ** [tickets:#3024] imm: update PR documentation** **Status:** assigned **Milestone:** 5.19.06 **Created:** Tue Mar 26, 2019 06:31 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Mar 26, 2019 06:31 AM UTC **Owner:** Vu Minh Nguyen PR documentation should be updated as result of the ticket [#3019] - return try again on write requests while file system is unavailable. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3019 imm: return try-again on write requests when FS is unresponsive
- **status**: assigned --> review - **Comment**: https://sourceforge.net/p/opensaf/mailman/message/36622696/ --- ** [tickets:#3019] imm: return try-again on write requests when FS is unresponsive** **Status:** review **Milestone:** 5.19.06 **Created:** Mon Mar 18, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Mar 26, 2019 01:56 AM UTC **Owner:** Vu Minh Nguyen With current design, when the file system (FS) is neither available nor responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may be stuck at the activity of writing to sqlite3 database and therefore is not able to respond to IMM in time. With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. Besides, a runtime attribute `saImmFileSystemStatus` is added and owned by IMM to show the status of underlying file system. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3019 imm: return try-again on write requests when FS is unresponsive
- Description has changed: Diff: --- old +++ new @@ -1,4 +1,4 @@ -With current design, when the file system (FS) is neither available nor responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may be stuck at the activity of writing to sqlite3 database and therefore is not able to response to IMM in time. +With current design, when the file system (FS) is neither available nor responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may be stuck at the activity of writing to sqlite3 database and therefore is not able to respond to IMM in time. With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. --- ** [tickets:#3019] imm: return try-again on write requests when FS is unresponsive** **Status:** assigned **Milestone:** 5.19.03 **Created:** Mon Mar 18, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Mar 18, 2019 04:59 AM UTC **Owner:** Vu Minh Nguyen With current design, when the file system (FS) is neither available nor responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may be stuck at the activity of writing to sqlite3 database and therefore is not able to respond to IMM in time. With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. Besides, a runtime attribute `saImmFileSystemStatus` is added and owned by IMM to show the status of underlying file system. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3019 imm: return try-again on write requests when FS is unresponsive
- Description has changed: Diff: --- old +++ new @@ -1,4 +1,4 @@ -With current design, when the file system (FS) is either unavailable or responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may be stuck at the activity of writing to sqlite3 database and therefore is not able to response to IMM in time. +With current design, when the file system (FS) is neither available nor responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may be stuck at the activity of writing to sqlite3 database and therefore is not able to response to IMM in time. With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. --- ** [tickets:#3019] imm: return try-again on write requests when FS is unresponsive** **Status:** assigned **Milestone:** 5.19.03 **Created:** Mon Mar 18, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Mar 18, 2019 04:51 AM UTC **Owner:** Vu Minh Nguyen With current design, when the file system (FS) is neither available nor responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may be stuck at the activity of writing to sqlite3 database and therefore is not able to response to IMM in time. With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. Besides, a runtime attribute `saImmFileSystemStatus` is added and owned by IMM to show the status of underlying file system. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3019 imm: return try-again on write requests when FS is unresponsive
- **summary**: imm: return try-again on write requests when file system is unresponsive --> imm: return try-again on write requests when FS is unresponsive - Description has changed: Diff: --- old +++ new @@ -1,4 +1,4 @@ -With current design, when the file system is unavailable or not responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may stuck at the activity of writing to sqlite3 database and therefore is not able to response to IMM in time. +With current design, when the file system (FS) is either unavailable or responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may be stuck at the activity of writing to sqlite3 database and therefore is not able to response to IMM in time. With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. --- ** [tickets:#3019] imm: return try-again on write requests when FS is unresponsive** **Status:** assigned **Milestone:** 5.19.03 **Created:** Mon Mar 18, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Mar 18, 2019 04:30 AM UTC **Owner:** Vu Minh Nguyen With current design, when the file system (FS) is either unavailable or responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may be stuck at the activity of writing to sqlite3 database and therefore is not able to response to IMM in time. With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. Besides, a runtime attribute `saImmFileSystemStatus` is added and owned by IMM to show the status of underlying file system. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3019 imm: return try-again on write requests when file system is unresponsive
- **status**: unassigned --> assigned - **assigned_to**: Vu Minh Nguyen --- ** [tickets:#3019] imm: return try-again on write requests when file system is unresponsive** **Status:** assigned **Milestone:** 5.19.03 **Created:** Mon Mar 18, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Mar 18, 2019 03:58 AM UTC **Owner:** Vu Minh Nguyen With current design, when the file system is unavailable or not responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may stuck at the activity of writing to sqlite3 database and therefore is not able to response to IMM in time. With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. Besides, a runtime attribute `saImmFileSystemStatus` is added and owned by IMM to show the status of underlying file system. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3019 imm: return try-again on write requests when file system is unresponsive
- Description has changed: Diff: --- old +++ new @@ -2,4 +2,4 @@ With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. -Besides, an runtime attribute `saImmFileSystemStatus` is added and owned by IMM to show the status of underlying file system. +Besides, a runtime attribute `saImmFileSystemStatus` is added and owned by IMM to show the status of underlying file system. --- ** [tickets:#3019] imm: return try-again on write requests when file system is unresponsive** **Status:** unassigned **Milestone:** 5.19.03 **Created:** Mon Mar 18, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Mar 18, 2019 03:57 AM UTC **Owner:** nobody With current design, when the file system is unavailable or not responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may stuck at the activity of writing to sqlite3 database and therefore is not able to response to IMM in time. With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. Besides, a runtime attribute `saImmFileSystemStatus` is added and owned by IMM to show the status of underlying file system. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3019 imm: return try-again on write requests when file system is unresponsive
--- ** [tickets:#3019] imm: return try-again on write requests when file system is unresponsive** **Status:** unassigned **Milestone:** 5.19.03 **Created:** Mon Mar 18, 2019 03:57 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Mar 18, 2019 03:57 AM UTC **Owner:** nobody With current design, when the file system is unavailable or not responsive, CCB apply on IMM OM side likely get SA_AIS_ERR_TIMEOUT error code as osafpbed may stuck at the activity of writing to sqlite3 database and therefore is not able to response to IMM in time. With this ticket, we propose to introduce 02 new admin operations (set/clear) towards IMM; using these operations to inform IMM if the file system is unavailable or in healthy state. Based on that data, IMM will reject the write request earlier with error code SA_AIS_ERR_TRY_AGAIN if the file system is unavailable. Besides, an runtime attribute `saImmFileSystemStatus` is added and owned by IMM to show the status of underlying file system. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3009 dtm: Trace filename format restriction
commit 0a3f48cfaf9f443c405cfd7122904c5cbe607226 (HEAD -> develop) Author: khanh.h.dang Date: Wed Feb 20 16:11:40 2019 +0700 dtm: Allow hyphen character "-" in trace file name [#3009] Allow hyphen character when naming trace file as this satisfies ValidateLogName method rule. --- ** [tickets:#3009] dtm: Trace filename format restriction** **Status:** assigned **Milestone:** 5.19.03 **Created:** Wed Feb 20, 2019 07:36 AM UTC by Khanh Hoang Dang **Last Updated:** Fri Mar 08, 2019 10:01 AM UTC **Owner:** Khanh Hoang Dang "opensaf/src/dtm/transport/log_server.h" file states that method ValidateLogName will check that the string, when used as a file name, does not traverse the directory structure and file names starting with a dot are also disallowed, since they would result in hidden files. Hyphen character "-" satisfies the above conditions but it is not supported from 5.17.07. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3009 dtm: Trace filename format restriction
- **status**: assigned --> fixed --- ** [tickets:#3009] dtm: Trace filename format restriction** **Status:** fixed **Milestone:** 5.19.03 **Created:** Wed Feb 20, 2019 07:36 AM UTC by Khanh Hoang Dang **Last Updated:** Fri Mar 08, 2019 10:02 AM UTC **Owner:** Khanh Hoang Dang "opensaf/src/dtm/transport/log_server.h" file states that method ValidateLogName will check that the string, when used as a file name, does not traverse the directory structure and file names starting with a dot are also disallowed, since they would result in hidden files. Hyphen character "-" satisfies the above conditions but it is not supported from 5.17.07. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3013 nid: opensafd was crashed during start-up
- **status**: review --> fixed - **Comment**: commit a4c13cca035b90e547048ec78b6fee07f54d6566 (HEAD -> develop, origin/develop) Author: Vu Minh Nguyen Date: Wed Feb 27 17:20:42 2019 +0700 nid: fix opensafd crashed during start-up [#3013] There is a dependency b/w svc_monitor_thread and spawn_services. The coredump happens when spawn_services is executed while the thread has not yet started. In this case, data is sent to the pipe but no one consumed it. When it comes to consume the data, will get unexpected data and crash the program. This patch ensures the things will happen in the right order: svc_monitor_thread must be in ready state before spawn_services() is executed. --- ** [tickets:#3013] nid: opensafd was crashed during start-up** **Status:** fixed **Milestone:** 5.19.03 **Created:** Wed Feb 27, 2019 09:50 AM UTC by Vu Minh Nguyen **Last Updated:** Wed Feb 27, 2019 10:50 AM UTC **Owner:** Vu Minh Nguyen **Attachments:** - [bt_core.1550799866.opensafd.140.SC-1](https://sourceforge.net/p/opensaf/tickets/3013/attachment/bt_core.1550799866.opensafd.140.SC-1) (6.8 kB; application/octet-stream) opensafd was crashed during start-up since the monitor thread received a strange name whose size is over maximum length: nid_name = "CLMNARDEHLFMIMMDIMMNDLOGDNTFDC" > 2019-02-22 02:44:26.585 SC-1 osaftransportd[445]: Started > 2019-02-22 02:44:26.588 SC-1 opensafd[140]: NO Monitoring of TRANSPORT started > 2019-02-22 02:44:26.589 SC-1 opensafd[140]: src/nid/nodeinit.cc:1542: > svc_monitor_thread: Assertion 'read_rc < NID_MAXSNAME' failed. > 2019-02-22 02:44:26.608 SC-1 osafamfnd[292]: NO > 'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' Presence State INSTANTIATING => > INSTANTIATED > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2060f: > msg_id 1 > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2050f: > msg_id 1 > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2030f: > msg_id 1 > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2040f: > msg_id 1 > 2019-02-22 02:44:27.445 SC-1 osafamfnd[292]: NO Assigning > 'safSi=NoRed1,safApp=OpenSAF' ACTIVE to > 'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' > 2019-02-22 02:44:27.445 SC-1 osafamfnd[292]: NO Assigned > 'safSi=NoRed1,safApp=OpenSAF' ACTIVE to > 'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' > 2019-02-22 02:44:27.590 SC-1 opensafd[109]: Starting OpenSAF Services (Using > TIPC):Aborted (core dumped) The full backtrace is attached. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3013 nid: opensafd was crashed during start-up
syslog Attachments: - [syslog.SC-1](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/f0e648e4fd/d908/attachment/syslog.SC-1) (24.3 kB; application/octet-stream) --- ** [tickets:#3013] nid: opensafd was crashed during start-up** **Status:** assigned **Milestone:** 5.19.03 **Created:** Wed Feb 27, 2019 09:50 AM UTC by Vu Minh Nguyen **Last Updated:** Wed Feb 27, 2019 09:50 AM UTC **Owner:** Vu Minh Nguyen **Attachments:** - [bt_core.1550799866.opensafd.140.SC-1](https://sourceforge.net/p/opensaf/tickets/3013/attachment/bt_core.1550799866.opensafd.140.SC-1) (6.8 kB; application/octet-stream) opensafd was crashed during start-up since the monitor thread received a strange name whose size is over maximum length: nid_name = "CLMNARDEHLFMIMMDIMMNDLOGDNTFDC" > 2019-02-22 02:44:26.585 SC-1 osaftransportd[445]: Started > 2019-02-22 02:44:26.588 SC-1 opensafd[140]: NO Monitoring of TRANSPORT started > 2019-02-22 02:44:26.589 SC-1 opensafd[140]: src/nid/nodeinit.cc:1542: > svc_monitor_thread: Assertion 'read_rc < NID_MAXSNAME' failed. > 2019-02-22 02:44:26.608 SC-1 osafamfnd[292]: NO > 'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' Presence State INSTANTIATING => > INSTANTIATED > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2060f: > msg_id 1 > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2050f: > msg_id 1 > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2030f: > msg_id 1 > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2040f: > msg_id 1 > 2019-02-22 02:44:27.445 SC-1 osafamfnd[292]: NO Assigning > 'safSi=NoRed1,safApp=OpenSAF' ACTIVE to > 'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' > 2019-02-22 02:44:27.445 SC-1 osafamfnd[292]: NO Assigned > 'safSi=NoRed1,safApp=OpenSAF' ACTIVE to > 'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' > 2019-02-22 02:44:27.590 SC-1 opensafd[109]: Starting OpenSAF Services (Using > TIPC):Aborted (core dumped) The full backtrace is attached. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3013 nid: opensafd was crashed during start-up
--- ** [tickets:#3013] nid: opensafd was crashed during start-up** **Status:** assigned **Milestone:** 5.19.03 **Created:** Wed Feb 27, 2019 09:50 AM UTC by Vu Minh Nguyen **Last Updated:** Wed Feb 27, 2019 09:50 AM UTC **Owner:** Vu Minh Nguyen **Attachments:** - [bt_core.1550799866.opensafd.140.SC-1](https://sourceforge.net/p/opensaf/tickets/3013/attachment/bt_core.1550799866.opensafd.140.SC-1) (6.8 kB; application/octet-stream) opensafd was crashed during start-up since the monitor thread received a strange name whose size is over maximum length: nid_name = "CLMNARDEHLFMIMMDIMMNDLOGDNTFDC" > 2019-02-22 02:44:26.585 SC-1 osaftransportd[445]: Started > 2019-02-22 02:44:26.588 SC-1 opensafd[140]: NO Monitoring of TRANSPORT started > 2019-02-22 02:44:26.589 SC-1 opensafd[140]: src/nid/nodeinit.cc:1542: > svc_monitor_thread: Assertion 'read_rc < NID_MAXSNAME' failed. > 2019-02-22 02:44:26.608 SC-1 osafamfnd[292]: NO > 'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' Presence State INSTANTIATING => > INSTANTIATED > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2060f: > msg_id 1 > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2050f: > msg_id 1 > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2030f: > msg_id 1 > 2019-02-22 02:44:27.442 SC-1 osafamfd[277]: NO Received node_up from 2040f: > msg_id 1 > 2019-02-22 02:44:27.445 SC-1 osafamfnd[292]: NO Assigning > 'safSi=NoRed1,safApp=OpenSAF' ACTIVE to > 'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' > 2019-02-22 02:44:27.445 SC-1 osafamfnd[292]: NO Assigned > 'safSi=NoRed1,safApp=OpenSAF' ACTIVE to > 'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' > 2019-02-22 02:44:27.590 SC-1 opensafd[109]: Starting OpenSAF Services (Using > TIPC):Aborted (core dumped) The full backtrace is attached. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3012 imm: immnd coredump during network split
- **status**: assigned --> review - **Comment**: https://sourceforge.net/p/opensaf/mailman/message/36596309/ --- ** [tickets:#3012] imm: immnd coredump during network split** **Status:** review **Milestone:** 5.19.03 **Created:** Mon Feb 25, 2019 06:20 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Feb 25, 2019 06:20 AM UTC **Owner:** Vu Minh Nguyen **Attachments:** - [osafimmnd.15317.PL-3.core.txt](https://sourceforge.net/p/opensaf/tickets/3012/attachment/osafimmnd.15317.PL-3.core.txt) (18.8 kB; text/plain) At the time of spliting the cluster into 02 partitions but keeping a node such as PL-3 connecting with both partitions, just IMMND on PL-3 will get discard-node messages from *both* active IMMD on partition #1 and from standby IMMD on partition #2. When sync finalizing comes from the partition #1, the mismatch of IMMND database on PL-3 will be detected, then crashed. The backtrace is attached to the ticket. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3012 imm: immnd coredump during network split
--- ** [tickets:#3012] imm: immnd coredump during network split** **Status:** assigned **Milestone:** 5.19.03 **Created:** Mon Feb 25, 2019 06:20 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Feb 25, 2019 06:20 AM UTC **Owner:** Vu Minh Nguyen **Attachments:** - [osafimmnd.15317.PL-3.core.txt](https://sourceforge.net/p/opensaf/tickets/3012/attachment/osafimmnd.15317.PL-3.core.txt) (18.8 kB; text/plain) At the time of spliting the cluster into 02 partitions but keeping a node such as PL-3 connecting with both partitions, just IMMND on PL-3 will get discard-node messages from *both* active IMMD on partition #1 and from standby IMMD on partition #2. When sync finalizing comes from the partition #1, the mismatch of IMMND database on PL-3 will be detected, then crashed. The backtrace is attached to the ticket. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2991 imm: update PR documentation regarding empty value persisted
- **status**: review --> fixed - **assigned_to**: Vu Minh Nguyen --> nobody - **Comment**: changeset: 240:b2f1a3289f92 tag: tip user: Vu Minh Nguyen date:Fri Feb 15 15:27:15 2019 +0700 summary: imm: allow empty value attribute persisted [#2991] --- ** [tickets:#2991] imm: update PR documentation regarding empty value persisted** **Status:** fixed **Milestone:** 5.19.03 **Created:** Wed Jan 02, 2019 09:00 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Jan 17, 2019 02:46 AM UTC **Owner:** nobody Update IMM PR documentation regarding the enhancement which is mentioned in the ticket [#2985]. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3002 log: coredump at log agent upon application exit
- **status**: review --> fixed - **Comment**: commit 84e73242dca86ac6d4318e7351e5b45128da6101 (HEAD -> develop, origin/develop, ticket-3002) Author: Vu Minh Nguyen Date: Mon Feb 11 15:40:31 2019 +0700 log: fix coredump at log agent application [#3002] There is a race in using singleton-static class object b/w mds thread and application thread - caller of exit() api. This patch still uses singleton but making the instance shared_ptr to ensure the resource will not be destroyed if it is being used. --- ** [tickets:#3002] log: coredump at log agent upon application exit** **Status:** fixed **Milestone:** 5.19.03 **Created:** Tue Jan 22, 2019 07:06 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Jan 24, 2019 10:15 AM UTC **Owner:** Vu Minh Nguyen **Attachments:** - [loga_coredump_bt.txt](https://sourceforge.net/p/opensaf/tickets/3002/attachment/loga_coredump_bt.txt) (8.1 kB; text/plain) Log application got a coredump at the log agent code - mutex unlock failed with error code EINVAL (22). This bug is very much similar to the ticket [#2860]. See the attached full back trace. There is a singleton log agent object (LogAgent) which is declared as static and due to order of desctructor upon the program exit, the memory allocated for mutex might be destroyed before mutex unlock is called. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3001 osaf: reboot must happen more quickly during split network partition
- **status**: review --> fixed - **Comment**: commit ef3de8e98795da1869454d26627ab3bdce0bbfc9 (HEAD -> develop, origin/develop, ticket-3001) Author: Vu Minh Nguyen Date: Tue Jan 29 12:51:31 2019 +0700 osaf: do quick local node reboot when split network [#3001] --- ** [tickets:#3001] osaf: reboot must happen more quickly during split network partition** **Status:** fixed **Milestone:** 5.19.03 **Created:** Wed Jan 16, 2019 08:31 AM UTC by Gary Lee **Last Updated:** Fri Jan 25, 2019 11:34 AM UTC **Owner:** Vu Minh Nguyen Reboot must happen more quickly during a split network partition event. Currently, this is supervised with a dependency on OPENSAF_REBOOT_TIMEOUT, which could be set very high. This should be 1 or 2 seconds at most, when we can calling opensaf_reboot() during a split network partition event. The new active SC is relying on the old active to shutdown promptly, to avoid duplicate assignments. Otherwise, we may see issues if the network is merged while the old SC is still shutting down. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3001 osaf: reboot must happen more quickly during split network partition
- **status**: assigned --> review --- ** [tickets:#3001] osaf: reboot must happen more quickly during split network partition** **Status:** review **Milestone:** 5.19.03 **Created:** Wed Jan 16, 2019 08:31 AM UTC by Gary Lee **Last Updated:** Wed Jan 16, 2019 10:52 AM UTC **Owner:** Vu Minh Nguyen Reboot must happen more quickly during a split network partition event. Currently, this is supervised with a dependency on OPENSAF_REBOOT_TIMEOUT, which could be set very high. This should be 1 or 2 seconds at most, when we can calling opensaf_reboot() during a split network partition event. The new active SC is relying on the old active to shutdown promptly, to avoid duplicate assignments. Otherwise, we may see issues if the network is merged while the old SC is still shutting down. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3002 log: coredump at log agent upon application exit
- **status**: accepted --> review - Attachments has changed: Diff: --- old +++ new @@ -0,0 +1 @@ +loga_coredump_bt.txt (8.1 kB; text/plain) --- ** [tickets:#3002] log: coredump at log agent upon application exit** **Status:** review **Milestone:** 5.19.03 **Created:** Tue Jan 22, 2019 07:06 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Jan 22, 2019 07:07 AM UTC **Owner:** Vu Minh Nguyen **Attachments:** - [loga_coredump_bt.txt](https://sourceforge.net/p/opensaf/tickets/3002/attachment/loga_coredump_bt.txt) (8.1 kB; text/plain) Log application got a coredump at the log agent code - mutex unlock failed with error code EINVAL (22). This bug is very much similar to the ticket [#2860]. See the attached full back trace. There is a singleton log agent object (LogAgent) which is declared as static and due to order of desctructor upon the program exit, the memory allocated for mutex might be destroyed before mutex unlock is called. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3002 log: coredump at log agent upon application exit
- **status**: unassigned --> accepted --- ** [tickets:#3002] log: coredump at log agent upon application exit** **Status:** accepted **Milestone:** 5.19.03 **Created:** Tue Jan 22, 2019 07:06 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Jan 22, 2019 07:06 AM UTC **Owner:** Vu Minh Nguyen **Attachments:** - [loga_coredump_bt.txt](https://sourceforge.net/p/opensaf/tickets/3002/attachment/loga_coredump_bt.txt) (5.6 kB; text/plain) Log application got a coredump at the log agent code - mutex unlock failed with error code EINVAL (22). This bug is very much similar to the ticket [#2860]. See the attached full back trace. There is a singleton log agent object (LogAgent) which is declared as static and due to order of desctructor upon the program exit, the memory allocated for mutex might be destroyed before mutex unlock is called. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #3002 log: coredump at log agent upon application exit
--- ** [tickets:#3002] log: coredump at log agent upon application exit** **Status:** unassigned **Milestone:** 5.19.03 **Created:** Tue Jan 22, 2019 07:06 AM UTC by Vu Minh Nguyen **Last Updated:** Tue Jan 22, 2019 07:06 AM UTC **Owner:** Vu Minh Nguyen **Attachments:** - [loga_coredump_bt.txt](https://sourceforge.net/p/opensaf/tickets/3002/attachment/loga_coredump_bt.txt) (5.6 kB; text/plain) Log application got a coredump at the log agent code - mutex unlock failed with error code EINVAL (22). This bug is very much similar to the ticket [#2860]. See the attached full back trace. There is a singleton log agent object (LogAgent) which is declared as static and due to order of desctructor upon the program exit, the memory allocated for mutex might be destroyed before mutex unlock is called. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2991 imm: update PR documentation regarding empty value persisted
https://sourceforge.net/p/opensaf/mailman/message/36519230/ --- ** [tickets:#2991] imm: update PR documentation regarding empty value persisted** **Status:** review **Milestone:** 5.19.03 **Created:** Wed Jan 02, 2019 09:00 AM UTC by Vu Minh Nguyen **Last Updated:** Thu Jan 17, 2019 02:44 AM UTC **Owner:** Vu Minh Nguyen Update IMM PR documentation regarding the enhancement which is mentioned in the ticket [#2985]. --- 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.___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
