Linux ошибки crontab

Где хранится информация о запуске заданий по расписанию? Для проверки используем Ubuntu Linux 12.04/14.04 LTS сервер. Как проверит, запущен ли cron и правильно ли он работает?

Как проверить запущен ли cron (планировщик заданий)? Используйте команду pgrep  или ps

Результат

Так же вы можете проверить файл /var/log/syslog используя команду grep что бы получить информации о работе планировщика cron

Результат:

Где хранятся журналы работы cron на Ubuntu Linux?

Журналы хранятся в файле /var/log/cron.log. Вы можете настроить его следующим образом. Редактировать /etc/rsyslog.d/50-default.conf файл с помощью текстового редактора, например, vi или nano:

или

Найдите строку

Необходимо её раскомментировать, и перезапустить оба сервиса:

Теперь все сообщения об ошибках в работе планировщика можно будет просматривать в файле

Воспользуйтесь различными командами для поиска нужной информации в логе

 Предоставляем уcлуги администрирования серверов Linux Ububtu

Нет похожих статей.

As others have pointed out, cron will email you the output of any program it runs (if there is any output). So, if you don’t get any output, there are basically three possibilities:

1. crond could not even start a shell for running the program or sending email
2. crond had troubles mailing the output, or the mail was lost.
3. the program did not produce any output (including error messages)

Case 1. is very unlikely, but something should have been written in the cron logs. Cron has an own reserved syslog facility, so you should have a look into /etc/syslog.conf (or the equivalent file in your distro) to see where messages of facility cron are sent. Popular destinations include /var/log/cron, /var/log/messages and /var/log/syslog.

In case 2., you should inspect the mailer daemon logs: messages from the Cron daemon usually appear as from root@yourhost. You can use a MAILTO=... line in the crontab file to have cron send email to a specific address, which should make it easier to grep the mailer daemon logs. For instance:

MAILTO=my.offsite.email@example.org
00 15 * * *  echo "Just testing if crond sends email"

In case 3., you can test if the program was actually run by appending another command whose effect you can easily check: for instance,

00 15 * * * /a/command; touch /tmp/a_command_has_run

so you can check if crond has actually run something by looking at
the mtime of /tmp/a_command_has_run.

How to fix all of your crontab related woes/problems (Linux)

---

This is a community wiki, if you notice anything incorrect with this answer or have additional information then please edit it.

---

First, basic terminology:

• cron(8) is the daemon that executes scheduled commands.
• crontab(1) is the program used to modify user crontab(5) files.
• crontab(5) is a per user file that contains instructions for cron(8).

Next, education about cron:

Every user on a system may have their own crontab file. The location of the root and user crontab files are system dependant but they are generally below /var/spool/cron.

There is a system-wide /etc/crontab file, the /etc/cron.d directory may contain crontab fragments which are also read and actioned by cron. Some Linux distributions (eg, Red Hat) also have /etc/cron.{hourly,daily,weekly,monthly} which are directories, scripts inside which will be executed every hour/day/week/month, with root privilege.

root can always use the crontab command; regular users may or may not be granted access. When you edit the crontab file with the command crontab -e and save it, crond checks it for basic validity but does not guarantee your crontab file is correctly formed. There is a file called cron.deny which will specify which users cannot use cron. The cron.deny file location is system dependent and can be deleted which will allow all users to use cron.

If the computer is not powered on or crond daemon is not running, and the date/time for a command to run has passed, crond will not catchup and run past queries.

crontab particulars, how to formulate a command:

