Why Doesn't My Cron Job Work Properly

Why Doesn't My Cron Job Work Properly?

Are you sure the temporary file is being created correctly when running as a cron job? The working directory for your script will either be specified in the HOME environment variable, or the /etc/passwd entry for the user that installed the cron job. If deploy does not have write permissions for the directory in which it is executing, then you could specify an absolute path for the dump file to fix the problem.

CronJob not running

Finally I found the solution. Following is the solution:-

1. Never use relative path in python scripts to be executed via crontab.
   I did something like this instead:-

   import os
   import sys
   import time, datetime
   
   CLASS_PATH = '/srv/www/live/mainapp/classes'
   SETTINGS_PATH = '/srv/www/live/foodtrade'
   sys.path.insert(0, CLASS_PATH)
   sys.path.insert(1,SETTINGS_PATH)
   
   import other_py_files
   

2. Never supress the crontab code instead use mailserver and check the mail for the user. That gives clearer insights of what is going.

What is preventing my cron job from running

sudo

The sudo command may not work in a crontab. Generally you need a password to run sudo but there might be a way to have it run without a password when running in a cron job. This would not be recommended however to attempt.

cron

You'll need to run the cron as a user that has access to do what you need to accomplish. Cron runs with a short list of specific paths. By default that list is pretty short. On a linux box I use the path is /sbin:/usr/sbin:/bin:/usr/bin.

Also, the paths need to be more specific. Cron doesn't run as a normal user so you have to be more specific with paths and output of those commands.

For instance, on the first command, where will the gzip file be placed?

logrotate

It looks like you're trying to zip a log file, then move log files, then remove old log files - this is exactly what logrotate accomplishes. It would be worth installing. Logrotate solves problems like the log file being opened when you run this command - generally the process that has the log file opened doesn't lose the file handle even if you rename it so the log continues to be written to even after you move it. It also handles the problem of keeping an archive of the recent log files, like syslog.1.gz, syslog.2.gz, syslog.x.gz or as many back as you have storage space for or want to keep for posterity.

Summary

• Don't use sudo in cron
• Be specific in paths when running commands in cron
• Use logrotate to accomplish this specific task in your question

Cron Jobs Not Running at all, Working manually

The __DIR__ would give the script working directory so when using require it would always translate the path correctly

example:

<?php
define('DIR', __DIR__);
require_once(DIR.'../backend/backend.php');
?>

One of the cron jobs not running

cron always leaves logs: what does /var/log/cron say? do you see your entry there attempting to run?

When does machine come up after reboot? Is that a case of a really long reboot? Some scripts hold up the shutdown/startup?

Also check for other entries from the same timeframe in /var/log/cron.

Stab in the dark: is SELinux on? Based on your description it shouldn't matter, but for example if your machine starts with Enforcing mode yet something changes it to Permissive later on - that could be something to look into. So the state of /etc/sysconfig/selinux is important here, as well as output of "sestatus" command when you can successfully execute your job by adjusting the time.

Looking at /var/log/audit/audit.log may shed some light on it in case of SELinux issues.

Last thing: simplify the problem and instead of "special" scripts - create "dummy" scripts:

00 21 * * 0,2,4 reboot
30 21 * * 0,2,4 touch /tmp/foo

now if /tmp/foo doesn't exist - something is screwed with the system, otherwise it must be some logic in scripts that is failing (lock files etc.) There is no reason cron wouldn't run job on account of reboot. That would prevent all other cron jobs from ever firing.

Cron Job Doesn't Run

The cronjob is running just fine, but the cron daemon (daemons in general as far as I know) have no access to stdout so cannot output messages to the terminal.

To test it you can, however, output what you want to a file using

*/1 * * * * echo "job every minute" >>$HOME/filename

which will output (and concatenate) the text to a file named "filename" in your home directory every minute.

why do some if tests not work in my cron scripts

It sounds like you are running the script with bash, while cron is running it under some other shell; thus, all of the bash extensions you're using are failing. Make sure the shebang on your script (i.e. the first line) requests bash (#!/bin/bash), and that the cron entry runs it directly rather than specifying a shell (e.g. 0 0 * * * /path/to/script NOT 0 0 * * * /bin/sh /path/to/script).

EDIT: there are several different ways of controlling which shell will be used to interpret a script, with a definite precedence order:

1. If you run the script with an explicit shell (e.g. /bin/sh /path/to/script), the shell you told to run it will be used, and any shebang will be ignored.
2. If you run the script directly (e.g. /path/to/script or ./script, or place it in your PATH and run it as script), the system will use the shebang to determine which shell (or other interpreter) to run it with.
3. If you run it directly and there's no shebang, the program you're running it from (e.g. bash, sh, or crond) might choose to do something else. In this situation, bash will run the script with bash. I'm not sure what crond will do, and it might even depend on which version it is.

In general, using a proper shebang and running the script directly is the best way to go; the script should "know" what the proper interpreter is, and that should be respected. For example, if you write a script in portable shell code (with a #!/bin/sh shebang), and then later need to use some bash-only features, you can simply change the shebang and not have to track down all the places it's run from.

Specifying the shell explicitly should be reserved for cases where the shebang is wrong or missing (in which case the better solution is to fix the script), or you don't have execute permission (again, fix the script). The third option is an unreliable fallback, and should be avoided whenever possible.

P.s. If I'm reading your last comment (above) correctly, you want to test whether $line contains "downloads.php", not whether it equals that; but the [ x == y] comparison tests for equality, not containment. To test for containment, use the bash-only [[ string == pattern ]] form:

if [[ "$line" == *"downloads.php"* ]]

PHP Include Not Working in Cron Job

I had several problems running cron scripts from Cpanel with absolute paths (when having includes) and ended up changing to executing them as URL's, now everything is working fine:

My command

wget -O /dev/null http://www.example.com/somescript > /dev/null 2>&1

---

Related Topics