Skip to main content
DevOps Insightsguides & answers

Linux · troubleshooting

Argument list too long

A shell glob such as rm *.log expanded to more file names than the system lets one command receive. The command never started; split the work with find or xargs instead.

Reproduced on Ubuntu 24.04, . Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published

New to this? Read what is actually happening first, then come back to the steps.

On this page · 9 sections

Before you start

  • The command that failed, and roughly how many files the pattern matches.

Run this first

step 1 of 1
getconf ARG_MAX

Look for 2097152 on this Ubuntu host, 1048576 on macOS

Shows the limit on this system.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

Does the failing command use a * pattern over a big directory?

Cause space

2 of 2 still possible

  • A glob matches too many filesCommon
  • The environment is very largeRare

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

  1. Step 1

    getconf ARG_MAX

    Shows the limit on this system.

    Look for 2097152 on this Ubuntu host, 1048576 on macOS

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

A glob matches too many files

Common

rm *.log, cp * dest/ or tar czf a.tgz * in a directory with a very large number of files.

Confirm

find . -maxdepth 1 -name '*.log' | wc -l

Tens or hundreds of thousands of matches

Fix

  • Let find do the work in batches: find . -maxdepth 1 -name '*.log' -type f -delete, or find … -exec cmd {} + for other commands.
  • Or pipe names to xargs: find . -name '*.log' -print0 | xargs -0 rm.
  • For copies and archives, pass the directory itself (cp -r dir dest, tar czf a.tgz dir) instead of dir/*.

The environment is very large

Rare

Arguments and environment share one limit, so a huge exported variable can make even a short command fail.

Confirm

env | wc -c

A size that is a large part of getconf ARG_MAX

Fix

  • Pass large data through files instead of environment variables, and export only what the command needs.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

Before running a command, the shell replaces a pattern like *.log with every matching file name. If there are hundreds of thousands, the list is larger than the kernel's limit for one program's arguments and environment, and the program cannot be started at all. Tools that process files in batches avoid the limit.

Words used on this page

Glob
A file-name pattern such as *.log that the shell expands into a list of names before running the command.
ARG_MAX
The limit on the combined size of a new program's arguments and environment; getconf ARG_MAX prints it.
find -exec … {} +
Runs a command on found files in batches that fit within the limit.
What is actually happening

Reproduced on 23 October 2026 with 200,000 files on Ubuntu 24.04: ls f* and rm f* failed with "bash: line 1: /usr/bin/ls: Argument list too long" and exit 126, meaning the command could not be started. find . -name 'f*' -type f -delete removed every one. getconf ARG_MAX printed 2097152 there.

On macOS, zsh words it "argument list too long: /bin/ls" (exit 127), and the limit is half the size: 1048576. The kernel counts the environment against the same limit, so very large environment variables, such as secrets loaded into a CI job, leave less room for arguments.

How to tell this is your problem
WhereWhat you see
bash on Linuxbash: /usr/bin/rm: Argument list too long
zsh on macOSzsh: argument list too long: /bin/ls

How to know it is actually fixed

  • The batched find or xargs command completes, and the files are gone or processed.

Stopping it happening again

  • Write cleanup jobs with find, not shell globs, so they keep working as directories grow.
  • Rotate or prune logs and artefacts before a directory reaches hundreds of thousands of files.

Security considerations

  • Test a bulk delete with -print first (find . -name '*.log' -type f -print | head) before switching to -delete.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it

Where to go next