« Argument list too long » (E2BIG) et la limite ARG_MAX

Ce que c'est

Argument list too long est la forme sous laquelle le shell affiche E2BIG, l'erreur que execve(2) renvoie lorsque la taille cumulée de la liste d'arguments et de l'environnement d'un nouveau programme dépasse la limite du noyau, généralement appelée ARG_MAX. La page de manuel de execve(2) indique que ce décompte inclut l'environnement en plus des arguments : un environnement exporté volumineux laisse donc moins de place aux arguments avant d'atteindre la même limite. Depuis Linux 2.6.23, le total est égal à un quart de la limite de taille de la pile (ulimit -s), et toute chaîne d'argument ou de variable d'environnement isolée de plus de 128 KiB provoque la même erreur, même si le total reste faible. Le déclencheur habituel est l'expansion de motifs (globbing) par le shell : dans une commande comme rm /path/*.log, le shell développe le glob en des milliers de noms de fichiers avant même l'appel à execve, si bien que l'échec survient avant que rm ne s'exécute.

Pourquoi c'est important

L'échec ressemble à un bogue de la commande lancée, mais celle-ci ne reçoit jamais le contrôle : l'expansion effectuée par le shell a déjà dépassé la limite, et aucune modification du quoting ou de l'échappement dans la ligne de commande n'y change quoi que ce soit.

Comment l'appliquer

• Diagnostic : getconf ARG_MAX affiche la limite effective, en octets, du système courant. echo * | wc -c dans le répertoire concerné indique la taille réelle de l'expansion et permet de confirmer que c'est bien cette limite qui est atteinte ; xargs --show-limits </dev/null (GNU) affiche la taille utilisable une fois l'environnement déduit.
• Correctifs, du moins au plus invasif :
  1. Traiter l'opération par lots avec xargs, qui, selon sa documentation, découpe une longue entrée en autant d'invocations que nécessaire pour rester sous la limite : printf '%s\n' *.log | xargs rm --, ou, pour des noms de fichiers pouvant contenir des caractères inhabituels, find . -maxdepth 1 -type f -name '*.log' -print0 | xargs -0 rm -- (sans -maxdepth 1, find descend aussi dans les sous-répertoires et supprime davantage de fichiers que n'aurait fait le glob).
  2. Préférer find ... -exec cmd {} + à -exec cmd {} \; ; la page de manuel de find(1) indique que la forme + regroupe en une seule invocation autant de noms correspondants que possible, ce qui évite un pipeline xargs distinct.
  3. Si un environnement exporté surdimensionné entame le même budget, le réduire avant d'invoquer la commande.
  4. Repenser la tâche pour éviter toute liste d'arguments gigantesque : parcourir des chemins lus depuis un fichier ou l'entrée standard, ou laisser l'outil traiter lui-même les correspondances (pour une suppression, find . -maxdepth 1 -type f -name '*.log' -delete) au lieu de lister chaque chemin sur une seule ligne de commande.
• Ce qui n'est pas une solution : ajouter du quoting. La limite porte sur le nombre total d'octets et d'arguments après l'expansion par le shell ; la manière de protéger les arguments ne change pas ce total.

Pièges

• Croire qu'un joker qui « a toujours fonctionné » est sûr : la même commande échoue dès que le répertoire dépasse le seuil.
• Oublier -print0/-0 lorsque les noms de fichiers peuvent contenir des espaces ou des retours à la ligne, ce qui transforme une correction de longueur en bogue de correction fonctionnelle.