offline service group cause service group to fault

[ryan]

We have a server application which processes messages from clients.  The application StopProgram attribute calls a script which execute a 'kill -SIGKILL <server-pid>' command.

The service group has the following resources:
- application
- ip
- nic

When the service group is offline while the clients are connected, the service group always ended up in a faulted state.  Does anyone know why?  Any suggestion or clarification is much appreciated.

[Eric_Gao]

For a service group being faulted,  there must be some resource being in a strange state, that is not online ,not offline and not being able to bring online or offline.

So I suggest to have a close eye on your stop/start/monitor script.

After you issued the command to offline group,  does the application really got shut down?  Also check monitor script,  run the checking command manually and double check the return value.

Also you service group contains nic?  is that a proxy that refers another nic in another group?

Eric

[ryan]

Thanks for reply and suggestions; here is a bit more information regarding my problem.

1) The service group only faultst when I tried to offline it while there is a client connected
2) The nic in this service group is only a proxy with the target resource attribute pointing to a real nic resource in another service group
3) The dependencies is application -> ip -> nicproxy
4) The ip resource is the one that get faulted; the log indicates that 'ip unexpectedly went offline ... ; VCS is cleaning resource ...'

So my next question is how does a virtual ip goes offline unexpectedly?

[ryan]

It turned out that when the IP resource was offline, the agent ended up taking down all other virtual ips on the same subnet.  This causes other service groups to fault.  By the way, this does not always happen; especially while Veritas technical support is monitoring remotely ;)

Has anyone experience this problem?

[Gaurav_S]

Not really.... :)

Is your IP resource configured as critical ?


Gaurav

[ryan]

It turned out that I have used the wrong netmask value.