Created attachment 480444 [details]
cluster.conf + fake scripts to provide timeline to reproduce bug

Description of problem:
If a service (named Se2 in the following) is dependent upon a service (Se1 in the following), and Se1 gets moved or restarted for any reason, Se2 might not be restarted.
This happens depending on the following timeline:
Se1 is moved or restarted and transition from started to stopped (if manually forced to move or for failure), and then it gets restarted on the same or other cluster member. Service state goes from stopped to starting.
Se2 is stopped since it depends on Se1, so if Se1 state gets to stopped, Se2 is forced to stop by cluster rule.
Se2 state goes from started to stopping.
This is the trick.
If Se1 gets to started BEFORE Se2 gets to stopped (end of stop script), Se2 is not restarted.
If Se2 gets to stopped BEFORE Se1 gets from starting to started, Se2 is correcty (re)started.
It seems that some kind of notification is sent as soon as Se1 gets to started and Se2 is unable to perform any action before it gets stopped state.
So if Se2 is stopped, it can move from stopped to starting (and eventually to started), but if still stopping, it never gets to starting (cluster will not "cache" the Se1 event to started and subsequently notify Se2 to dependently move to starting phase).


Version-Release number of selected component (if applicable):
rgmanager-2.0.52-9.el5

How reproducible:
Create a cluster with attached cluster.conf + /root/scripts/service1 and /root/scripts/service2 on all cluster nodes


Steps to Reproduce:
1. start cluster and wait for all services to starts (eventually clusvcadm -e both of them)
2. trigger a Se1 (A service in the description) restart or move (clusvcadm -R Se1 OR clusvcadm -r Se1 -m <other_cluster_member>)
3. Look at service Se2 state. It gets to stopped but never restarted.
  
Actual results:
Se2 never gets started again

Expected results:
Se2 should get restarted as expected

Additional info:
If Se1 is manually restarted again, the Se1 state transition starting->started, triggers the starting of Se2 as expected.

Additionally, if Se1 script (/root/scripts/service1) is changed to the following:

  start)
        echo -e "Starting service\n"
        sleep 10 #THIS IS THE CHANGE
        exit 0
        ;;

restart of Se2 is done as expected.