For some reason handle initialize is accepted by the sync client when
it should not be.
The handle initialize should get TRY_AGAIN before and during sync of
local IMMND.
That is the problem. But we have not tracked down yet as to why the
initialize gets accepted
when it should not be.
/AndersBj
A V Mahesh (AVM) wrote:
> Yes , problem is occurring even with access control is NOT enabled.
>
> ================================================
> Aug 20 15:13:49 SC-2 osafimmnd[6765]: NO Fevs count adjusted to 1705
> preLoadPid: 0
> Aug 20 15:13:49 SC-2 osafimmnd[6765]: NO SERVER STATE: IMM_SERVER_ANONYMOUS
> --> IMM_SERVER_CLUSTER_WAITING
> Aug 20 15:13:50 SC-2 osafimmnd[6765]: NO SERVER STATE:
> IMM_SERVER_CLUSTER_WAITING --> IMM_SERVER_LOADING_PENDING
> Aug 20 15:13:50 SC-2 osafimmnd[6765]: NO SERVER STATE:
> IMM_SERVER_LOADING_PENDING --> IMM_SERVER_SYNC_PENDING
> Aug 20 15:13:50 SC-2 osafimmnd[6765]: NO NODE STATE-> IMM_NODE_ISOLATED
> Aug 20 15:13:52 SC-2 osafimmd[6228]: NO SBY: Ruling epoch noted as:7
> Aug 20 15:13:52 SC-2 osafimmd[6228]: NO IMMND coord at 2010f
> Aug 20 15:13:52 SC-2 osafimmnd[6765]: NO NODE STATE-> IMM_NODE_W_AVAILABLE
> Aug 20 15:13:52 SC-2 osafimmnd[6765]: NO Implementer (applier) connected: 28
> (@safAmfService2020f) <299, 2020f>
> Aug 20 15:13:52 SC-2 osafimmnd[6765]: NO Sync client discarded
> classimplementer set. Impl-id:28 Class:SaAmfCompBaseType
> Aug 20 15:13:52 SC-2 osafimmnd[6765]: NO SERVER STATE:
> IMM_SERVER_SYNC_PENDING --> IMM_SERVER_SYNC_CLIENT
> Aug 20 15:14:02 SC-2 osafamfd[6290]: ER Impl Set Failed for
> SaAmfCompBaseType, returned 5
> Aug 20 15:14:02 SC-2 osafamfd[6290]: ER exiting since avd_imm_applier_set
> failed
> Aug 20 15:14:02 SC-2 osafamfnd[6300]: ER AMF director unexpectedly crashed
> Aug 20 15:14:02 SC-2 osafamfnd[6300]: Rebooting OpenSAF NodeId = 131599 EE
> Name = , Reason: local AVD down(Adest) or both AVD down(Vdest) received,
> OwnNodeId = 131599, SupervisionTime = 60
> Aug 20 15:14:02 SC-2 osafimmnd[6765]: NO Implementer locally disconnected.
> Marking it as doomed 28 <299, 2020f> (@safAmfService2020f)
> Aug 20 15:14:02 SC-2 osafimmnd[6765]: NO Implementer disconnected 28 <299,
> 2020f> (@safAmfService2020f)
> Aug 20 15:14:02 SC-2 opensaf_reboot: Rebooting local node; timeout=60
> Aug 20 15:14:03 SC-2 osafimmnd[6765]: NO finalizeSync implementerSet
> '@safAmfService2020f' id: 0 has bypassed finalizeSync, ignoring
> Aug 20 15:14:03 SC-2 osafimmnd[6765]: NO NODE STATE->
> IMM_NODE_FULLY_AVAILABLE 2462
> Aug 20 15:14:03 SC-2 osafimmnd[6765]: NO RepositoryInitModeT is
> SA_IMM_INIT_FROM_FILE
> Aug 20 15:14:03 SC-2 osafimmnd[6765]: WA IMM Access Control is OFF!
> Aug 20 15:14:30 SC-2 syslog-ng[1169]: syslog-ng starting up; version='2.0.9'
> =========================================================================
>
>
> ---
>
> ** [tickets:#995] IMM: after immnd restart amfd fails to become class
> implementer**
>
> **Status:** assigned
> **Milestone:** 4.5.0
> **Created:** Tue Aug 19, 2014 10:36 AM UTC by Hans Feldt
> **Last Updated:** Wed Aug 20, 2014 09:26 AM UTC
> **Owner:** Hans Feldt
>
> Seems like the IMM access control changes triggers some new behavior around
> the IMM "resurrect" logic that cause client failure after immnd restart.
>
> Test case is simply to kill immnd on a controller. In most cases it ends up
> with node reboot since amfd cannot become class implementer. Timeout is
> returned which is not handled properly.
>
> If this cannot be resolved rather quickly I am afraid the IMM access control
> feature should be backed out.
>
>
>
> ---
>
> Sent from sourceforge.net because you indicated interest in
> <https://sourceforge.net/p/opensaf/tickets/995/>
>
> To unsubscribe from further messages, please visit
> <https://sourceforge.net/auth/subscriptions/>
>
---
** [tickets:#995] IMM: after immnd restart amfd fails to become class
implementer**
**Status:** assigned
**Milestone:** 4.5.0
**Created:** Tue Aug 19, 2014 10:36 AM UTC by Hans Feldt
**Last Updated:** Wed Aug 20, 2014 11:11 AM UTC
**Owner:** Hans Feldt
Seems like the IMM access control changes triggers some new behavior around the
IMM "resurrect" logic that cause client failure after immnd restart.
Test case is simply to kill immnd on a controller. In most cases it ends up
with node reboot since amfd cannot become class implementer. Timeout is
returned which is not handled properly.
If this cannot be resolved rather quickly I am afraid the IMM access control
feature should be backed out.
---
Sent from sourceforge.net because [email protected] is
subscribed to http://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
http://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
