- This topic has 3 replies, 2 voices, and was last updated 15 years, 5 months ago by
.
-
Topic
-
Running Cloverleaf 5.4.1P on HP-UX B.11.11 We bounced the entire engine this morning (including the UNIX box itself). Part of our routine includes “hcidbinit -CAfi” for every site.
When we restarted the processes, two of them generated the error below (they were both the same error). They were both in the same site and other processes in the site had already been started successfully. After the error, we were able to start both of them without issue.
Any thoughts on what is going on here? Are we approaching a big issue that needs addressing???
Scheduler State
Thread Events State Priority Runnable PT Msgs
0 0 SCHED_IDLE 0 0 0,0,0
Thread 0
ti: 0x40315730
tid : 0
HostPthreadId : 0x00000001
EventList : 0x40075ec0
PolledEvents : 0x40075f80
PthreadEvent : 0x40081288
ReadyEvents : 0x40075ed8
CtrlMsgs : 0x40075f38
UserCtrlMsgs : 0x40075f68
UserDataMsgs : 0x40075ef0
StartArgs : 0x00000000
SchedState : SCHED_IDLE
SchedPriority : 0
Killed : 0
Registered Events
el: 0x40075ec0
elCount : 1
elHead: 0x400806c0
elTail: 0x400806c0
ele: 0x400806c0
event: 0x40081288
prev : 0x0
next : 0x0
ev: 0x40081288
evType : PTHREADS
evStrDesc :
evSocket : 0
evMsgQue : 0
evTid : 0
evState : 0
evPtMsg : 0x0
evUserData : 0x0
evCallBack : 0x0
evCbShutdown : 0x0
evRecurFreq :
Polled Events
el: 0x40075f80
elCount : 0
elHead: 0x00000000
elTail: 0x00000000
Ready Events
el: 0x40075ed8
elCount : 0
elHead: 0x00000000
elTail: 0x00000000
Outstanding Pthread Ctrl Msgs
pmq: 0x40075f38
Count : 0
Head : 0x00000000
Tail : 0x00000000
Outstanding Pthread User Ctrl Msgs
pmq: 0x40075f68
Count : 0
Head : 0x00000000
Tail : 0x00000000
Outstanding Pthread User Data Msgs
pmq: 0x40075ef0
Count : 0
Head : 0x00000000
Tail : 0x00000000
PANIC: Process panic—engine going down
PANIC: assertion ‘0’ failed at main.cpp/241
[/color]
-
Replies
-
-
-
Gary Atkinson wrote:
Were/are there any messages in the recovery database that belong to those processes?
We do this monthly and have procedures in place to keep messages out before we take it down.
We check the databases (hcidbdump) right before we take them down to make sure they are empty.
A message could have snuck in, but at this point, I am not sure how to tell?? Is there a trail somewhere that would tell me???
I would assume though that as soon as we came up and made a connection with the sending application, it had messages queued up to send us.
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
