> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf 
> Of Mark Gertsvolf (JIRA)
> Sent: Thursday, July 02, 2009 11:27 PM
> To: [email protected]
> Subject: [SFtrack] Updated: (XX-6051) sipXsupervisor to alert 
> admin whensystem services can not start
> 
>
http://track.sipfoundry.org/browse/XX-6051?page=com.atlassian.jira.plugi
n.system.issuetabpanels:all-tabpanel 
> 
>     Description: 
> At the moment if a service fails to start due to a 
> precondition not being met sipXsupervisor does not proide a 
> visual indication and does not raise an alarm. Admin has to 
> visit services page to find out that one or more services 
> fail to start. At the same time there is a visual indication 
> on multiple pages when one or more services needs to be 
> restarted or when one of the jobs fail or when updates are 
> available. There should be a similar visual indication 
> telling the admin that one or more services can not run due 
> to configuration or another issue.
> 
> At the same time due to unpredictable nature of component 
> restarts/failures it would be very helpful if an alarm is 
> raised when such service failure occurs. At the moment an 
> alarm is raised if component fail and restarts, but there is 
> no alarm when component can not start after an admin 
> initiated restar
> 
> See http://list.sipfoundry.org/archive/sipx-dev/msg18582.html 
> for an illustration.
> 

This is asking for two quite separate things:

1) visual indication of non-running service.
     This would be a config server feature: any Enabled service which is
not in Running should cause a message to be displayed on each page with
a link to the Services page.  After restarting a service, the config
server would have to follow its status until it reaches Running or a
failure state.

2) alarm on any service which does not get to Running.
     This is a supervisor feature: raise alarm on entry to states
ConfigurationMismatch, ResourceRequired, and ConfigTestFailed.

I think two JIRAs are warranted, assuming that we have agreement on both
these requirements.

Carolyn
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to