1、錯誤現象

這是一臺Mysql數據庫服務器，在系統中運行了很多定時任務，今天通過crontab命令又添加了一個計劃任務，退出時發生了如下報錯：

#crontab -e

編輯完成后，保存退出，就出現下面如下圖所示錯誤：

2、解決思路
根據上面報錯的提示信息，基本判定是磁盤空間滿了，那么首先從檢查服務器的磁盤空間開始，根據報錯提示應首先檢查/tmp磁盤空間，然后應該是根分區的磁盤空間，最好是系統其它分區的磁盤空間。

3、問題排查
通過df命令查看了這個服務器上所有磁盤分區的情況，/tmp分區空間還有很多，根分區也還有很大剩余空間，都不存在問題，最后發現是/var磁盤分區空間使用已經100%了，到這里已經定位了問題，是/var磁盤空間爆滿導致的，因為crontab會在保存時寫文件信息到/var目錄下，由于這個磁盤沒有空間了，報錯也是理所當然了。

4、解決問題
接著通過“du -sh”命令檢查/var目錄下所有文件或目錄的大小，發現/var/spool/clientmqueue目錄占用了/var整個分區大小的90%，那么/var/spool/clientmqueue目錄下的文件都是怎么產生的呢，是否能刪除？下面簡單介紹下/var/spool/clientmqueue目錄的文件是怎么生成的。

可以打開/var/spool/clientmqueue目錄下的一些文件看看，都是一些郵件信息，郵件內容大多是關于Cron Daemon的，其實/var/spool/clientmqueue就是一個郵件暫存的目錄，linux服務器在默認情況下會發一些郵件，比如當cron執行的程序有輸出內容時，就會發送郵件信息到執行cron進程的用戶，系統在發送郵件時，首先會把郵件拷貝到/var/spool/clientmqueue目錄下，然后等待MTA程序(mail transfer agent)來處理，而MTA主要的功能是把這個目錄中的郵件轉移到/var/spool/mqueue目錄下，然后再通過sendmail服務發送到真正的目的地。于是檢查了這個服務器的sendmail服務，發現沒有開啟，這樣/var/spool/clientmqueue目錄非常大的原因就找到了：沒有發送郵件的客戶端服務，所有郵件就都堆積在這個目錄下了。

在確認完這些內容都沒用后，切換到/var/spool/clientmqueue目錄下，執行rm命令刪除所有的文件時，出現了錯誤：

[root@localhost clientmqueue]# rm */bin/rm: argument list too long

此時出現了本文開頭我們談到的問題。

當Linux下試圖傳遞太多參數給一個系統命令時，就會出現”Argument list too long”錯誤。這個是Linux系統一直以來都有的限制。查看這個限制可以通過命令“getconf ARG_MAX”來實現，如下圖所示：

這是Centos6版本的一個最大值，而在Centos5.x中，這個值相對較小，如下圖所示：

所以這個問題更多時候是發生在linux低版本中。

知道了產生問題的原因，解決方法就很多了，這里提供四種解決此問題的方法，分別介紹如下：

（1）手動把命令行參數分成較小的部分
例如：

rm [a-n]* -rfrm [o-z]* -rf

這種方法里最簡單的,但是相對較弱智，因為必須要知道怎么平均分割文件，同時對于文件數目極多的情況，需要輸入很多遍命令。

（2）使用find命令刪除
基本原理是通過find命令篩選文件列表，把符合要求的文件傳遞給一系列命令。這種方法是最簡潔的，也就最有效的。
例如：

find /var/spool/clientmqueue -type f -print -exec rm -f {} /;

但是這種方法也有缺點：就是需要遍歷所有文件，因而在文件數量極多時比較耗時。

（3） 通過shell腳本
這種方法是通過編寫一個shell腳本，然后通過循序語句實現，與find方法類似。
例如，可以編寫如下腳本：

#!/bin/bash# 設定需要刪除的文件夾RM_DIR='/var/spool/clientmqueue'cd $RM_DIRfor I in `ls`do rm -f $Idone

（4）重新編譯Linux內核
這種方法需要手動增加內核中分配給命令行參數的頁數，打開kernel source下面的include/linux/binfmts.h文件，找到如下行： 

# define MAX_ARG_PAGES  32

將”32“改為更大的值，例如64或128，然后重新編譯內核。
此種方法永久有效，可以徹底解決問題，但是比較復雜，推薦給高級用戶使用，沒有Linux經驗的用戶不建議用這種方法。