Member Avatar for mmcdonald

Hi all,

I'm using crontab on Ubuntu 10.04 and I have had 7 tasks running smoothly for about 6 months. I've now created a new script but for some frustrating reason it will be execute. It's a small task that needs to run every two minutes. The issue doesn't reside with the code as if I execute the script manually it works perfectly. The script is written in PHP and I'm running Apache2.

This works fine:
*/5 * * * * php -q /var/tasks/PEQ.php

This does not:
*/2 * * * * php -q /var/tasks/SSC.php

There are no errors being reported by the script, which has error reporting on, and there are no errors being logged by crontab.

Any ideas?

Thanks in advance!

  • 3 Contributors
  • 2 Replies
  • 274 Views
  • 4 Hours Discussion Span
  • Latest Post Latest Post by CimmerianX

Dani AI

Generated

For — cron runs jobs in a very different environment than an interactive shell, so "works when run manually" is expected to be an unreliable test. 's logging idea and 's shebang/permission point are both on-target. Below are compact, practical steps that expose the usual culprits (environment, working directory, permissions, line endings, includes) and a robust crontab pattern to capture failures.

Reproduce the cron environment (runs PHP with almost-no environment — if this fails, the script depends on env vars or relative paths):

env -i HOME=/home/USERNAME PATH=/usr/bin:/bin /usr/bin/php -f /var/tasks/SSC.php

Use a crontab entry that is explicit about the interpreter, working directory and captures stdout/stderr to a log:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
*/2 * * * * cd /var/tasks && /usr/bin/php -f SSC.php >> /var/log/ssc-cron.log 2>&1

Why this helps: cd fixes relative-include problems, the full /usr/bin/php avoids PATH surprises, and redirecting both streams makes hidden errors visible. Additional checks: verify file ownership/permissions with ls -l /var/tasks/SSC.php; ensure the script doesn't rely on Apache-only globals (no $_SERVER assumptions); run file /var/tasks/SSC.php / dos2unix if Windows CRLF or a BOM might be present; and confirm cron actually tried to run the job by scanning syslog (grep CRON /var/log/syslog) or by checking the log created above.

Note: percent signs in crontab are special and must be escaped. If these steps still show nothing in the log, run the env‑isolated command above and capture its output to identify the missing environment or failing include.

Recommended Answers

All 2 Replies

Member Avatar for dorco

are you sure that is not executing?
add log msg at the top of your script:

file_put_contents("/tmp/log.txt", "script executed on " . date('Y-m-d H:i:s'));

then check if the file exists in /tmp

Member Avatar for CimmerianX

To you have the script language defined in the 1st line to be php? From command line, do you just run './SSC.php' and it runs or do you pass it into the scripting language module? Does the script have new external commands that require permissions that the id running this cron doesn't have?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.