No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.

Knowledge Base

The inode usage is abnormally high

Publication Date:  2019-07-27  |   Views:  588  |   Downloads:  0  |   Author:  v84083177  |   Document ID:  EKB1001336812


Issue Description

The U2000 generated a critical risk alarm: The inode usage is abnormally high, /var >60%


1. Ask client to verify and reply the status of:

a. U2000 Guard

b. system monitoring information from Administration menu


2. As well the client should run the Ueasy Health Check software, specific for his OS type, in order to verify the NMS environment.

*the Ueasy should be the latest version available

*client will choose the pre-upgrade scenario and then provide us the report.


3. The report will be delivered to R&D for further checks if is necessary.


4. Because the error details showed that the /var parameter is affected, we have connect on client network on the Linux platform:

a. checked the live network and the version (#svc_adm-cmd version)

b. checked the File System

:var # df -i

:var # df-i /var  ///  the path is displayed on the alarm detail.

                       ///  the capacity of the inode was very high

c. checked the files under "var/"


      engr/cd .. /spool/

                     /spool #ls /// provided us a large data of junk files

d. delete the junk files

# ls | wc-c       /// indicating the amount of junk files (around 8 millions)

:var/spool/postfix/maildrop # rm*  /// "rm*" can not delete all the files, the files should be deleted part by part. The asterisk "*" will re replaced by months choosing 1,2,3..9,A,B..

*run again the command #ls | wc-c


5. Go back on U2000 Client and run the U2000 Guard, the operation shown that "1 critical risk are found that will cause the U2000 to be abnormal. Solve them at the earliest time possible" alarm cleared.





In order to avoid this alarm to reappear client can check the schedule task by running the command crontab -l, confirm if there are any task which have no output to /dev/null 2>&1.

In our current situation the files should be generated by sntp schedule task(the other task no need modify).  So please modify the output of the schedule task as add the path of /dev/null 2>&1 to the task tail like this

* * * * * task > /dev/null 2>&1

You can modify it by below command:#crontab -e  (the edit command is same with ‘VI’ or ‘VIM’)