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 [email protected] 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.
------------------------------------------------------------------------------
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
