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

2017-02-02 Thread Gary Lee 
- **status**: review --> fixed
- **Comment**:

changeset:   8556:6b86466731ef
branch:  opensaf-5.0.x
parent:  8550:431ac44d8ee4
user:Gary Lee 
date:Fri Feb 03 10:24:30 2017 +1100
summary: base: avoid SIGPIPE in osaf_auth_server_connect()  [#2286]

changeset:   8555:ab8689bfc0ba
branch:  opensaf-5.1.x
parent:  8551:2aea0b91ae5a
user:Gary Lee 
date:Fri Feb 03 10:24:24 2017 +1100
summary: base: avoid SIGPIPE in osaf_auth_server_connect()  [#2286]

changeset:   8554:282c0a6e6d8f
user:Gary Lee 
date:Fri Feb 03 10:23:58 2017 +1100
summary: base: avoid SIGPIPE in osaf_auth_server_connect()  [#2286]



---

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

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


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

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

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




---

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

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

[tickets] [opensaf:tickets] #2287 uml: build_uml install_testprog fails for amf_demo app

2017-02-02 Thread Hans Nordebäck 
- **summary**: uml: build_uml install_testprog fails for amf_demo app after the 
new directory structure --> uml: build_uml install_testprog fails for amf_demo 
app
- Description has changed:

Diff:



--- old
+++ new
@@ -1 +1 @@
-build_uml install_testprog fails for amf_demo app after the new directory 
structure.
+build_uml install_testprog fails for amf_demo app with the new directory 
structure.






---

** [tickets:#2287] uml: build_uml install_testprog fails for amf_demo app**

**Status:** review
**Milestone:** 5.2.FC
**Created:** Thu Feb 02, 2017 01:05 PM UTC by Hans Nordebäck
**Last Updated:** Thu Feb 02, 2017 01:06 PM UTC
**Owner:** Hans Nordebäck


build_uml install_testprog fails for amf_demo app with the new directory 
structure.


---

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

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

[tickets] [opensaf:tickets] #2287 uml: build_uml install_testprog fails for amf_demo app after the new directory structure

2017-02-02 Thread Hans Nordebäck 
- **summary**: samples:build_uml install_testprog fails for amf_demo app after 
the new directory structure --> uml: build_uml install_testprog fails for 
amf_demo app after the new directory structure



---

** [tickets:#2287] uml: build_uml install_testprog fails for amf_demo app after 
the new directory structure**

**Status:** review
**Milestone:** 5.2.FC
**Created:** Thu Feb 02, 2017 01:05 PM UTC by Hans Nordebäck
**Last Updated:** Thu Feb 02, 2017 01:05 PM UTC
**Owner:** Hans Nordebäck


build_uml install_testprog fails for amf_demo app after the new directory 
structure.


---

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

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

[tickets] [opensaf:tickets] #2287 samples:build_uml install_testprog fails for amf_demo app after the new directory structure

2017-02-02 Thread Hans Nordebäck 



---

** [tickets:#2287] samples:build_uml install_testprog fails for amf_demo app 
after the new directory structure**

**Status:** review
**Milestone:** 5.2.FC
**Created:** Thu Feb 02, 2017 01:05 PM UTC by Hans Nordebäck
**Last Updated:** Thu Feb 02, 2017 01:05 PM UTC
**Owner:** Hans Nordebäck


build_uml install_testprog fails for amf_demo app after the new directory 
structure.


---

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

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

[tickets] [opensaf:tickets] #2279 mds: Remove calls to exit

2017-02-02 Thread Hans Nordebäck 
- **status**: review --> fixed
- **Comment**:

changeset:   8553:aeffd7de19e6
tag: tip
user:Hans Nordeback 
date:Thu Feb 02 13:11:06 2017 +0100
summary: mds: Remove calls to exit [#2279]




---

** [tickets:#2279] mds: Remove calls to exit**

**Status:** fixed
**Milestone:** 5.2.FC
**Created:** Fri Jan 27, 2017 01:27 PM UTC by Hans Nordebäck
**Last Updated:** Fri Jan 27, 2017 01:27 PM UTC
**Owner:** Hans Nordebäck


MDS calls exit() and this results in aborts. Calling exit() in shared libraries 
is incorrect, it is the caller to decide action based on return values, not the 
library. By calling exit()  at_exit handlers, destructors etc. will be run in 
parallel with other threads.


---

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

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

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

2017-02-02 Thread Nagendra Kumar 
Hi Minh,

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

 

Thanks

-Nagu

 

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

 

Hi Nagu,

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

Thanks,
Minh

  _  

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

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

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

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

  _  

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a 
mailing list, you can unsubscribe from the mailing list.



---

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

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


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

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


---

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

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

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

2017-02-02 Thread Nagendra Kumar 
Hi Minh,
I also wouldn’t prefer to rollback but because of internal 
implementation, I am just reusing the code. I am preferring return code as 
TRY_AGAIN because the error has occurred and the operation can’t be completed.

Thanks
-Nagu


---

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

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


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

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


---

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

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