„Argument list too long“ (E2BIG) und das ARG_MAX-Limit

Worum es geht

Argument list too long ist die Darstellung des Fehlers E2BIG durch die Shell. execve(2) liefert ihn, wenn die Gesamtgrösse von Argumentliste und Umgebung (Environment) eines neuen Programms das Limit des Kernels überschreitet, das allgemein ARG_MAX genannt wird. Die Manpage zu execve(2) dokumentiert, dass in diese Berechnung neben den Argumenten auch die Umgebung einfliesst; eine grosse exportierte Umgebung lässt also weniger Platz für Argumente, bevor dasselbe Limit erreicht wird. Seit Linux 2.6.23 beträgt die Gesamtgrösse ein Viertel des Stack-Limits (ulimit -s), und jedes einzelne Argument oder jeder einzelne Umgebungsstring mit mehr als 128 KiB löst denselben Fehler aus, selbst wenn die Gesamtgrösse klein ist. Der übliche Auslöser ist das Globbing der Shell: Bei einem Befehl wie rm /path/*.log expandiert die Shell das Glob zu Tausenden von Dateinamen, bevor execve überhaupt aufgerufen wird. Der Fehler tritt also auf, noch bevor rm läuft.

Warum es wichtig ist

Der Fehler sieht nach einem Bug im ausgeführten Befehl aus, doch der Befehl erhält nie die Kontrolle: Die Expansion der Shell hat das Limit bereits überschritten. Deshalb hilft es nicht, Quoting oder Escaping in der Befehlszeile zu ändern.

So wird es angewendet

• Diagnose: getconf ARG_MAX gibt das effektive Limit des aktuellen Systems in Bytes aus. echo * | wc -c im betroffenen Verzeichnis zeigt, wie gross die tatsächliche Expansion ist, und bestätigt so, dass wirklich dieses Limit erreicht wird; GNU xargs --show-limits </dev/null gibt die nach Abzug der Umgebung nutzbare Grösse aus.
• Lösungen, von der am wenigsten bis zur am stärksten eingreifenden:
  1. Die Operation über xargs aufteilen, das laut Dokumentation eine lange Eingabe auf so viele Aufrufe verteilt, wie nötig sind, um unter dem Limit zu bleiben: printf '%s\n' *.log | xargs rm --, oder bei Dateinamen, die ungewöhnliche Zeichen enthalten können, find . -maxdepth 1 -type f -name '*.log' -print0 | xargs -0 rm -- (ohne -maxdepth 1 steigt find auch in Unterverzeichnisse ab und löscht mehr, als das Glob erfasst hätte).
  2. find ... -exec cmd {} + gegenüber -exec cmd {} \; bevorzugen; die Manpage find(1) dokumentiert die Form mit + so, dass sie so viele gefundene Namen, wie hineinpassen, in einem einzigen Aufruf bündelt, sodass keine separate xargs-Pipeline nötig ist.
  3. Wenn eine aufgeblähte exportierte Umgebung dasselbe Budget aufzehrt, diese vor dem Aufruf des Befehls verkleinern.
  4. Die Aufgabe so umbauen, dass gar keine riesige Argumentliste entsteht: über Pfade iterieren, die aus einer Datei oder von stdin gelesen werden, oder das Werkzeug die Treffer selbst bearbeiten lassen (zum Löschen find . -maxdepth 1 -type f -name '*.log' -delete), statt jeden Pfad in einer einzigen Befehlszeile aufzulisten.
• Keine Lösung: zusätzliches Quoting. Das Limit gilt für die Gesamtzahl der Bytes und die Anzahl der Argumente nach der Shell-Expansion; wie die Argumente gequotet sind, ändert an dieser Summe nichts.

Stolpersteine

• Annehmen, ein Wildcard, das „schon immer funktioniert hat“, sei unbedenklich; derselbe Befehl scheitert, sobald das Verzeichnis über die Schwelle hinauswächst.
• -print0/-0 vergessen, obwohl Dateinamen Leerzeichen oder Zeilenumbrüche enthalten können; das macht aus einer Korrektur der Länge einen Korrektheitsfehler.