> -----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/