A crontab command is represented by a single line. You cannot use to extend a command over multiple lines. The hash (#) sign represents a comment which means anything on that line is ignored by cron. Leading whitespace and blank lines are ignored.

Be VERY careful when using the percent (%) sign in your command. Unless they are escaped % they are converted into newlines and everything after the first non-escaped % is passed to your command on stdin.

There are two formats for crontab files:

• User crontabs

   # Example of job definition:
   # .---------------- minute (0 - 59)
   # |  .------------- hour (0 - 23)
   # |  |  .---------- day of month (1 - 31)
   # |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
   # |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7)
   # |  |  |  |  |
   # *  *  *  *  *   command to be executed
  

• System wide /etc/crontab and /etc/cron.d fragments

   # Example of job definition:
   # .---------------- minute (0 - 59)
   # |  .------------- hour (0 - 23)
   # |  |  .---------- day of month (1 - 31)
   # |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
   # |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7)
   # |  |  |  |  |
   # *  *  *  *  * user-name  command to be executed
  

Notice that the latter requires a user-name. The command will be run as the named user.

The first 5 fields of the line represent the time(s) when the command should be run.
You can use numbers or where applicable day/month names in the time specification.

• The fields are separated by spaces or tabs.
• A comma (,) is used to specify a list e.g 1,4,6,8 which means run at 1,4,6,8.
• Ranges are specified with a dash (-) and may be combined with lists e.g. 1-3,9-12 which means between 1 and 3 then between 9 and 12.
• The / character can be used to introduce a step e.g. 2/5 which means starting at 2 then every 5 (2,7,12,17,22…). They do not wrap past the end.
• An asterisk (*) in a field signifies the entire range for that field (e.g. 0-59 for the minute field).
• Ranges and steps can be combined e.g. */2 signifies starting at the minimum for the relevant field then every 2 e.g. 0 for minutes( 0,2…58), 1 for months (1,3 … 11) etc.

Debugging cron commands

Check the mail!

By default cron will mail any output from the command to the user it is running the command as. If there is no output there will be no mail. If you want cron to send mail to a different account then you can set the MAILTO environment variable in the crontab file e.g.

MAILTO=user@somehost.tld
1 2 * * * /path/to/your/command

Capture the output yourself

You can redirect stdout and stderr to a file. The exact syntax for capturing output may vary depending on what shell cron is using. Here are two examples which save all output to a file at /tmp/mycommand.log:

1 2 * * * /path/to/your/command &>/tmp/mycommand.log
1 2 * * * /path/to/your/command >/tmp/mycommand.log 2>&1

Look at the logs

Cron logs its actions via syslog, which (depending on your setup) often go to /var/log/cron or /var/log/syslog.

If required you can filter the cron statements with e.g.

grep CRON /var/log/syslog 

Now that we’ve gone over the basics of cron, where the files are and how to use them let’s look at some common problems.

Check that cron is running

If cron isn’t running then your commands won’t be scheduled …

ps -ef | grep cron | grep -v grep

should get you something like

root    1224   1  0 Nov16 ?    00:00:03 cron

or

root    2018   1  0 Nov14 ?    00:00:06 crond

If not restart it

/sbin/service cron start

or

/sbin/service crond start

There may be other methods; use what your distro provides.

cron runs your command in a restricted environment.

What environment variables are available is likely to be very limited. Typically, you’ll only get a few variables defined, such as $LOGNAME, $HOME, and $PATH.

Of particular note is the PATH is restricted to /bin:/usr/bin. The vast majority of «my cron script doesn’t work» problems are caused by this restrictive path. If your command is in a different location you can solve this in a couple of ways:

1. Provide the full path to your command.

    1 2 * * * /path/to/your/command
   

2. Provide a suitable PATH in the crontab file

    PATH=/bin:/usr/bin:/path/to/something/else
    1 2 * * * command 
   

If your command requires other environment variables you can define them in the crontab file too.

cron runs your command with cwd == $HOME

Regardless of where the program you execute resides on the filesystem, the current working directory of the program when cron runs it will be the user’s home directory. If you access files in your program, you’ll need to take this into account if you use relative paths, or (preferably) just use fully-qualified paths everywhere, and save everyone a whole lot of confusion.

The last command in my crontab doesn’t run

Cron generally requires that commands are terminated with a new line. Edit your crontab; go to the end of the line which contains the last command and insert a new line (press enter).

Check the crontab format

You can’t use a user crontab formatted crontab for /etc/crontab or the fragments in /etc/cron.d and vice versa. A user formatted crontab does not include a username in the 6th position of a row, while a system formatted crontab includes the username and runs the command as that user.

I put a file in /etc/cron.{hourly,daily,weekly,monthly} and it doesn’t run

• Check that the filename doesn’t have an extension see run-parts
• Ensure the file has execute permissions.
• Tell the system what to use when executing your script (eg. put #!/bin/sh at top)

Cron date related bugs

If your date is recently changed by a user or system update, timezone or other, then crontab will start behaving erratically and exhibit bizarre bugs, sometimes working, sometimes not. This is crontab’s attempt to try to «do what you want» when the time changes out from underneath it. The «minute» field will become ineffective after the hour is changed. In this scenario, only asterisks would be accepted. Restart cron and try it again without connecting to the internet (so the date doesn’t have a chance to reset to one of the time servers).

Percent signs, again

To emphasise the advice about percent signs, here’s an example of what cron does with them:

# cron entry
* * * * * cat >$HOME/cron.out%foo%bar%baz

will create the ~/cron.out file containing the 3 lines

foo
bar
baz

This is particularly intrusive when using the date command. Be sure to escape the percent signs

* * * * * /path/to/command --day "$(date "+%Y%m%d")"

How to use sudo in cron jobs

when running as a non-root user,

crontab -e

will open the user’s crontab, while

sudo crontab -e

will open the root user’s crontab. It’s not recommended to run sudo commands in a cron job, so if you’re trying to run a sudo command in a user’s cron, try moving that command to root’s cron and remove sudo from the command.

The cron scheduler has been bundled with Unix and Linux operating systems for decades. It’s widely used, and usually very reliable. However, when something goes wrong with cron, it can be difficult to debug.

This guide will walk you through locating cron jobs on your server, validating their schedules, and debugging common runtime problems.

Why cron jobs fail

Cron jobs can fail for a variety of reasons, but at Cronitor we have observed common failure patterns that can provide a useful starting point for your debugging process. In the rest of this guide, we will dive into these common failures with suggestions and solutions.

If you’re adding a new cron job and it is not working…

• Schedule errors are easy to make

  Cron job schedule expressions are quirky and difficult to write. If your job didn’t run when you expected it to, the easiest thing to rule out is a mistake with the cron expression.

• Cron has subtle environment differences

  A common experience is to have a job that works flawlessly when run at the command line but fails whenever it’s run by cron. When this happens, eliminate these common failures:

  1. The command has an unresovable relative path like ../scripts. (Try an absolute path)
  2. The job uses environment variables. (Cron does not load .bashrc and similar files)
  3. The command uses advanced bash features (cron uses /bin/sh by default)

  Tip:Our free software, CronitorCLI, includes a shell command to test run any job the way cron does.

• There is a problem with permissions

  Invalid permissions can cause your cron jobs to fail in at least 3 ways. This guide will cover them all.

If your cron job stopped working suddenly…

• System resources have been depleted

  The most stable cron job is no match for a disk that is full or an OS that can’t spawn new threads. Check all the usual graphs to rule this out.

• You’ve reached an inflection point

  Cron jobs are often used for batch processing and other data-intensive tasks that can reveal the constraints of your stack. Jobs often work fine until your data size grows to a point where queries start timing-out or file transfers are too slow.

• Infrastructure drift occurs

  When app configuration and code changes are deployed it can be easy to overlook the cron jobs on each server. This causes infrastructure drift where hosts are retired or credentials change that break the forgotten cron jobs.

• Jobs have begun to overlap themselves

  Cron is a very simple scheduler that starts a job at the scheduled time, even if the previous invocation is still running. A small slow-down can lead to a pile-up of overlapped jobs sucking up available resources.

• A bug has been introduced

  Sometimes a failure has nothing to do with cron. It can be difficult to thoroughly test cron jobs in a development environment and a bug might exist only in production.

How to fix a cron job not running on schedule

You may find that you have scheduled a cron job that is just not running when expected. Follow these steps to locate your scheduled job and diagnose the problem.

1. Locate the scheduled job

Tip: If you know where your job is scheduled, skip this step

Cron jobs are run by a system daemon called crond that watches several locations for scheduled jobs. The first step to understanding why your job didn’t start when expected is to find where your job is scheduled.

Search manually for cron jobs on your server

• Check your user crontab with crontab -l

  dev01: ~ $ crontab -l
  # Edit this file to introduce tasks to be run by cron.
  # m h  dom mon dow   command
  5 4 * * *      /var/cronitor/bin/database-backup.sh
  

• Jobs are commonly created by adding a crontab file in /etc/cron.d/
• System-level cron jobs can also be added as a line in /etc/crontab
• Sometimes for easy scheduling, jobs are added to /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ or /etc/cron.monthly/
• It’s possible that the job was created in the crontab of another user. Go through each user’s crontab using crontab -u username -l

Or, scan for cron jobs automatically with CronitorCLI

• Install CronitorCLI for free

  Step 1 of 2: Enter your email address for your free CronitorCLI download:

  Download CronitorCLI

  Step 2 of 2: Download CronitorCLI directly from your server:

  • Linux
  • MacOS

  Paste each instruction into a terminal and execute.

  wget https://cronitor.io/dl/linux_amd64.tar.gz
  sudo tar xvf linux_amd64.tar.gz -C /usr/local/bin/
  sudo cronitor configure --api-key {{ api_key }} #optional
  

  Paste each instruction into a terminal and execute.

  curl -sOL https://cronitor.io/dl/darwin_amd64.tar.gz
  sudo tar xvf darwin_amd64.tar.gz -C /usr/local/bin
  sudo cronitor configure --api-key {{ api_key }} #optional
  

• Run cronitor list to scan your system for cron jobs:

  

If you can’t find your job but believe it was previously scheduled double check that you are on the correct server.

2. Validate your job schedule

Once you have found your job, verify that it’s scheduled correctly. Cron schedules are commonly used because they are expressive and powerful, but like regular expressions can sometimes be difficult to read. We suggest using Crontab Guru to validate your schedule.

* Paste the schedule expression from your crontab into the text field on Crontab Guru * Verify that the plaintext translation of your schedule is correct, and that the next scheduled execution times match your expectations * Check that the effective server timezone matches your expectation. In addition to checking system time using date, check your crontab file for TZ or CRON_TZ timezone declarations that would override system settings. For example, CRON_TZ=America/New_York

3. Check your permissions

Invalid permissions can cause your cron jobs to fail in at least 3 ways:

1. Jobs added as files in a /etc/cron.*/ directory must be owned by root. Files owned by other users will be ignored and you may see a message similar to WRONG FILE OWNER in your syslog. 2. The command must be executable by the user that cron is running your job as. For example if your ubuntu user crontab invokes a script like database-backup.sh, ubuntu must have permission to execute the script. The most direct way is to ensure that the ubuntu user owns the file and then ensure execute permissions are available using chmod +x database-backup.sh. 3. The user account must be allowed to use cron. First, if a /etc/cron.allow file exists, the user must be listed. Separately, the user cannot be in a /etc/cron.deny list.

Related to the permissions problem, ensure that if your command string contains a % that it is escaped with a backslash.

4. Check that your cron job is running by finding the attempted execution in syslog

When cron attempts to run a command, it logs it in syslog. By grepping syslog for the name of the command you found in a crontab file you can validate that your job is scheduled correctly and cron is running.

• Begin by grepping for the command in /var/log/syslog (You will probably need root or sudo access.)

  dev01: ~ $ grep database-backup.sh /var/log/syslog
  Aug  5 4:05:01 dev01 CRON[2128]: (ubuntu) CMD (/var/cronitor/bin/database-backup.sh)
  

• If you can’t find your command in the syslog it could be that the log has been rotated or cleared since your job ran. If possible, rule that out by updating the job to run every minute by changing its schedule to * * * * *.
• If your command doesn’t appear as an entry in syslog within 2 minutes the problem could be with the underlying cron daemon known as crond. Rule this out quickly by verifying that cron is running by looking up its process ID. If cron is not running no process ID will be returned.

  dev01: ~ $ pgrep cron
  323
  

• If you’ve located your job in a crontab file but persistently cannot find it referenced in syslog, double check that crond has correctly loaded your crontab file. The easiest way to do this is to force a reparse of your crontab by running EDITOR=true crontab -e from your command prompt. If everything is up to date you will see a message like No modification made. Any other message indicates that your crontab file was not reloaded after a previous update but has now been updated. This will also ensure that your crontab file is free of syntax errors.

If you can see in syslog that your job was scheduled and attempted to run correctly but still did not produce the expected result you can assume there is a problem with the command you are trying to run.

How to debug unexpected cron job failures

Your cron jobs, like every other part of your system, will eventually fail. This section will walk you through testing your job and spotting common failures.

1. Test run your command like cron does

When cron runs your command the environment is different from your normal command prompt in subtle but important ways. The first step to troubleshooting is to simulate the cron environment and run your command in an interactive shell.

Run any command like cron does with CronitorCLI

• Install CronitorCLI for free

  Step 1 of 2: Enter your email address for your free CronitorCLI download:

  Download CronitorCLI

  Step 2 of 2: Download CronitorCLI directly from your server:

  • Linux
  • MacOS

  Paste each instruction into a terminal and execute.

  wget https://cronitor.io/dl/linux_amd64.tar.gz
  sudo tar xvf linux_amd64.tar.gz -C /usr/local/bin/
  sudo cronitor configure --api-key {{ api_key }} #optional
  

  Paste each instruction into a terminal and execute.

  curl -sOL https://cronitor.io/dl/darwin_amd64.tar.gz
  sudo tar xvf darwin_amd64.tar.gz -C /usr/local/bin
  sudo cronitor configure --api-key {{ api_key }} #optional
  

• To force a scheduled cron job to run immediately, use cronitor select to scan your system and present a list of jobs to choose from.

• To simulate running any command the way cron does, use cronitor shell:

  

Or, manually test run a command like cron does

• If you are parsing a file in /etc/cron.d/ or /etc/crontab each line is allowed to have an effective «run as» username after the schedule and before the command itself. If this applies to your job, or if your job is in another user’s crontab, begin by opening a bash prompt as that user sudo -u username bash
• By default, cron will run your command using /bin/sh, not the bash or zsh prompt you are familiar with. Double check your crontab file for an optional SHELL=/bin/bash declaration. If using the default /bin/sh shell, certain features that work in bash like [[command]] syntax will cause syntax errors under cron.
• Unlike your interactive shell, cron doesn’t load your bashrc or bash_profile so any environment variables defined there are unavailable in your cron jobs. This is true even if you have a SHELL=/bin/bash declaration. To simulate this, create a command prompt with a clean environment.

  dev01: ~ $ env -i /bin/sh
  

• By default, cron will run commands with your home directory as the current working directory. To ensure you are running the command like cron does, run cd ~ at your prompt.
• Paste the command to run (everything after the schedule or declared username) into the command prompt. If crontab is unable to run your command, this should fail too and will hopefully contain a useful error message. Common errors include invalid permissions, command not found, and command line syntax errors.
• If no useful error message is available, double check any application logs your job is expected to produce, and ensure that you are not redirecting log and error messages. In linux, command >> /path/to/file will redirect console log messages to the specified file and command >> /path/to/file 2>&1 will redirect both the console log and error messages. Determine if your command has a verbose output or debug log flag that can be added to see additional details at runtime.
• Ideally, if your job is failing under cron it will fail here too and you will see a useful error message, giving you a chance to modify and debug as needed. Common errors include file not found, misconfigured permissions, and commandline syntax errors.

2. Check for overlapping jobs

At Cronitor our data shows that runtime durations increase over time for a large percentage of cron jobs. As your dataset and user base grows it’s normal to find yourself in a situation where cron starts an instance of your job before the previous one has finished. Depending on the nature of your job this might not be a problem, but several undesired side effects are possible:

• Unexpected server or database load could impact other users

• Locking of shared resources could cause deadlocks and prevent your jobs from ever completing successfully

• Creation of an unanticipated race condition that might result in records being processed multiple times, amplifying server load and possibly impacting customers

  To verify if any instances of a job are running on your server presently, grep your process list. In this example, 3 job invocations are running simultaneously:

  dev01: ~ $ ps aux | grep database-backup.sh
  ubuntu           1343   0.0  0.1  2585948  12004   ??  S    31Jul18   1:04.15 /var/cronitor/bin/database-backup.sh
  ubuntu           3659   0.0  0.1  2544664    952   ??  S     1Aug18   0:34.35 /var/cronitor/bin/database-backup.sh
  ubuntu           7309   0.0  0.1  2544664   8012   ??  S     2Aug18   0:18.01 /var/cronitor/bin/database-backup.sh
  

To quickly recover from this, first kill the overlapping jobs and then watch closely when your command is next scheduled to run. It’s possible that a one time failure cascaded into several overlapping instances. If it becomes clear that the job often takes longer than the interval between job invocations you may need to take additional steps, e.g.:

• Increase the duration between invocations of your job. For example if your job runs every minute now, consider running it every other minute.
• Use a tool like flock to ensure that only a single instance of your command is running at any given time. Using flock is easy. After installing from apt-get or yum you only need to prefix the command in your crontab:

  dev01: ~ $ crontab -l
  # Edit this file to introduce tasks to be run by cron.
  # m h  dom mon dow   command
  * * * * *      flock -w 0 /var/cronitor/bin/database-backup.sh
  

Read more about flock from the man page.

What to do if nothing else works

Here are a few things you can try if you’ve followed this guide and find that your job works flawlessly when run from the cron-like command prompt but fails to complete successful under crontab.

• First get the most basic cron job working with a command like date >> /tmp/cronlog. This command will simply echo the execution time to the log file each time it runs. Schedule this to run every minute and tail the logfile for results.

• If your basic command works, replace it with your command. As a sanity check, verify if it works.

• If your command works by invoking a runtime like python some-command.py perform a few checks to determine that the runtime version and environment is correct. Each language runtime has quirks that can cause unexpected behavior under crontab.

  • For python you might find that your web app is using a virtual environment you need to invoke in your crontab.
  • For node a common problem is falling back to a much older version bundled with the distribution.
  • When using php you might run into the issue that custom settings or extensions that work in your web app are not working under cron or commandline because a different php.ini is loaded.

  If you are using a runtime to invoke your command double check that it’s pointing to the expected version from within the cron environment.

• If nothing else works, restart the cron daemon and hope it helps, stranger things have happened. The way to do this varies from distro to distro so it’s best to ask google.