Cron Troubleshooting: Manual vs Scheduled Runs

A website report is generated when an administrator runs the script in a terminal, but the scheduled result never appears. The first reaction is to change the hours or grant the process more permissions. Yet cron may be running the correct command in a different environment. Cron troubleshooting starts by separating two situations: the job never starts, or it starts but behaves differently from a manual run.

Below is a learning scenario for Linux with traditional cron and the /bin/sh shell. It does not describe a real client incident or install a new schedule. You need a terminal, a text editor and your own test directory. Python is only looked up as a program; no Python code needs to execute. Do not repeat genuine email delivery, charges or synchronisation merely to test them: those actions can create duplicates.

Establish what the scheduler actually runs

Take the exact command from the agreed configuration or hosting panel. Record the job owner, server time zone and expected run time. Do not mechanically transfer a line between a user’s crontab and a system file: their formats may differ. Also check whether cron, a control panel or another scheduler manages the job; a colleague calling it “cron” does not establish that.

The Debian crontab reference describes the execution user, shell and command-line rules. In particular, the percent sign has a special meaning in that implementation. If a command contains date formatting with percent signs, check your scheduler’s actual rules. Do not blindly copy an example for another system. For containers and systemd timers, the environment test below remains a diagnostic clue, not instructions for configuring their schedules.

Separate the message “the scheduler launched the command” from confirmation of its outcome. A start record does not prove that the required file was created. Equally, a missing expected file does not prove that nothing ran. Ask the administrator for an available execution record and completion status without secrets. Until those facts exist, the cause remains a hypothesis rather than an established cron fault.

Observe the difference without production data access

Create check-context.sh in your own test directory with the following content. Create an empty input.txt beside it using the editor. Both names are illustrative. The script only displays the working directory, looks up python3 and checks the test file’s accessibility; it neither reads its contents nor changes settings. Running it through /bin/sh does not require granting the file execute permission.

#!/bin/sh
printf 'working_directory: '
pwd
printf 'python_lookup: '
command -v python3 || printf 'not found\n'
if [ -r ./input.txt ]; then
    printf 'relative_input: readable\n'
else
    printf 'relative_input: missing or unreadable\n'
fi

Run the two commands below from that same directory. The first uses the terminal’s current environment. The second runs the diagnostic with a cleared environment and an explicitly shortened PATH. This is an approximation for testing dependencies, not an exact reproduction of cron. Here, PATH is a parameter for the child process only; do not change global shell or system settings for the exercise.

/bin/sh ./check-context.sh
env -i PATH=/usr/bin:/bin /bin/sh ./check-context.sh

Compare the three output lines. If python3 is found only during the first run, the manual session has an additional program search path. If both runs locate the same interpreter, that is useful too: this check found no difference. Do not declare PATH responsible without confirmation. The GNU env documentation describes env -i; it does not automatically reproduce every condition of a background process.

Check the directory separately from the environment

Now open a terminal in another directory you own and run the script using its absolute path. The /srv/cron-demo path below is illustrative: replace it with the real path to your test folder. Do not create a system directory merely to match the example. The shell must exist and the script must remain readable; administrator permissions are unnecessary.

/bin/sh /srv/cron-demo/check-context.sh

Expect working_directory to show the directory from which you launched the shell. The input.txt file beside the script may now be reported as unavailable, because ./input.txt refers to the process’s current directory, not the script’s location. This explains why fixing one absolute program path does not necessarily repair data access. Check both dependencies separately before changing the schedule.

For the real job, agree on a working directory or use explicit paths to the required files. Check the actual interpreter and its dependencies, not just the command name. If the script needs application variables, supply them through the project’s intended secure mechanism. Do not print the entire env output into a log: it may contain tokens and passwords. Do not insert secrets directly into a schedule line or a support screenshot.

Make the fix testable and reversible

Check permissions as the agreed job user together with the administrator. Reading a script, traversing directories and writing output require different permissions. Do not address the error with chmod 777 or by running as root without a justified need. If the process cannot write the report, first confirm the destination directory and owner. The article on SSH configuration is relevant to arranging safe access.

Before changing the production command, preserve the previous configuration and test the specific fix on a copy. If adding a log, use a separate protected file, check disk space and define retention. Logging itself may fail because of permissions. Record the start, completion and a safe operation identifier; do not equate the absence of an error message with success. If rollback is needed, restore that particular previous command rather than disabling every server job.

Conclusion: confirm the start first, reproduce the directory and environment next, and only then fix the dependency identified. After the change, check the next agreed run and its actual output, not merely a green panel status. If manual and background execution still differ, AriZone can help compare the conditions and verify a targeted fix without risky repeated operations.