Call Management System (CMS) - DISK_ERR or DISK_WRN Alarms

Description:  

CMS version 17.0 or 16.3 SP5 running on the Solaris platform (version 17.0 or 16.3) or Linux platform (version 17), may report the following disk alarms.

(Alarm Name) : DISK_ERR , (Alarm String) : 16/00:26,ACT|DISK_ERR,DISK_ERR,MAJ

Problem Clarification:

These alarms may indicate one of the following conditions:

1. Disk space is full or near capacity [DISK_ERR or DISK_WRN]

2. Disk failure has occurred [DISK_ERR]

3. Disk failure is imminent [DISK_WRN]

Cause:

If the issue is related to disk storage, a disk that is full or near capacity will have triggered this alarm. If the disk has failed, the cause for the disk failure does not need to be investigated since it will be replaced.

Expected cause is the older release of CMS and the chkdisk script.

This can also be caused if the NFS share or USB drive used for backups is at 100% capacity.

Solution:

There are two possible solutions to this issue depending on whether the disk is full or has actually failed.

Note - Depending on what version of CMS you are running, the path to the commands between 17.0 and

16.3 differ slightly (called out below).

Disk Full

1. Establish a remote session to the CMS system with super-user permissions.

2. Check disk usage on the CMS system to determine if you are dealing with a disk full condition.

3. If the disk is full or near capacity, restore disk space to acceptable levels by removing non-essential, non-

CMS files that could be occupying a large amount of disk space.

4. Next, confirm what DISK_ERR or DISK_WRN alarms currently exist with the following command:

(17.0) /cms/aom/bin/active_alarms or (16.3) /cms/cc/aot/bin/active_alarms

5. If alarms exist proceed with step 6 and 7, otherwise continue to step 8.

6. Attempt to clear the active alarms by issuing the command: (17.0) /cms/aom/bin/alarm_resolve -a

DISK_ERR (repeat command for DISK_WRN) or (16.3) /cms/cc/aot/bin/alarm_resolve -a DISK_ERR

(repeat command for DISK_WRN).

7. Re-check to see if any active disk alarms still exist: (17.0) /cms/aom/bin/active_alarms or (16.3)

/cms/cc/aot/bin/active_alarms

8. Next run the following command to check for disk errors (17.0 and 16.3) /olds/chkDisks. If there are disk

errors, the system will log the errors in /olds/log log file.

9. Re-check the system for active alarms one more time to make sure they have cleared by issuing he

following command: (17.0) /cms/aom/bin/active_alarms 

 (16.3) /cms/cc/aot/bin/active_alarms

If the backup medium is full, delete older backups to free up space.Disk Failure

1. Establish a remote session to the CMS system with super-user permissions.

2. Begin by first confirming any pre-existing DISK_WRN or DISK_ERR alarms with the following

command (17.0) /cms/aom/bin/active_alarms or (16.3) /cms/cc/aot/bin/active_alarms

3. If alarms exist proceed with step 4 and 5, otherwise continue to step 6.

4. Attemp to clear the active alarms by issuing the command (17.0) /cms/aom/bin/alarm_resolve -a

DISK_ERR (repeat command for DISK_WRN) or (16.3) /cms/cc/aot/bin/alarm_resolve -a DISK_ERR

(repeat command for DISK_WRN).

5. Re-check to see if any active disk alarms still exist (17.0) /cms/aom/bin/active_alarms or (16.3)

/cms/cc/aot/bin/active_alarms

6. Next run the following command to check for disk errors (17.0 and 16.3) /olds/chkDisks. If there are disk

errors, the system will log the errors in /olds/log log file.

7. Re-check the system for active alarms one more time by issuing he following command: (17.0)

/cms/aom/bin/active_alarms or (16.3) /cms/cc/aot/bin/active_alarms

8. If any disk alarms are still present, coordinate a dispatch with the hardware vendor (Oracle or Dell) to

have the defective disk(s) replaced. Once the disk is replaced, clear the alarms as above. If the CMS is an

HP machine then Avaya would replace the disk.

Upgrade the CMS to newest version of R16 release or higher to R18

two commands I used to make sure was an issue and to confirm later was working correctly

(cms1)-(Primary)=# /opt/MegaRAID/CLI/MegaCli -pdlist -a0 | grep Firmware

/olds/olds -synch_stat

Manufacturer Release notes:

Please copy the content of this and edit your copy if not creating your article from a ZenDesk Ticket, Delete the text in red

Disclaimer: intlx Solutions Knowledge Base

The information contained in this knowledge base ("Content") is provided for informational purposes only and is intended to be a general resource. intlx Solutions does not guarantee the accuracy, completeness, or timeliness of the Content.

Use at Your Own Risk: By accessing and using the Content, you agree that you do so at your own risk. intlx Solutions assumes no responsibility for any errors or omissions in the Content, nor for any damages or losses you may suffer arising out of or related to the use of the Content.

Current Customers: If you are a current intlx Solutions customer and have questions or require further clarification on any information presented here, please do not hesitate to contact our support team directly. They are available to assist you and ensure you have the most up-to-date information specific to your needs.

Not a Customer? If you are not currently an intlx Solutions customer but are interested in learning more about our solutions and how we can help your business, please click here. We look forward to the opportunity to discuss your needs and explore how a partnership with intlx Solutions can benefit you.

Thank you for your understanding.

This article contains data that is aimed at helping fix an issue with a product. Please use this information at your own risk as intlx Solutions is not responsible for actions taken by the steps or procedures shown in these articles.