Member WAITING_FOR_FAILBACK, no alerts, corresponding host is in INACTIVE state with alert

The output of the db2instance -list command shows at least one member in WAITING_FOR_FAILBACK state with no alerts, and the corresponding host is in INACTIVE state with an alert.

This is a sample output from the db2instance -list command showing a three member, two cluster caching facility environment:
ID        TYPE             STATE                HOME_HOST    CURRENT_HOST    ALERT   PARTITION_NUMBER    LOGICAL_PORT    NETNAME
--        ----             -----                ---------    ------------    -----   ----------------    ------------    -------
0         MEMBER           WAITING_FOR_FAILBACK hostA        hostB           NO                     0               1    hostB-ib0
1         MEMBER           STARTED              hostB        hostB           NO                     0               0    hostB-ib0
2         MEMBER           STARTED              hostC        hostC           NO                     0               0    hostC-ib0
128       CF               PRIMARY              hostD        hostD           NO                     -               0    hostD-ib0
129       CF               PEER                 hostE        hostE           NO                     -               0    hostE-ib0
	
HOSTNAME              STATE      INSTANCE_STOPPED ALERT
--------              -----      ---------------- -----
hostA                 INACTIVE   NO               YES
hostB                 ACTIVE     NO               NO
hostC                 ACTIVE     NO               NO
hostD                 ACTIVE     NO               NO
hostE                 ACTIVE     NO               NO
Member 0 has experienced a problem with its home host, hostA, and performed a successful restart light on hostB.

Running the db2instance -list at this point shows no alerts for the member 0 after it performed a restart light. This is indicated in the ALERT column for member 0. This means member 0 was successful on its first attempt at performing restart light on hostB.

Since hostA is unavailable, the state for the host is set to INACTIVE. member 0 can not fail back while hostA is in the INACTIVE state; member 0 will therefore remain in WAITING_FOR_FAILBACK state.

If hostA becomes available again, its state will change from INACTIVE to ACTIVE. member 0 will fail back to hostA, and its state will change from WAITING_FOR_FAILBACK to STARTED. To diagnose this symptom see Diagnosing a host reboot with a restart light.