The last trace relevant to opensafImm object shows safImmService is the
admin owner for the object.
Sep 8 15:48:23.801101 osafimmnd [20639:ImmModel.cc:4401] T5 Set admin
owner 'om_teardown'
Sep 8 15:48:23.801153 osafimmnd [20639:ImmModel.cc:13261] T7 ERR_EXIST:
Object 'opensafImm=opensafImm,safApp=safImmService' has different
administative owner safImmService != om_teardown
Sep 8 15:48:23.801233 osafimmnd [20639:ImmModel.cc:4519] <<
adminOwnerChange
Can you share the traces where the admin owner for that object has been
changed by the application before AdminOwnerRelease() or
AdminOwnerFinalize()?
On Monday 08 September 2014 06:19 PM, Sirisha Alla wrote:
Without being an admin owner for an object, does IMM honor clear of
admin owner on that object? And why does this work in single PBE case?
Is this behavior different from 4.4?
On Monday 08 September 2014 06:10 PM, Neelakanta Reddy wrote:
- **status**: unassigned --> invalid
- **Comment**:
Application has explicitly called Adminownerclear on object
opensafImm=opensafImm,safApp=safImmService. imm service needs
admin-ownership over the object
"opensafImm=opensafImm,safApp=safImmService" in order for 2PBE to
work properly(see README.2PBE)
Sep 8 15:48:55.996067 osafimmnd [20639:immsv_evt.c:5382] T8
Received: IMMND_EVT_A2ND_ADMO_CLEAR (11) from 0
Sep 8 15:48:55.996081 osafimmnd [20639:ImmModel.cc:4374] >>
adminOwnerChange
Sep 8 15:48:55.996092 osafimmnd [20639:ImmModel.cc:4401] T5 Clear
admin owner 'ALL'
Sep 8 15:48:55.996139 osafimmnd [20639:ImmModel.cc:4506] TR Cutoff
in admo-change-loop by childCount
Sep 8 15:48:55.996153 osafimmnd [20639:ImmModel.cc:4414] T5 Clear
Admin Owner for object opensafImm=opensafImm,safApp=safImmService
Sep 8 15:48:55.996173 osafimmnd [20639:ImmModel.cc:4506] TR Cutoff
in admo-change-loop by childCount
Sep 8 15:48:55.996186 osafimmnd [20639:ImmModel.cc:4519] <<
adminOwnerChange
---
** [tickets:#1049] ccbs fail to apply after immnd restart in 2pbe**
**Status:** invalid
**Milestone:** 4.3.3
**Created:** Mon Sep 08, 2014 10:53 AM UTC by Sirisha Alla
**Last Updated:** Mon Sep 08, 2014 11:14 AM UTC
**Owner:** nobody
The issue is seen on SLES X86-64 VMs. Opensaf is running on changeset
5697 with 2pbe. Same IMM applications ran fine on single pbe.
opensaf is running on 4 nodes. The issue is observed after IMMND
restart.
After IMMND is killed on PL-3, Syslog on PL-3 and SC-1 (active
controller):
Sep 8 15:49:14 SLES-64BIT-SLOT3 osafamfnd[18773]: NO
'safSu=PL-3,safSg=NoRed,safApp=OpenSAF' component restart probation
timer started (timeout: 60000000000 ns)
Sep 8 15:49:14 SLES-64BIT-SLOT3 osafamfnd[18773]: NO Restarting a
component of 'safSu=PL-3,safSg=NoRed,safApp=OpenSAF' (comp restart
count: 1)
Sep 8 15:49:14 SLES-64BIT-SLOT3 osafamfnd[18773]: NO
'safComp=IMMND,safSu=PL-3,safSg=NoRed,safApp=OpenSAF' faulted due to
'avaDown' : Recovery is 'componentRestart'
Sep 8 15:49:14 SLES-64BIT-SLOT3 osafimmnd[19065]: Started
Sep 8 15:49:14 SLES-64BIT-SLOT3 osafimmnd[19065]: NO Persistent
Back-End capability configured, Pbe file:imm.db (suffix may get added)
Sep 8 15:49:14 SLES-64BIT-SLOT3 osafimmnd[19065]: NO Fevs count
adjusted to 2143 preLoadPid: 0
Sep 8 15:49:14 SLES-64BIT-SLOT3 osafimmnd[19065]: NO SERVER STATE:
IMM_SERVER_ANONYMOUS --> IMM_SERVER_CLUSTER_WAITING
Sep 8 15:49:14 SLES-64BIT-SLOT3 osafimmnd[19065]: NO SERVER STATE:
IMM_SERVER_CLUSTER_WAITING --> IMM_SERVER_LOADING_PENDING
Sep 8 15:49:15 SLES-64BIT-SLOT3 osafimmnd[19065]: NO SERVER STATE:
IMM_SERVER_LOADING_PENDING --> IMM_SERVER_SYNC_PENDING
Sep 8 15:49:15 SLES-64BIT-SLOT3 osafimmnd[19065]: NO NODE STATE->
IMM_NODE_ISOLATED
Sep 8 15:49:15 SLES-64BIT-SLOT3 osafimmnd[19065]: NO NODE STATE->
IMM_NODE_W_AVAILABLE
Sep 8 15:49:16 SLES-64BIT-SLOT3 osafimmnd[19065]: NO SERVER STATE:
IMM_SERVER_SYNC_PENDING --> IMM_SERVER_SYNC_CLIENT
Sep 8 15:49:16 SLES-64BIT-SLOT3 osafimmnd[19065]: NO NODE STATE->
IMM_NODE_FULLY_AVAILABLE 2460
Sep 8 15:49:16 SLES-64BIT-SLOT3 osafimmnd[19065]: NO
RepositoryInitModeT is SA_IMM_KEEP_REPOSITORY
Sep 8 15:49:16 SLES-64BIT-SLOT3 osafimmnd[19065]: WA IMM Access
Control mode is DISABLED!
Sep 8 15:49:44 SLES-64BIT-SLOT3 osafimmnd[19065]: NO Implementer
connected: 43 (Rajesh) <130, 2030f>
Sep 8 15:49:46 SLES-64BIT-SLOT3 osafimmnd[19065]: NO implementer for
class 'AHGEspukccZxcngTQuhG' is Rajesh => class extent is safe.
Sep 8 15:49:46 SLES-64BIT-SLOT3 osafimmnd[19065]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:46 SLES-64BIT-SLOT3 osafimmnd[19065]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:47 SLES-64BIT-SLOT3 osafimmnd[19065]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:47 SLES-64BIT-SLOT3 osafimmnd[19065]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:48 SLES-64BIT-SLOT3 osafimmnd[19065]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:48 SLES-64BIT-SLOT3 osafimmnd[19065]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:49 SLES-64BIT-SLOT3 osafimmnd[19065]: NO Validation
error (BAD_OPERATION) reported by implementer 'OpenSafImmPBE', Ccb 17
will be aborted
Sep 8 15:49:49 SLES-64BIT-SLOT3 osafimmnd[19065]: NO Ccb 17 ABORTED
(SetUp_Ccb)
Sep 8 15:49:43 SLES-64BIT-SLOT1 osafimmpbed: IN Starting distributed
PBE commit for Ccb:11/17
Sep 8 15:49:43 SLES-64BIT-SLOT1 osafimmnd[20639]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:44 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or
Immsv (4294901760) replied with transient error on prepare for ccb:11/17
Sep 8 15:49:44 SLES-64BIT-SLOT1 osafimmnd[20639]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:44 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or
Immsv (4294901760) replied with transient error on prepare for ccb:11/17
Sep 8 15:49:44 SLES-64BIT-SLOT1 osafimmnd[20639]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:45 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or
Immsv (4294901760) replied with transient error on prepare for ccb:11/17
Sep 8 15:49:45 SLES-64BIT-SLOT1 osafimmnd[20639]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:45 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or
Immsv (4294901760) replied with transient error on prepare for ccb:11/17
Sep 8 15:49:45 SLES-64BIT-SLOT1 osafimmnd[20639]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or
Immsv (4294901760) replied with transient error on prepare for ccb:11/17
Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmnd[20639]: NO
ERR_BAD_OPERATION: Mismatch on administrative owner '' !=
'safImmService'
Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or
Immsv (4294901760) replied with transient error on prepare for ccb:11/17
Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmpbed: WA Start prepare for
ccb: 11/17 towards slave PBE returned: '20' from Immsv
Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmpbed: WA PBE-A failed to
prepare Ccb:11/17 towards PBE-B
Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmnd[20639]: NO Validation
error (BAD_OPERATION) reported by implementer 'OpenSafImmPBE', Ccb 17
will be aborted
Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmnd[20639]: NO Ccb 17 ABORTED
(SetUp_Ccb)
Syslog and immnd traces are attached. The issue is reproducible.
---
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.
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
