Cron Job Failing? The Ultimate Guide to Fixing 'docker: command not found'

## The Problem You've set up a `cron` job to execute a `docker exec` command. It works perfectly when you run it in your terminal, but when you check the logs, you find a perplexing error. This is a real-world scenario encountered by developer DP from the `wiki.lib00.com` community. **Crontab Configuration (`crontab -l`):** ```crontab */2 * * * * docker exec ee-php-fpm-8.4.13 php /eeBox/eeProject/app/public/index.php '/data-import/import?source=all' >> /var/log/wiki.lib00/api_import.log 2>&1 ``` **Error Log (`api_import.log`):** ```plaintext /bin/sh: docker: command not found /bin/sh: docker: command not found ``` Why does the `docker` command, which is readily available in your terminal, suddenly become "not found" in the world of `cron`? --- ## The Root Cause: A Tale of Two `PATH` Environments The core of the issue is this: **the execution environment for a `cron` job is isolated and vastly different from your interactive terminal environment**. - **Terminal Environment**: When you open a terminal, your system loads configuration files like `.bash_profile` or `.zshrc`. These files set up a comprehensive `PATH` environment variable, which tells the shell where to find executables, including paths like `/usr/local/bin` (where `docker` is often located). - **Cron Environment**: `cron` runs tasks in the background in a non-interactive mode, loading a very minimal, default environment. Its `PATH` variable typically only includes basic system directories like `/bin` and `/usr/bin`. The directory `/usr/local/bin` is not part of this default search path. Consequently, when `cron`'s execution shell (`/bin/sh`) tries to run `docker`, it can't find the command in its limited `PATH`, leading to the `command not found` error. --- ## The Solutions Here are three solutions, ranging from simple to more robust. **The first one is highly recommended** for its clarity and reliability. ### Solution 1: Use the Absolute Path (Highly Recommended) This is the best practice for solving this problem as it removes all environmental ambiguity. 1. **Find the Absolute Path to `docker`** Run the `which` command in your terminal: ```bash which docker ``` You will typically get an output like `/usr/local/bin/docker`. 2. **Modify Your Crontab** Use `crontab -e` to edit your job, replacing `docker` with its full, absolute path. **Before:** ```crontab docker exec ee-php-fpm-8.4.13 ... ``` **After:** ```crontab */2 * * * * /usr/local/bin/docker exec ee-php-fpm-8.4.13 php /eeBox/eeProject/app/public/index.php '/data-import/import?source=all' >> /var/log/wiki.lib00/api_import.log 2>&1 ``` ### Solution 2: Define `PATH` in the Crontab File If you have multiple cron jobs that depend on commands in non-standard paths, you can define the `PATH` variable at the top of your crontab file. 1. Run `crontab -e`. 2. Add a line at the very top that defines a `PATH` including all necessary directories. ```crontab PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin */2 * * * * docker exec ee-php-fpm-8.4.13 php ... ``` All subsequent jobs in the file will inherit this more complete `PATH`. ### Solution 3: Wrap the Command in a Shell Script For complex commands or long command chains, wrapping them in a dedicated shell script is a cleaner and more maintainable approach. 1. **Create a Script File** Create a file named `run_import_from_lib00.sh`. ```bash #!/bin/sh # Ensure the PATH includes the directory for docker export PATH="/usr/local/bin:/usr/bin:/bin:$PATH" # Define the log file LOG_FILE="/var/log/wiki.lib00/api_import.log" # Execute your Docker command /usr/local/bin/docker exec ee-php-fpm-8.4.13 php /eeBox/eeProject/app/public/index.php '/data-import/import?source=all' >> "$LOG_FILE" 2>&1 ``` 2. **Make It Executable** ```bash chmod +x /path/to/your/run_import_from_lib00.sh ``` 3. **Update Your Crontab** Now, your cron job simply needs to call this script. ```crontab */2 * * * * /path/to/your/run_import_from_lib00.sh ``` --- ## Conclusion The `command not found` error in `cron` is almost always caused by a `PATH` environment mismatch. While several solutions exist, **using the absolute path to the command** is the most direct and foolproof method. Understanding the environmental differences between `cron` and your interactive shell is a key step toward becoming a more effective system administrator or developer. We hope this guide from DP@lib00 helps you resolve this issue quickly.