argument list too long 啥意思

Posted 2023-03-21

当你Linux下试图传递太多参数给一个系统命令(ls *; cp *; rm *; cat *; etc…)时，就会出现”Argument list too long”错误。本文将提供4种解决方法，按复杂程度由低到高排列。正如Occam’s Razor的逻辑原则所说：如果其他方面不分伯仲，简单的解决方法则最好。
方法#1: 手动把命令行参数分成较小的部分
例1
mv [a-l]* ../directory2
mv [m-z]* ../directory2
这是4种方法里最简单的,但是远非理想的方法。你必须有办法平均分割文件，而且对于文件数目极多的情况，需要输入N遍命令。
方法#2: 使用find命令
例2
find $directory -type f -name ‘*’ -exec mv
$directory2/. \;
方法2通过find命令筛选文件列表，把符合要求的文件传递给一系列命令。
优点是find命令有很强大的筛选功能，而且，也许是最重要的，这个方法只需要1行命令。
唯一的缺点是， 方法2需要遍历文件，因此耗时较多。
方法#3: 建立函数
例3a
function large_mv ()
while read line1; do
mv directory/$line1 ../directory2
done

ls -1 directory/ | large_mv
虽然写一个shell函数确实比较复杂，但这个方法比方法1或2更灵活，它依次处理每个文件，可以进行无数操作而只使用一个命令，如:
例3b
function larger_mv ()
while read line1; do
md5sum directory/$line1 >> ~/md5sums
ls -l directory/$line1 >> ~/backup_list
mv directory/$line1 ../directory2
done

ls -1 directory/ | larger_mv
例3b显示我们可以先轻松地得到文件的md5sum和备份文件列表然后移动文件
然而方法3也需要遍历每个文件，因此类似方法2,也比较耗时。根据经验，方法2要稍快一些，因此仅当需要复杂的操作时才使用方法3.
方法#4：重新编译Linux内核
最后一个方法需要2个字：谨慎，这个方法很高级，因此没有经验的linux用户最好不要尝试。此外，在永久使用前，务必在系统环境中全面测试。
方法4只需要手动增加内核中分配给命令行参数的页数。打开include/linux/binfmts.h文件，在文件起始附近位置有以下几行：
/*
* MAX_ARG_PAGES defines the number of pages allocated for arguments
* and envelope for the new program. 32 should suffice, this gives
* a maximum env+arg of 128kB w/4KB pages!
*/
#define MAX_ARG_PAGES 32
为了增加分配格命令行参数的内存，只需要赋给MAX_ARG_PAGES一个更大的值，保存，重新编译，安装，重启，搞定
在我的系统中，我把MAX_ARG_PAGES的值增加到64,就解决了所有问题。在改变这个值后，我还没有遇到任何问题。这是可以理解的，当MAX_ARG_PAGES被改为64,最长的参数行仅占用256KB系统内存–对于现在的硬件标准不算什么。
方法4的优点很明显，现在你只要像通常一样运行命令。缺点也很明显,如果分配给命令行的内存大于可用的系统内存，可能导致对系统自身的拒绝服务攻击(DoS attack)，引起系统崩溃。尤其是对于多用户系统，即使增加很小的内存分配都会有很大影响，因为每个用户都被分配到额外内存。因此一定要充分测试来决定是否你的系统可以使用方法4。 参考技术A 参数列表太长

Argument list too long......

作为一名运维人员来说，这个错误并不陌生，在执行rm、cp、mv等命令时，如果要操作的文件数很多，可能会使用通配符批量处理大量文件，这时就可能会出现“Argument list too long”这个问题了。

1、错误现象

这是一台Mysql数据库服务器，在系统中运行了很多定时任务，今天通过crontab命令又添加了一个计划任务，退出时发生了如下报错：

1	#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命令删除所有的文件时，出现了错误：

1 2	[[email protected] clientmqueue]# rm * /bin/rm: argument list too long

此时出现了本文开头我们谈到的问题。

 

当Linux下试图传递太多参数给一个系统命令时，就会出现”Argument list too long”错误。这个是Linux系统一直以来都有的限制。查看这个限制可以通过命令“getconf ARG_MAX”来实现，如下图所示：

 

这是Centos6版本的一个最大值，而在Centos5.x中，这个值相对较小，如下图所示：

 

所以这个问题更多时候是发生在linux低版本中。

 

知道了产生问题的原因，解决方法就很多了，这里提供四种解决此问题的方法，分别介绍如下：

 

（1）手动把命令行参数分成较小的部分

例如：

1 2	rm [a-n]* -rf rm [o-z]* -rf

这种方法里最简单的,但是相对较弱智，因为必须要知道怎么平均分割文件，同时对于文件数目极多的情况，需要输入很多遍命令。

 

（2）使用find命令删除

基本原理是通过find命令筛选文件列表，把符合要求的文件传递给一系列命令。这种方法是最简洁的，也就最有效的。

例如：

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

但是这种方法也有缺点：就是需要遍历所有文件，因而在文件数量极多时比较耗时。

 

（3） 通过shell脚本

这种方法是通过编写一个shell脚本，然后通过循序语句实现，与find方法类似。

例如，可以编写如下脚本：

1 2	#!/bin/bash # 设定需要删除的文件夹

1 2 3 4 5 6

RM_DIR=‘/var/spool/clientmqueue‘ cd $RM_DIR for I in `ls` do  rm -f $I done

 

（4）重新编译Linux内核

这种方法需要手动增加内核中分配给命令行参数的页数，打开kernel source下面的include/linux/binfmts.h文件，找到如下行：

1	# define MAX_ARG_PAGES  32

将”32“改为更大的值，例如64或128，然后重新编译内核。

此种方法永久有效，可以彻底解决问题，但是比较复杂，推荐给高级用户使用，没有Linux经验的用户不建议用这种方法。

本文出自 “技术成就梦想” 博客，请务必保留此出处http://ixdba.blog.51cto.com/2895551/1433379