Why crontab scripts are not working?
Often, crontab
scripts are not executed on schedule or as expected. There are numerous reasons for that:
- wrong crontab notation
- permissions problem
- environment variables
This community wiki aims to aggregate the top reasons for crontab
scripts not being executed as expected. Write each reason in a separate answer.
Please include one reason per answer - details about why it's not executed - and fix(es) for that one reason.
Please write only cron-specific issues, e.g. commands that execute as expected from the shell but execute erroneously by cron.
cron
add a comment |
Often, crontab
scripts are not executed on schedule or as expected. There are numerous reasons for that:
- wrong crontab notation
- permissions problem
- environment variables
This community wiki aims to aggregate the top reasons for crontab
scripts not being executed as expected. Write each reason in a separate answer.
Please include one reason per answer - details about why it's not executed - and fix(es) for that one reason.
Please write only cron-specific issues, e.g. commands that execute as expected from the shell but execute erroneously by cron.
cron
10
You must closecrontab -e
for the cron to take affect. For instance using vim I edit the file and use:w
to write it but the job is not added to cron until I quit also. So I will not see the job until after I:q
also.
– DutGRIFF
Jun 24 '14 at 14:58
I think best way to debug cron is to check syslog and find the problems.
– Suneel Kumar
Jun 23 '16 at 7:49
In my case - the email was going to my SPAM folder, so..... check that before you spend hours on debugging :D
– almaruf
Nov 6 '17 at 14:54
Electricity outages
– Josef Klimuk
Mar 21 '18 at 7:38
add a comment |
Often, crontab
scripts are not executed on schedule or as expected. There are numerous reasons for that:
- wrong crontab notation
- permissions problem
- environment variables
This community wiki aims to aggregate the top reasons for crontab
scripts not being executed as expected. Write each reason in a separate answer.
Please include one reason per answer - details about why it's not executed - and fix(es) for that one reason.
Please write only cron-specific issues, e.g. commands that execute as expected from the shell but execute erroneously by cron.
cron
Often, crontab
scripts are not executed on schedule or as expected. There are numerous reasons for that:
- wrong crontab notation
- permissions problem
- environment variables
This community wiki aims to aggregate the top reasons for crontab
scripts not being executed as expected. Write each reason in a separate answer.
Please include one reason per answer - details about why it's not executed - and fix(es) for that one reason.
Please write only cron-specific issues, e.g. commands that execute as expected from the shell but execute erroneously by cron.
cron
cron
edited May 8 '17 at 18:15
community wiki
11 revs, 5 users 57%
Adam Matan
10
You must closecrontab -e
for the cron to take affect. For instance using vim I edit the file and use:w
to write it but the job is not added to cron until I quit also. So I will not see the job until after I:q
also.
– DutGRIFF
Jun 24 '14 at 14:58
I think best way to debug cron is to check syslog and find the problems.
– Suneel Kumar
Jun 23 '16 at 7:49
In my case - the email was going to my SPAM folder, so..... check that before you spend hours on debugging :D
– almaruf
Nov 6 '17 at 14:54
Electricity outages
– Josef Klimuk
Mar 21 '18 at 7:38
add a comment |
10
You must closecrontab -e
for the cron to take affect. For instance using vim I edit the file and use:w
to write it but the job is not added to cron until I quit also. So I will not see the job until after I:q
also.
– DutGRIFF
Jun 24 '14 at 14:58
I think best way to debug cron is to check syslog and find the problems.
– Suneel Kumar
Jun 23 '16 at 7:49
In my case - the email was going to my SPAM folder, so..... check that before you spend hours on debugging :D
– almaruf
Nov 6 '17 at 14:54
Electricity outages
– Josef Klimuk
Mar 21 '18 at 7:38
10
10
You must close
crontab -e
for the cron to take affect. For instance using vim I edit the file and use :w
to write it but the job is not added to cron until I quit also. So I will not see the job until after I :q
also.– DutGRIFF
Jun 24 '14 at 14:58
You must close
crontab -e
for the cron to take affect. For instance using vim I edit the file and use :w
to write it but the job is not added to cron until I quit also. So I will not see the job until after I :q
also.– DutGRIFF
Jun 24 '14 at 14:58
I think best way to debug cron is to check syslog and find the problems.
– Suneel Kumar
Jun 23 '16 at 7:49
I think best way to debug cron is to check syslog and find the problems.
– Suneel Kumar
Jun 23 '16 at 7:49
In my case - the email was going to my SPAM folder, so..... check that before you spend hours on debugging :D
– almaruf
Nov 6 '17 at 14:54
In my case - the email was going to my SPAM folder, so..... check that before you spend hours on debugging :D
– almaruf
Nov 6 '17 at 14:54
Electricity outages
– Josef Klimuk
Mar 21 '18 at 7:38
Electricity outages
– Josef Klimuk
Mar 21 '18 at 7:38
add a comment |
46 Answers
46
active
oldest
votes
1 2
next
Different environment
Cron passes a minimal set of environment variables to your jobs. To see the difference, add a dummy job like this:
* * * * * env > /tmp/env.output
Wait for /tmp/env.output
to be created, then remove the job again. Now compare the contents of /tmp/env.output
with the output of env
run in your regular terminal.
A common "gotcha" here is the PATH
environment variable being different. Maybe your cron script uses the command somecommand
found in /opt/someApp/bin
, which you've added to PATH
in /etc/environment
? cron ignores PATH
from that file, so runnning somecommand
from your script will fail when run with cron, but work when run in a terminal. It's worth noting that variables from /etc/environment
will be passed on to cron jobs, just not the variables cron specifically sets itself, such as PATH
.
To get around that, just set your own PATH
variable at the top of the script. E.g.
#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# rest of script follows
Some prefer to just use absolute paths to all the commands instead. I recommend against that. Consider what happens if you want to run your script on a different system, and on that system, the command is in /opt/someAppv2.2/bin
instead. You'd have to go through the whole script replacing /opt/someApp/bin
with /opt/someAppv2.2/bin
instead of just doing a small edit on the first line of the script.
You can also set the PATH variable in the crontab file, which will apply to all cron jobs. E.g.
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
15 1 * * * backupscript --incremental /home /root
5
I think I just fell for this, and newline at end... double whammy.
– WernerCD
Jun 2 '11 at 4:22
5
+1 forenv
, I had completely forgotten about that command and thought PATH was working. It was actually sliiiightly different in my case.
– Izkata
Jan 18 '12 at 15:16
8
@pbr If such directories are left writable to others, the system is already compromized.
– geirha
Apr 9 '12 at 8:23
6
@pbr A sysadmin could unwittingly delete the root filesystem. You can't guard against sysadmins making silly mistakes. If you install a newer version of an interpreter that is not backwards compatible, I'd expect breakage regardless. The sane way to handle that is to install it as a different command. E.g. you have python version 2.x and install python 3, you install it as python3, not python. And as for /opt/someApp/bin, why on earth wouldn't it have sane permissions/ownership? any sane admin would ensure sane permissions/ownership on system files.
– geirha
Apr 10 '12 at 6:36
2
@pbr It seems we could go on forever, yes. I still fail to see why it's a bad idea to use PATH though. If you feel like discussing this further in a medium better suited for discussion, you'll find me in #ubuntu and #bash, among other channels, on irc.freenode.net
– geirha
Apr 11 '12 at 16:28
|
show 20 more comments
My top gotcha: If you forget to add a newline at the end of the crontab
file. In other words, the crontab file should end with an empty line.
Below is the relevant section in the man pages for this issue (man crontab
then skip to the end):
Although cron requires that each entry in a crontab end in a newline
character, neither the crontab command nor the cron daemon will detect
this error. Instead, the crontab will appear to load normally. However,
the command will never run. The best choice is to ensure that your
crontab has a blank line at the end.
4th Berkeley Distribution 29 December 1993 CRONTAB(1)
77
this is such a showstopper, how come it hasn't been fixed in so many years of cron?
– Capi Etheriel
Jan 27 '11 at 3:20
2
Seems to be fixed in Vixie cron:man crontab
on Ubuntu 10.10 says "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." (And the date at the end is 19 April 2010.)
– Marius Gedminas
Feb 1 '11 at 22:58
18
@barraponto This is actually a bug in new text editors. The "newline" character is supposed to be a line termination character, so the final line in a text file is supposed to end in a newline character that doesn't get shown in the editor. Vi and vim use the character correctly, and cron was built before the new editors started their odd behavior... Hence playing it save and including a blank line.
– Izkata
Jan 18 '12 at 15:20
4
If you edit crontab usingcrontab -e
it will check the syntax of the file before allowing a save, including a check for newline.
– Tom Harrison Jr
Sep 26 '14 at 18:26
2
@Chan-HoSuh, according to man page "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." This behavior will be invoked when editing then saving the crontab using the-e
option, and is independent of the editor.
– Tom Harrison Jr
Nov 18 '14 at 16:40
|
show 7 more comments
Cron daemon is not running. I really screwed up with this some months ago.
Type:
pgrep cron
If you see no number, then cron is not running. sudo /etc/init.d/cron start
can be used to start cron.
EDIT: Rather than invoking init scripts through /etc/init.d, use the service
utility, e.g.
sudo service cron start
40
Thanks for showing me pgrep. I kept doing ps -ef | grep foo
– ripper234
Mar 17 '11 at 17:01
4
You could also usepidof cron
which will omit results for other applications that also have the word 'cron', like crontab.
– Pithikos
Mar 11 '14 at 16:19
Weird, all of these give me nothing to show cron is running, but if I runsudo service cron start
I getstart: Job is already running: cron
– Colleen
Apr 6 '15 at 17:04
1
service crond start
if its centos/RHEL
– Srihari Karanth
Jan 18 '17 at 10:02
add a comment |
The script filenames in cron.d/
, cron.daily/
, cron.hourly/
, etc., should not contain dot (.
), otherwise run-parts will skip them.
See run-parts(8):
If neither the --lsbsysinit option nor the --regex option is given then
the names must consist entirely of upper and lower case letters, dig‐
its, underscores, and hyphens.
If the --lsbsysinit option is given, then the names must not end in
.dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to
one or more of the following namespaces: the LANANA-assigned namespace
(^[a-z0-9]+$); the LSB hierarchical and reserved namespaces
(^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace
(^[a-zA-Z0-9_-]+$).
So, if you have a cron script backup.sh
, analyze-logs.pl
in cron.daily/
directory, you'd best to remove the extension names.
10
It's a feature not a bug - it keeps things like myscript.backup or myscript.original or myscript.rpm-new from running right beside myscript.
– pbr
Apr 8 '12 at 22:45
@pbr: makes sense. At least it would have been helpful for debugging ifrun-parts --test
(or another imaginary option like--debug
would output the files it skips including the reason.
– Rabarberski
May 30 '13 at 8:46
7
If this is a feature, it's not a nice one :( A lot of people use dot in file name (backup.sh is the most common one). If you want to a script to stop executing, the most logical method will be to remove it from "cron.d" directory.
– MatuDuke
May 16 '14 at 13:59
5
This is such a bad feature that it's effectively a bug. It's common practice to require a particular ending (like ".list" or ".cron" or something) if people want to make sure that things only get run when intended. Arbitrarily picking dot as a likely separator for ".bak" or ".temp" or whatever, is completely unpredictable except in the way that it will predictably confuse people. Legitimate endings like ".sh", and ".pl" have been in widespread use for decades. Lots of people use "_bak" or "_temp" or "-bak" instead of a dot, however. This is an awful design choice; it's a design bug at best.
– Teekin
May 10 '17 at 20:42
add a comment |
In many environments cron executes commands using sh
, while many people assume it will use bash
.
Suggestions to test or fix this for a failing command:
- Try running the command in
sh
to see if it works - Wrap the command in a bash subshell to make sure it gets run in bash:
bash -c "mybashcommand"
- Tell cron to run all commands in bash by setting the shell at the top of your crontab:
SHELL=/bin/bash
- If the command is a script, make sure the script contains a shebang:
#!/bin/bash
bash suggestion is very helpful, fixed issue with my cron.
– Maxim Galushka
Feb 18 '16 at 22:38
This just caused me 1hr of fiddling/troubleshooting. Even more perplexing if you're not aware of the issue is the script will run manually just fine if you're typical shell isbash
, but not withcron
. Thanks!
– Hendy
Nov 22 '16 at 19:42
A long time ago I ran into something related: The commandsource
is in bash but not sh. In cron/sh, use a period:. envfile
rather thansource envfile
.
– kungphu
Dec 22 '17 at 2:24
add a comment |
I had some issues with the time zones. Cron was running with the fresh installation time zone. The solution was to restart cron:
sudo service cron restart
6
Yes, after changing the timezone on a system, one must either restart every service that cares about what time it is, or reboot. I prefer the reboot, to be sure I've caught everything.
– pbr
Apr 8 '12 at 22:48
Oh for God's sake, killed hours on this. Tried service restart after* * * * * touch /tmp/cronworks
did nothing, yet there isRELOAD
at cronlog.
– НЛО
Oct 1 '14 at 3:57
add a comment |
Absolute path should be used for scripts:
For example, /bin/grep
should be used instead of grep
:
# m h dom mon dow command
0 0 * * * /bin/grep ERROR /home/adam/run.log &> /tmp/errors
Instead of:
# m h dom mon dow command
0 0 * * * grep ERROR /home/adam/run.log &> /tmp/errors
This is especially tricky, because the same command will work when executed from shell. The reason is that cron
does not have the same PATH
environment variable as the user.
3
see geirha answer, you can (must) define cron's PATH
– Capi Etheriel
Jan 27 '11 at 3:22
9
Bzzt. you do NOT need to define the PATH - using absolute paths is the best practice here. "because an executable may be elsewhere on some other computer" doesn't trump "I want it to run exactly this program and not some other one someone put in the path in front of my original program"
– pbr
Apr 8 '12 at 22:55
1
yep this was it for me, outside the cron I could run the command directly, inside the cron it needed full/usr/bin/whatever
path
– Anentropic
Aug 14 '16 at 10:56
add a comment |
If your crontab command has a %
symbol in it, cron tries to interpret it. So if you were using any command with a %
in it (such as a format specification to the date command) you will need to escape it.
That and other good gotchas here:
http://www.pantz.org/software/cron/croninfo.html
This is what has been causing my Cron job to fail for the last week. Finally figured out that my Date didn't have an escape character (backslash for any other folks looking for what the escape character is). Yay!
– Valien
Oct 14 '13 at 14:27
2
See also How can I executedate
inside of a cron tab job?
– Jared Beck
Apr 16 '15 at 20:49
This one bit me as well. Thanks!
– stefansundin
Jan 1 '17 at 21:54
add a comment |
It is also possible that the user's password has expired. Even root's password can expire. You can tail -f /var/log/cron.log
and you will see cron fail with password expired. You can set the password to never expire by doing this: passwd -x -1 <username>
In some systems (Debian, Ubuntu) logging for cron is not enabled by default. In /etc/rsyslog.conf or /etc/rsyslog.d/50-default.conf the line:
# cron.* /var/log/cron.log
should be edited (sudo nano /etc/rsyslog.conf
) uncommented to:
cron.* /var/log/cron.log
After that, you need to restart rsyslog via
/etc/init.d/rsyslog restart
or
service rsyslog restart
Source: Enable crontab logging in Debian Linux
In some systems (Ubuntu) separate logging file for cron is not enabled by default, but cron related logs are appearing in syslog file. One may use
cat /var/log/syslog | grep cron -i
to view cron-related messages.
I have Debian (wheezy) but there is no /etc/init.d/rsyslog, only inetutils-syslogd and sysklogd. Do I have to install something or just restart one of the two?
– hgoebl
Oct 21 '16 at 11:41
add a comment |
Cron is calling a script which is not executable.
By running chmod +x /path/to/scrip
the script becomes executable and should resolve this issue.
4
That's not unique tocron
, and easily traceable by simply trying to execute/path/to/script
from the command line.
– Adam Matan
Jan 27 '11 at 6:33
2
If you're used to executing scripts with. scriptname
orsh scriptname
orbash scriptname
, then this becomes acron
-specific problem.
– Eliah Kagan
Nov 24 '11 at 23:09
add a comment |
If your cronjob invokes GUI-apps, you need to tell them what DISPLAY they should use.
Example: Firefox launch with cron.
Your script should contain export DISPLAY=:0
somewhere.
aplay needed this one for some reason. thank you
– IljaBek
Oct 2 '16 at 10:47
* * * * * export DISPLAY=:0 && <command>
– LoMaPh
Jul 27 '17 at 22:27
add a comment |
Permissions problems are quite common, I'm afraid.
Note that a common workaround is to execute everything using root's crontab, which sometimes is a Really Bad Idea. Setting proper permissions is definitely a largely overlooked issue.
Note that if you have a crontab line that is set to pipe output to a file that does not yet exist, and the directory for the file is one that the cron user doesn't have access to, then the line will not execute.
– Evan Donovan
Sep 10 '15 at 16:51
add a comment |
Insecure cron table permission
A cron table is rejected if its permission is insecure
sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)
The problem is solved with
# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs
First I figured it out myself and then I found your answer! Still thanks a lot! In my case, I had reverted/restored some crontabs in /var/spool/cron/crontabs via SVN which changed its permissions!
– alfonx
Jun 8 '13 at 20:40
add a comment |
Script is location-sensitive. This is related to always using absolute paths in a script, but not quite the same. Your cron job may need to cd
to a specific directory before running, e.g. a rake task on a Rails application may need to be in the application root for Rake to find the correct task, not to mention the appropriate database configuration, etc.
So a crontab entry of
23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production
would be better as
23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production
Or, to keep the crontab entry simpler and less brittle:
23 3 * * * /home/<user>/scripts/session-purge.sh
with the following code in /home/<user>/scripts/session-purge.sh
:
cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production
1
If the script being invoked from cron is written in an interpreted language like PHP, you may need to set the working directory in the script itself. For example, in PHP:chdir(dirname(__FILE__));
– Evan Donovan
Sep 10 '15 at 16:14
Just got caught with this one: the script used to be in the root of my home directory, but then I moved it (and updated the crontab) and couldn't figure out why it wasn't working. Turns out the script was using a relative path, assuming that it was relative to the location of the script but it was in fact relative to the root of my home directory because that was the working directory that cron was using, which is why the script worked when it was in the root of my home directory (because the script's expected working directory and it's actual working just happened to coincide).
– Micheal Johnson
Feb 4 '16 at 18:36
add a comment |
Crontab specs which worked in the past can break when moved from one crontab file to another. Sometimes the reason is that you've moved the spec from a system crontab file to a user crontab file or vice-versa.
The cron job specification format differs between users' crontab files (/var/spool/cron/username or /var/spool/cron/crontabs/username) and the system crontabs (/etc/crontab
and the the files in /etc/cron.d
).
The system crontabs have an extra field 'user' right before the command-to-run.
This will cause errors stating things like george; command not found
when you move a command out of /etc/crontab
or a file in /etc/cron.d
into a user's crontab file.
Conversely, cron will deliver errors like /usr/bin/restartxyz is not a valid username
or similar when the reverse occurs.
add a comment |
cron script is invoking a command with --verbose option
I had a cron script fail on me because I was in autopilot while typing the script and I included the --verbose option:
#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands
The script ran fine when executing from shell, but failed when running from crontab because the verbose output goes to stdout when run from shell, but nowhere when run from crontab. Easy fix to remove the 'v':
#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
5
Why is this causing a failure? Buffer issues?
– Adam Matan
May 31 '12 at 6:38
Any outputs or errors trriggred via cron jobs is gooing to sent to your mailbox.So we should never forget to care about these errors/output.We can redirect them to any file or /dev/null
– Nischay
Sep 27 '13 at 11:32
add a comment |
Most frequent reason I have seen cron fail in an incorrectly stated schedule. It takes practice to specify a job scheduled for 11:15 pm as 30 23 * * *
instead of * * 11 15 *
or 11 15 * * *
. Day of week for jobs after midnight also gets confused M-F is 2-6
after midnight not 1-5
. Specific dates are usually a problem as we rarely use them * * 3 1 *
is not March 3rd.
If your work with different platforms using unsupported options such as 2/3
in time specifications can also cause failures. This is a very useful option but not universally available. I have also run across issues will lists like 1-5
or 1,3,5
.
Using unqualified paths have also caused problems. The default path is usually /bin:/usr/bin
so only standard commands will run. These directories usually don't have the desired command. This also affects scripts using non standard commands. Other environment variables can also be missing.
Clobbering an existing crontab entirely has caused me problems. I now load from a file copy. This can be recovered from the existing crontab using crontab -l
if it gets clobbered. I keep the copy of crontab in ~/bin. It is commented throughout and ends with the line # EOF
. This is reloaded daily from a crontab entry like:
#!/usr/bin/crontab
# Reload this crontab
#
54 12 * * * ${HOME}/bin/crontab
The reload command above relies on an executable crontab with a bang path running crontab. Some systems require the running crontab in the command and specifying the file. If the directory is network shared, then I often use crontab.$(hostname)
as the name of the file. This will eventually correct cases where the wrong crontab is loaded on the wrong server.
Using the file provides a backup of what the crontab should be, and allows temporary edits (the only time I use crontab -e
) to be backed out automatically. There are headers available which help with getting the scheduling parameters right. I have added them when inexperience users would be editing a crontab.
Rarely, I have run into commands that require user input. These fail under crontab, although some will work with input redirection.
2
This covers three separate problems. Can they be split into separate answers?
– Eliah Kagan
Nov 24 '11 at 23:07
9
Can you explain how30 23 * * *
translates to 11:15 PM?
– JYelton
Jan 10 '14 at 19:23
add a comment |
If you are accessing an account via SSH keys it is possible to login to the account but not notice that the password on the account is locked (e.g. due to expiring or invalid password attempts)
If the system is using PAM and the account is locked, this can stop its cronjob from running. (I've tested this on Solaris, but not on Ubuntu)
You may find messages like this in /var/adm/messages:
Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
All you should need to do is run:
# passwd -u <USERNAME>
as root to unlock the account, and the crontab should work again.
add a comment |
If you have a command like this:
* * * * * /path/to/script >> /tmp/output
and it doesn't work and you can't see any output, it may not necessarily mean cron isn't working. The script could be broken and the output going to stderr which doesn't get passed to /tmp/output. Check this isn't the case, by capturing this output as well:
* * * * * /path/to/script >> /tmp/output 2>&1
to see if this helps you catch your issue.
add a comment |
=== Docker alert ===
If you're using docker,
I think it is proper to add that I couldn't manage to make cron to run in the background.
To run a cron job inside the container, I used supervisor and ran cron -f
, together with the other process.
Edit: Another issue - I also didn't manage to get it work when running the container with HOST networking. See this issue here also: https://github.com/phusion/baseimage-docker/issues/144
1
stackoverflow.com/questions/37458287/…
– Simon D
Dec 17 '18 at 9:53
add a comment |
In my case cron and crontab had different owners.
NOT working I had this:
User@Uva ~ $ ps -ef | grep cron | grep -v grep
User 2940 7284 pty1 19:58:41 /usr/bin/crontab
SYSTEM 11292 636 ? 22:14:15 /usr/sbin/cro
Basically I had to run cron-config and answer the questions correctly. There is a point where I was required to enter my Win7 user password for my 'User' account. From reading I did, it looks like this is a potential security issue but I am the only administrator on a single home network so I decided it was OK.
Here is the command sequence that got me going:
User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.
Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec
You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
the passwords. There are three methods to do that, as explained in
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
which provides access to network drives, or if you are using the
cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no
Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no
Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User
Reenter: User
Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.
Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.
Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.
In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.
Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.
If you cannot fix the problem, then report it to cygwin@cygwin.com.
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.
WARNING: PATH may be set differently under cron than in interactive shells.
Names such as "find" and "date" may refer to Windows programs.
User@Uva ~ $ ps -ef | grep cron | grep -v grep
User 2944 11780 ? 03:31:10 /usr/sbin/cron
User 2940 7284 pty1 19:58:41 /usr/bin/crontab
User@Uva ~ $
1
Although well documented, this looks like a Cygwin-specific point; does it really belong in askubuntu?
– sxc731
Feb 7 '16 at 11:14
add a comment |
I was writing an install shell script that creates another script to purge old transaction data from a database. As a part of the task it had to configure daily cron
job to run at an arbitrary time, when the database load was low.
I created a file mycronjob
with cron schedule, username & the command and copied it to the /etc/cron.d
directory. My two gotchas:
mycronjob
file had to be owned by root to run- I had to set permissions of the file to 644 - 664 would not run.
A permission problem will appear in /var/log/syslog
as something similar to:
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)
The first line refers to /etc/crontab
file and the later to a file I placed under /etc/cront.d
.
add a comment |
Line written in a way crontab doesn't understand. It needs to be correctly written. Here's CrontabHowTo.
1
How can this be debugged?
– Adam Matan
Jan 27 '11 at 6:34
Reviewing cron's error log is the most common way. IIRC 'crontab -e' does a syntax parse after you've edited the file as well - but that might not be universal.
– pbr
Apr 8 '12 at 22:47
add a comment |
Cron daemon could be running, but not actually working. Try restarting cron:
sudo /etc/init.d/cron restart
3
I've NEVER seen this case in production. Doesn't mean it hasn't happened - just that I've not seen it in the 30 years I've been using UNIX and Linux. Cron is insanely robust.
– pbr
Apr 8 '12 at 22:42
1
I'm not sure but I think this did actually just happen to me. I triedpidof
cron and got nothing. Tried usingservice
utility and it said cron was already running. Just ran this command and ranpidof
again and I get a result.
– Colleen
Apr 6 '15 at 17:13
add a comment |
Writing to cron via "crontab -e" with the username argument in a line. I've seen examples of users (or sysadmins) writing their shell scripts and not understanding why they don't automate. The "user" argument exists in /etc/crontab, but not the user-defined files. so, for example, your personal file would be something like:
# m h dom mon dow command
* * */2 * * /some/shell/script
whereas /etc/crontab would be:
# m h dom mon dow user command
* * */2 * * jdoe /some/shell/script
So, why would you do the latter? Well, depending on how you want to set your permissions, this can become very convoluted. I've written scripts to automate tasks for users who don't understand the intricacies, or don't want to bother with the drudgery. By setting permissions to --x------
, I can make the script executable without them being able to read (and perhaps accidentally change) it. However, I might want to run this command with several others from one file (thus making it easier to maintain) but make sure file output is assigned the right owner. Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute, plus the afore-mentioned issue with putting periods in /etc/crontab (which, funnily enough, causes no error when going through crontab -e
).
As an example, I've seen instances of sudo crontab -e
used to run a script with root permissions, with a corresponding chown username file_output
in the shell script. Sloppy, but it works. IMHO, The more graceful option is to put it in /etc/crontab
with username declared and proper permissions, so file_output
goes to the right place and owner.
"Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute....." I should clarify: /etc/crontab (by default) requires read AND execute permissions, whereas you COULD run "sudo crontab -e" to create a cronjob which overrides both the need for the "w" permission, and the problem with extensions like ".sh". I haven't had time to pull apart the cron code and check why this works, just a detail I've noticed.
– Mange
Jun 12 '12 at 19:54
add a comment |
Building off what Aaron Peart mentioned about verbose mode, sometimes scripts not in verbose mode will initialize but not finish if the default behavior of an included command is to output a line or more to the screen once the proc starts. For example, I wrote a backup script for our intranet which used curl, a utility that downloads or uploads files to remote servers, and is quite handy if you can only access said remote files through HTTP. Using 'curl http://something.com/somefile.xls' was causing a script I wrote to hang and never complete because it spits out a newline followed by a progress line. I had to use the silent flag (-s) to tell it not to output any information, and write in my own code to handle if the file failed to download.
1
For programs that don't have a silent mode, you can redirect their output to/dev/null
. For example:some-command > /dev/null
This will redirect only standard output, and not error output (which is usually what you want, since you want to be informed of errors). To redirect error output too, usesome-command &> /dev/null
.
– Eliah Kagan
Jun 12 '12 at 20:22
Yeah, that was my first thought when writing the afore-mentioneed script. I forget why I didn't use that, possibly some non-standard behavior that circumvented said solution. I know that verbose/interactive mode is the default on some commands (I'm looking at YOU, scp!), which means you need to hadle said output for smooth operation of shell scripts.
– Mange
Jun 13 '12 at 12:09
add a comment |
Although you can define environment variables in your crontable, you're not in a shell script. So constructions like the following won't work:
SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log
BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file
0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
This is because variables are not interpreted in the crontable: all values are taken litterally. And this is the same if you omit the brackets.
So your commands won't run, and your log files won't be written...
Instead you must define all your environment variables straight:
SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log
BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file
0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
add a comment |
When a task is run within cron, stdin is closed. Programs that act differently based on whether stdin is available or not will behave differently between the shell session and in cron.
An example is the program goaccess
for analysing web server log files. This does NOT work in cron:
goaccess -a -f /var/log/nginx/access.log > output.html
and goaccess
shows the help page instead of creating the report. In the shell this can be reproduced with
goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null
The fix for goaccess
is to make it read the log from stdin instead of reading from the file, so the solution is to change the crontab entry to
cat /var/log/nginx/access.log | goaccess -a > output.html
add a comment |
On my RHEL7 servers, root cron jobs would run, but user jobs would not. I found that without a home directory, the jobs won't run (but you will see good errors in /var/log/cron). When I created the home directory, the problem was solved.
add a comment |
If you edited your crontab file using a windows editor (via samba or something) and it's replaced the newlines with nr or just r, cron won't run.
Also, if you're using /etc/cron.d/* and one of those files has a r in it, cron will move through the files and stop when it hits a bad file. Not sure if that's the problem?
Use:
od -c /etc/cron.d/* | grep r
add a comment |
1 2
next
protected by heemayl May 9 '17 at 3:07
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
46 Answers
46
active
oldest
votes
46 Answers
46
active
oldest
votes
active
oldest
votes
active
oldest
votes
1 2
next
Different environment
Cron passes a minimal set of environment variables to your jobs. To see the difference, add a dummy job like this:
* * * * * env > /tmp/env.output
Wait for /tmp/env.output
to be created, then remove the job again. Now compare the contents of /tmp/env.output
with the output of env
run in your regular terminal.
A common "gotcha" here is the PATH
environment variable being different. Maybe your cron script uses the command somecommand
found in /opt/someApp/bin
, which you've added to PATH
in /etc/environment
? cron ignores PATH
from that file, so runnning somecommand
from your script will fail when run with cron, but work when run in a terminal. It's worth noting that variables from /etc/environment
will be passed on to cron jobs, just not the variables cron specifically sets itself, such as PATH
.
To get around that, just set your own PATH
variable at the top of the script. E.g.
#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# rest of script follows
Some prefer to just use absolute paths to all the commands instead. I recommend against that. Consider what happens if you want to run your script on a different system, and on that system, the command is in /opt/someAppv2.2/bin
instead. You'd have to go through the whole script replacing /opt/someApp/bin
with /opt/someAppv2.2/bin
instead of just doing a small edit on the first line of the script.
You can also set the PATH variable in the crontab file, which will apply to all cron jobs. E.g.
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
15 1 * * * backupscript --incremental /home /root
5
I think I just fell for this, and newline at end... double whammy.
– WernerCD
Jun 2 '11 at 4:22
5
+1 forenv
, I had completely forgotten about that command and thought PATH was working. It was actually sliiiightly different in my case.
– Izkata
Jan 18 '12 at 15:16
8
@pbr If such directories are left writable to others, the system is already compromized.
– geirha
Apr 9 '12 at 8:23
6
@pbr A sysadmin could unwittingly delete the root filesystem. You can't guard against sysadmins making silly mistakes. If you install a newer version of an interpreter that is not backwards compatible, I'd expect breakage regardless. The sane way to handle that is to install it as a different command. E.g. you have python version 2.x and install python 3, you install it as python3, not python. And as for /opt/someApp/bin, why on earth wouldn't it have sane permissions/ownership? any sane admin would ensure sane permissions/ownership on system files.
– geirha
Apr 10 '12 at 6:36
2
@pbr It seems we could go on forever, yes. I still fail to see why it's a bad idea to use PATH though. If you feel like discussing this further in a medium better suited for discussion, you'll find me in #ubuntu and #bash, among other channels, on irc.freenode.net
– geirha
Apr 11 '12 at 16:28
|
show 20 more comments
Different environment
Cron passes a minimal set of environment variables to your jobs. To see the difference, add a dummy job like this:
* * * * * env > /tmp/env.output
Wait for /tmp/env.output
to be created, then remove the job again. Now compare the contents of /tmp/env.output
with the output of env
run in your regular terminal.
A common "gotcha" here is the PATH
environment variable being different. Maybe your cron script uses the command somecommand
found in /opt/someApp/bin
, which you've added to PATH
in /etc/environment
? cron ignores PATH
from that file, so runnning somecommand
from your script will fail when run with cron, but work when run in a terminal. It's worth noting that variables from /etc/environment
will be passed on to cron jobs, just not the variables cron specifically sets itself, such as PATH
.
To get around that, just set your own PATH
variable at the top of the script. E.g.
#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# rest of script follows
Some prefer to just use absolute paths to all the commands instead. I recommend against that. Consider what happens if you want to run your script on a different system, and on that system, the command is in /opt/someAppv2.2/bin
instead. You'd have to go through the whole script replacing /opt/someApp/bin
with /opt/someAppv2.2/bin
instead of just doing a small edit on the first line of the script.
You can also set the PATH variable in the crontab file, which will apply to all cron jobs. E.g.
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
15 1 * * * backupscript --incremental /home /root
5
I think I just fell for this, and newline at end... double whammy.
– WernerCD
Jun 2 '11 at 4:22
5
+1 forenv
, I had completely forgotten about that command and thought PATH was working. It was actually sliiiightly different in my case.
– Izkata
Jan 18 '12 at 15:16
8
@pbr If such directories are left writable to others, the system is already compromized.
– geirha
Apr 9 '12 at 8:23
6
@pbr A sysadmin could unwittingly delete the root filesystem. You can't guard against sysadmins making silly mistakes. If you install a newer version of an interpreter that is not backwards compatible, I'd expect breakage regardless. The sane way to handle that is to install it as a different command. E.g. you have python version 2.x and install python 3, you install it as python3, not python. And as for /opt/someApp/bin, why on earth wouldn't it have sane permissions/ownership? any sane admin would ensure sane permissions/ownership on system files.
– geirha
Apr 10 '12 at 6:36
2
@pbr It seems we could go on forever, yes. I still fail to see why it's a bad idea to use PATH though. If you feel like discussing this further in a medium better suited for discussion, you'll find me in #ubuntu and #bash, among other channels, on irc.freenode.net
– geirha
Apr 11 '12 at 16:28
|
show 20 more comments
Different environment
Cron passes a minimal set of environment variables to your jobs. To see the difference, add a dummy job like this:
* * * * * env > /tmp/env.output
Wait for /tmp/env.output
to be created, then remove the job again. Now compare the contents of /tmp/env.output
with the output of env
run in your regular terminal.
A common "gotcha" here is the PATH
environment variable being different. Maybe your cron script uses the command somecommand
found in /opt/someApp/bin
, which you've added to PATH
in /etc/environment
? cron ignores PATH
from that file, so runnning somecommand
from your script will fail when run with cron, but work when run in a terminal. It's worth noting that variables from /etc/environment
will be passed on to cron jobs, just not the variables cron specifically sets itself, such as PATH
.
To get around that, just set your own PATH
variable at the top of the script. E.g.
#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# rest of script follows
Some prefer to just use absolute paths to all the commands instead. I recommend against that. Consider what happens if you want to run your script on a different system, and on that system, the command is in /opt/someAppv2.2/bin
instead. You'd have to go through the whole script replacing /opt/someApp/bin
with /opt/someAppv2.2/bin
instead of just doing a small edit on the first line of the script.
You can also set the PATH variable in the crontab file, which will apply to all cron jobs. E.g.
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
15 1 * * * backupscript --incremental /home /root
Different environment
Cron passes a minimal set of environment variables to your jobs. To see the difference, add a dummy job like this:
* * * * * env > /tmp/env.output
Wait for /tmp/env.output
to be created, then remove the job again. Now compare the contents of /tmp/env.output
with the output of env
run in your regular terminal.
A common "gotcha" here is the PATH
environment variable being different. Maybe your cron script uses the command somecommand
found in /opt/someApp/bin
, which you've added to PATH
in /etc/environment
? cron ignores PATH
from that file, so runnning somecommand
from your script will fail when run with cron, but work when run in a terminal. It's worth noting that variables from /etc/environment
will be passed on to cron jobs, just not the variables cron specifically sets itself, such as PATH
.
To get around that, just set your own PATH
variable at the top of the script. E.g.
#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# rest of script follows
Some prefer to just use absolute paths to all the commands instead. I recommend against that. Consider what happens if you want to run your script on a different system, and on that system, the command is in /opt/someAppv2.2/bin
instead. You'd have to go through the whole script replacing /opt/someApp/bin
with /opt/someAppv2.2/bin
instead of just doing a small edit on the first line of the script.
You can also set the PATH variable in the crontab file, which will apply to all cron jobs. E.g.
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
15 1 * * * backupscript --incremental /home /root
edited Feb 27 '18 at 18:47
community wiki
10 revs, 8 users 67%
geirha
5
I think I just fell for this, and newline at end... double whammy.
– WernerCD
Jun 2 '11 at 4:22
5
+1 forenv
, I had completely forgotten about that command and thought PATH was working. It was actually sliiiightly different in my case.
– Izkata
Jan 18 '12 at 15:16
8
@pbr If such directories are left writable to others, the system is already compromized.
– geirha
Apr 9 '12 at 8:23
6
@pbr A sysadmin could unwittingly delete the root filesystem. You can't guard against sysadmins making silly mistakes. If you install a newer version of an interpreter that is not backwards compatible, I'd expect breakage regardless. The sane way to handle that is to install it as a different command. E.g. you have python version 2.x and install python 3, you install it as python3, not python. And as for /opt/someApp/bin, why on earth wouldn't it have sane permissions/ownership? any sane admin would ensure sane permissions/ownership on system files.
– geirha
Apr 10 '12 at 6:36
2
@pbr It seems we could go on forever, yes. I still fail to see why it's a bad idea to use PATH though. If you feel like discussing this further in a medium better suited for discussion, you'll find me in #ubuntu and #bash, among other channels, on irc.freenode.net
– geirha
Apr 11 '12 at 16:28
|
show 20 more comments
5
I think I just fell for this, and newline at end... double whammy.
– WernerCD
Jun 2 '11 at 4:22
5
+1 forenv
, I had completely forgotten about that command and thought PATH was working. It was actually sliiiightly different in my case.
– Izkata
Jan 18 '12 at 15:16
8
@pbr If such directories are left writable to others, the system is already compromized.
– geirha
Apr 9 '12 at 8:23
6
@pbr A sysadmin could unwittingly delete the root filesystem. You can't guard against sysadmins making silly mistakes. If you install a newer version of an interpreter that is not backwards compatible, I'd expect breakage regardless. The sane way to handle that is to install it as a different command. E.g. you have python version 2.x and install python 3, you install it as python3, not python. And as for /opt/someApp/bin, why on earth wouldn't it have sane permissions/ownership? any sane admin would ensure sane permissions/ownership on system files.
– geirha
Apr 10 '12 at 6:36
2
@pbr It seems we could go on forever, yes. I still fail to see why it's a bad idea to use PATH though. If you feel like discussing this further in a medium better suited for discussion, you'll find me in #ubuntu and #bash, among other channels, on irc.freenode.net
– geirha
Apr 11 '12 at 16:28
5
5
I think I just fell for this, and newline at end... double whammy.
– WernerCD
Jun 2 '11 at 4:22
I think I just fell for this, and newline at end... double whammy.
– WernerCD
Jun 2 '11 at 4:22
5
5
+1 for
env
, I had completely forgotten about that command and thought PATH was working. It was actually sliiiightly different in my case.– Izkata
Jan 18 '12 at 15:16
+1 for
env
, I had completely forgotten about that command and thought PATH was working. It was actually sliiiightly different in my case.– Izkata
Jan 18 '12 at 15:16
8
8
@pbr If such directories are left writable to others, the system is already compromized.
– geirha
Apr 9 '12 at 8:23
@pbr If such directories are left writable to others, the system is already compromized.
– geirha
Apr 9 '12 at 8:23
6
6
@pbr A sysadmin could unwittingly delete the root filesystem. You can't guard against sysadmins making silly mistakes. If you install a newer version of an interpreter that is not backwards compatible, I'd expect breakage regardless. The sane way to handle that is to install it as a different command. E.g. you have python version 2.x and install python 3, you install it as python3, not python. And as for /opt/someApp/bin, why on earth wouldn't it have sane permissions/ownership? any sane admin would ensure sane permissions/ownership on system files.
– geirha
Apr 10 '12 at 6:36
@pbr A sysadmin could unwittingly delete the root filesystem. You can't guard against sysadmins making silly mistakes. If you install a newer version of an interpreter that is not backwards compatible, I'd expect breakage regardless. The sane way to handle that is to install it as a different command. E.g. you have python version 2.x and install python 3, you install it as python3, not python. And as for /opt/someApp/bin, why on earth wouldn't it have sane permissions/ownership? any sane admin would ensure sane permissions/ownership on system files.
– geirha
Apr 10 '12 at 6:36
2
2
@pbr It seems we could go on forever, yes. I still fail to see why it's a bad idea to use PATH though. If you feel like discussing this further in a medium better suited for discussion, you'll find me in #ubuntu and #bash, among other channels, on irc.freenode.net
– geirha
Apr 11 '12 at 16:28
@pbr It seems we could go on forever, yes. I still fail to see why it's a bad idea to use PATH though. If you feel like discussing this further in a medium better suited for discussion, you'll find me in #ubuntu and #bash, among other channels, on irc.freenode.net
– geirha
Apr 11 '12 at 16:28
|
show 20 more comments
My top gotcha: If you forget to add a newline at the end of the crontab
file. In other words, the crontab file should end with an empty line.
Below is the relevant section in the man pages for this issue (man crontab
then skip to the end):
Although cron requires that each entry in a crontab end in a newline
character, neither the crontab command nor the cron daemon will detect
this error. Instead, the crontab will appear to load normally. However,
the command will never run. The best choice is to ensure that your
crontab has a blank line at the end.
4th Berkeley Distribution 29 December 1993 CRONTAB(1)
77
this is such a showstopper, how come it hasn't been fixed in so many years of cron?
– Capi Etheriel
Jan 27 '11 at 3:20
2
Seems to be fixed in Vixie cron:man crontab
on Ubuntu 10.10 says "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." (And the date at the end is 19 April 2010.)
– Marius Gedminas
Feb 1 '11 at 22:58
18
@barraponto This is actually a bug in new text editors. The "newline" character is supposed to be a line termination character, so the final line in a text file is supposed to end in a newline character that doesn't get shown in the editor. Vi and vim use the character correctly, and cron was built before the new editors started their odd behavior... Hence playing it save and including a blank line.
– Izkata
Jan 18 '12 at 15:20
4
If you edit crontab usingcrontab -e
it will check the syntax of the file before allowing a save, including a check for newline.
– Tom Harrison Jr
Sep 26 '14 at 18:26
2
@Chan-HoSuh, according to man page "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." This behavior will be invoked when editing then saving the crontab using the-e
option, and is independent of the editor.
– Tom Harrison Jr
Nov 18 '14 at 16:40
|
show 7 more comments
My top gotcha: If you forget to add a newline at the end of the crontab
file. In other words, the crontab file should end with an empty line.
Below is the relevant section in the man pages for this issue (man crontab
then skip to the end):
Although cron requires that each entry in a crontab end in a newline
character, neither the crontab command nor the cron daemon will detect
this error. Instead, the crontab will appear to load normally. However,
the command will never run. The best choice is to ensure that your
crontab has a blank line at the end.
4th Berkeley Distribution 29 December 1993 CRONTAB(1)
77
this is such a showstopper, how come it hasn't been fixed in so many years of cron?
– Capi Etheriel
Jan 27 '11 at 3:20
2
Seems to be fixed in Vixie cron:man crontab
on Ubuntu 10.10 says "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." (And the date at the end is 19 April 2010.)
– Marius Gedminas
Feb 1 '11 at 22:58
18
@barraponto This is actually a bug in new text editors. The "newline" character is supposed to be a line termination character, so the final line in a text file is supposed to end in a newline character that doesn't get shown in the editor. Vi and vim use the character correctly, and cron was built before the new editors started their odd behavior... Hence playing it save and including a blank line.
– Izkata
Jan 18 '12 at 15:20
4
If you edit crontab usingcrontab -e
it will check the syntax of the file before allowing a save, including a check for newline.
– Tom Harrison Jr
Sep 26 '14 at 18:26
2
@Chan-HoSuh, according to man page "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." This behavior will be invoked when editing then saving the crontab using the-e
option, and is independent of the editor.
– Tom Harrison Jr
Nov 18 '14 at 16:40
|
show 7 more comments
My top gotcha: If you forget to add a newline at the end of the crontab
file. In other words, the crontab file should end with an empty line.
Below is the relevant section in the man pages for this issue (man crontab
then skip to the end):
Although cron requires that each entry in a crontab end in a newline
character, neither the crontab command nor the cron daemon will detect
this error. Instead, the crontab will appear to load normally. However,
the command will never run. The best choice is to ensure that your
crontab has a blank line at the end.
4th Berkeley Distribution 29 December 1993 CRONTAB(1)
My top gotcha: If you forget to add a newline at the end of the crontab
file. In other words, the crontab file should end with an empty line.
Below is the relevant section in the man pages for this issue (man crontab
then skip to the end):
Although cron requires that each entry in a crontab end in a newline
character, neither the crontab command nor the cron daemon will detect
this error. Instead, the crontab will appear to load normally. However,
the command will never run. The best choice is to ensure that your
crontab has a blank line at the end.
4th Berkeley Distribution 29 December 1993 CRONTAB(1)
edited Feb 2 '11 at 20:32
community wiki
4 revs, 3 users 88%
user4124
77
this is such a showstopper, how come it hasn't been fixed in so many years of cron?
– Capi Etheriel
Jan 27 '11 at 3:20
2
Seems to be fixed in Vixie cron:man crontab
on Ubuntu 10.10 says "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." (And the date at the end is 19 April 2010.)
– Marius Gedminas
Feb 1 '11 at 22:58
18
@barraponto This is actually a bug in new text editors. The "newline" character is supposed to be a line termination character, so the final line in a text file is supposed to end in a newline character that doesn't get shown in the editor. Vi and vim use the character correctly, and cron was built before the new editors started their odd behavior... Hence playing it save and including a blank line.
– Izkata
Jan 18 '12 at 15:20
4
If you edit crontab usingcrontab -e
it will check the syntax of the file before allowing a save, including a check for newline.
– Tom Harrison Jr
Sep 26 '14 at 18:26
2
@Chan-HoSuh, according to man page "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." This behavior will be invoked when editing then saving the crontab using the-e
option, and is independent of the editor.
– Tom Harrison Jr
Nov 18 '14 at 16:40
|
show 7 more comments
77
this is such a showstopper, how come it hasn't been fixed in so many years of cron?
– Capi Etheriel
Jan 27 '11 at 3:20
2
Seems to be fixed in Vixie cron:man crontab
on Ubuntu 10.10 says "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." (And the date at the end is 19 April 2010.)
– Marius Gedminas
Feb 1 '11 at 22:58
18
@barraponto This is actually a bug in new text editors. The "newline" character is supposed to be a line termination character, so the final line in a text file is supposed to end in a newline character that doesn't get shown in the editor. Vi and vim use the character correctly, and cron was built before the new editors started their odd behavior... Hence playing it save and including a blank line.
– Izkata
Jan 18 '12 at 15:20
4
If you edit crontab usingcrontab -e
it will check the syntax of the file before allowing a save, including a check for newline.
– Tom Harrison Jr
Sep 26 '14 at 18:26
2
@Chan-HoSuh, according to man page "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." This behavior will be invoked when editing then saving the crontab using the-e
option, and is independent of the editor.
– Tom Harrison Jr
Nov 18 '14 at 16:40
77
77
this is such a showstopper, how come it hasn't been fixed in so many years of cron?
– Capi Etheriel
Jan 27 '11 at 3:20
this is such a showstopper, how come it hasn't been fixed in so many years of cron?
– Capi Etheriel
Jan 27 '11 at 3:20
2
2
Seems to be fixed in Vixie cron:
man crontab
on Ubuntu 10.10 says "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." (And the date at the end is 19 April 2010.)– Marius Gedminas
Feb 1 '11 at 22:58
Seems to be fixed in Vixie cron:
man crontab
on Ubuntu 10.10 says "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." (And the date at the end is 19 April 2010.)– Marius Gedminas
Feb 1 '11 at 22:58
18
18
@barraponto This is actually a bug in new text editors. The "newline" character is supposed to be a line termination character, so the final line in a text file is supposed to end in a newline character that doesn't get shown in the editor. Vi and vim use the character correctly, and cron was built before the new editors started their odd behavior... Hence playing it save and including a blank line.
– Izkata
Jan 18 '12 at 15:20
@barraponto This is actually a bug in new text editors. The "newline" character is supposed to be a line termination character, so the final line in a text file is supposed to end in a newline character that doesn't get shown in the editor. Vi and vim use the character correctly, and cron was built before the new editors started their odd behavior... Hence playing it save and including a blank line.
– Izkata
Jan 18 '12 at 15:20
4
4
If you edit crontab using
crontab -e
it will check the syntax of the file before allowing a save, including a check for newline.– Tom Harrison Jr
Sep 26 '14 at 18:26
If you edit crontab using
crontab -e
it will check the syntax of the file before allowing a save, including a check for newline.– Tom Harrison Jr
Sep 26 '14 at 18:26
2
2
@Chan-HoSuh, according to man page "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." This behavior will be invoked when editing then saving the crontab using the
-e
option, and is independent of the editor.– Tom Harrison Jr
Nov 18 '14 at 16:40
@Chan-HoSuh, according to man page "cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing the newline, cron will consider the crontab (at least partially) broken and refuse to install it." This behavior will be invoked when editing then saving the crontab using the
-e
option, and is independent of the editor.– Tom Harrison Jr
Nov 18 '14 at 16:40
|
show 7 more comments
Cron daemon is not running. I really screwed up with this some months ago.
Type:
pgrep cron
If you see no number, then cron is not running. sudo /etc/init.d/cron start
can be used to start cron.
EDIT: Rather than invoking init scripts through /etc/init.d, use the service
utility, e.g.
sudo service cron start
40
Thanks for showing me pgrep. I kept doing ps -ef | grep foo
– ripper234
Mar 17 '11 at 17:01
4
You could also usepidof cron
which will omit results for other applications that also have the word 'cron', like crontab.
– Pithikos
Mar 11 '14 at 16:19
Weird, all of these give me nothing to show cron is running, but if I runsudo service cron start
I getstart: Job is already running: cron
– Colleen
Apr 6 '15 at 17:04
1
service crond start
if its centos/RHEL
– Srihari Karanth
Jan 18 '17 at 10:02
add a comment |
Cron daemon is not running. I really screwed up with this some months ago.
Type:
pgrep cron
If you see no number, then cron is not running. sudo /etc/init.d/cron start
can be used to start cron.
EDIT: Rather than invoking init scripts through /etc/init.d, use the service
utility, e.g.
sudo service cron start
40
Thanks for showing me pgrep. I kept doing ps -ef | grep foo
– ripper234
Mar 17 '11 at 17:01
4
You could also usepidof cron
which will omit results for other applications that also have the word 'cron', like crontab.
– Pithikos
Mar 11 '14 at 16:19
Weird, all of these give me nothing to show cron is running, but if I runsudo service cron start
I getstart: Job is already running: cron
– Colleen
Apr 6 '15 at 17:04
1
service crond start
if its centos/RHEL
– Srihari Karanth
Jan 18 '17 at 10:02
add a comment |
Cron daemon is not running. I really screwed up with this some months ago.
Type:
pgrep cron
If you see no number, then cron is not running. sudo /etc/init.d/cron start
can be used to start cron.
EDIT: Rather than invoking init scripts through /etc/init.d, use the service
utility, e.g.
sudo service cron start
Cron daemon is not running. I really screwed up with this some months ago.
Type:
pgrep cron
If you see no number, then cron is not running. sudo /etc/init.d/cron start
can be used to start cron.
EDIT: Rather than invoking init scripts through /etc/init.d, use the service
utility, e.g.
sudo service cron start
edited Jan 26 '12 at 10:57
community wiki
4 revs, 4 users 38%
user6019
40
Thanks for showing me pgrep. I kept doing ps -ef | grep foo
– ripper234
Mar 17 '11 at 17:01
4
You could also usepidof cron
which will omit results for other applications that also have the word 'cron', like crontab.
– Pithikos
Mar 11 '14 at 16:19
Weird, all of these give me nothing to show cron is running, but if I runsudo service cron start
I getstart: Job is already running: cron
– Colleen
Apr 6 '15 at 17:04
1
service crond start
if its centos/RHEL
– Srihari Karanth
Jan 18 '17 at 10:02
add a comment |
40
Thanks for showing me pgrep. I kept doing ps -ef | grep foo
– ripper234
Mar 17 '11 at 17:01
4
You could also usepidof cron
which will omit results for other applications that also have the word 'cron', like crontab.
– Pithikos
Mar 11 '14 at 16:19
Weird, all of these give me nothing to show cron is running, but if I runsudo service cron start
I getstart: Job is already running: cron
– Colleen
Apr 6 '15 at 17:04
1
service crond start
if its centos/RHEL
– Srihari Karanth
Jan 18 '17 at 10:02
40
40
Thanks for showing me pgrep. I kept doing ps -ef | grep foo
– ripper234
Mar 17 '11 at 17:01
Thanks for showing me pgrep. I kept doing ps -ef | grep foo
– ripper234
Mar 17 '11 at 17:01
4
4
You could also use
pidof cron
which will omit results for other applications that also have the word 'cron', like crontab.– Pithikos
Mar 11 '14 at 16:19
You could also use
pidof cron
which will omit results for other applications that also have the word 'cron', like crontab.– Pithikos
Mar 11 '14 at 16:19
Weird, all of these give me nothing to show cron is running, but if I run
sudo service cron start
I get start: Job is already running: cron
– Colleen
Apr 6 '15 at 17:04
Weird, all of these give me nothing to show cron is running, but if I run
sudo service cron start
I get start: Job is already running: cron
– Colleen
Apr 6 '15 at 17:04
1
1
service crond start
if its centos/RHEL– Srihari Karanth
Jan 18 '17 at 10:02
service crond start
if its centos/RHEL– Srihari Karanth
Jan 18 '17 at 10:02
add a comment |
The script filenames in cron.d/
, cron.daily/
, cron.hourly/
, etc., should not contain dot (.
), otherwise run-parts will skip them.
See run-parts(8):
If neither the --lsbsysinit option nor the --regex option is given then
the names must consist entirely of upper and lower case letters, dig‐
its, underscores, and hyphens.
If the --lsbsysinit option is given, then the names must not end in
.dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to
one or more of the following namespaces: the LANANA-assigned namespace
(^[a-z0-9]+$); the LSB hierarchical and reserved namespaces
(^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace
(^[a-zA-Z0-9_-]+$).
So, if you have a cron script backup.sh
, analyze-logs.pl
in cron.daily/
directory, you'd best to remove the extension names.
10
It's a feature not a bug - it keeps things like myscript.backup or myscript.original or myscript.rpm-new from running right beside myscript.
– pbr
Apr 8 '12 at 22:45
@pbr: makes sense. At least it would have been helpful for debugging ifrun-parts --test
(or another imaginary option like--debug
would output the files it skips including the reason.
– Rabarberski
May 30 '13 at 8:46
7
If this is a feature, it's not a nice one :( A lot of people use dot in file name (backup.sh is the most common one). If you want to a script to stop executing, the most logical method will be to remove it from "cron.d" directory.
– MatuDuke
May 16 '14 at 13:59
5
This is such a bad feature that it's effectively a bug. It's common practice to require a particular ending (like ".list" or ".cron" or something) if people want to make sure that things only get run when intended. Arbitrarily picking dot as a likely separator for ".bak" or ".temp" or whatever, is completely unpredictable except in the way that it will predictably confuse people. Legitimate endings like ".sh", and ".pl" have been in widespread use for decades. Lots of people use "_bak" or "_temp" or "-bak" instead of a dot, however. This is an awful design choice; it's a design bug at best.
– Teekin
May 10 '17 at 20:42
add a comment |
The script filenames in cron.d/
, cron.daily/
, cron.hourly/
, etc., should not contain dot (.
), otherwise run-parts will skip them.
See run-parts(8):
If neither the --lsbsysinit option nor the --regex option is given then
the names must consist entirely of upper and lower case letters, dig‐
its, underscores, and hyphens.
If the --lsbsysinit option is given, then the names must not end in
.dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to
one or more of the following namespaces: the LANANA-assigned namespace
(^[a-z0-9]+$); the LSB hierarchical and reserved namespaces
(^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace
(^[a-zA-Z0-9_-]+$).
So, if you have a cron script backup.sh
, analyze-logs.pl
in cron.daily/
directory, you'd best to remove the extension names.
10
It's a feature not a bug - it keeps things like myscript.backup or myscript.original or myscript.rpm-new from running right beside myscript.
– pbr
Apr 8 '12 at 22:45
@pbr: makes sense. At least it would have been helpful for debugging ifrun-parts --test
(or another imaginary option like--debug
would output the files it skips including the reason.
– Rabarberski
May 30 '13 at 8:46
7
If this is a feature, it's not a nice one :( A lot of people use dot in file name (backup.sh is the most common one). If you want to a script to stop executing, the most logical method will be to remove it from "cron.d" directory.
– MatuDuke
May 16 '14 at 13:59
5
This is such a bad feature that it's effectively a bug. It's common practice to require a particular ending (like ".list" or ".cron" or something) if people want to make sure that things only get run when intended. Arbitrarily picking dot as a likely separator for ".bak" or ".temp" or whatever, is completely unpredictable except in the way that it will predictably confuse people. Legitimate endings like ".sh", and ".pl" have been in widespread use for decades. Lots of people use "_bak" or "_temp" or "-bak" instead of a dot, however. This is an awful design choice; it's a design bug at best.
– Teekin
May 10 '17 at 20:42
add a comment |
The script filenames in cron.d/
, cron.daily/
, cron.hourly/
, etc., should not contain dot (.
), otherwise run-parts will skip them.
See run-parts(8):
If neither the --lsbsysinit option nor the --regex option is given then
the names must consist entirely of upper and lower case letters, dig‐
its, underscores, and hyphens.
If the --lsbsysinit option is given, then the names must not end in
.dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to
one or more of the following namespaces: the LANANA-assigned namespace
(^[a-z0-9]+$); the LSB hierarchical and reserved namespaces
(^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace
(^[a-zA-Z0-9_-]+$).
So, if you have a cron script backup.sh
, analyze-logs.pl
in cron.daily/
directory, you'd best to remove the extension names.
The script filenames in cron.d/
, cron.daily/
, cron.hourly/
, etc., should not contain dot (.
), otherwise run-parts will skip them.
See run-parts(8):
If neither the --lsbsysinit option nor the --regex option is given then
the names must consist entirely of upper and lower case letters, dig‐
its, underscores, and hyphens.
If the --lsbsysinit option is given, then the names must not end in
.dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to
one or more of the following namespaces: the LANANA-assigned namespace
(^[a-z0-9]+$); the LSB hierarchical and reserved namespaces
(^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace
(^[a-zA-Z0-9_-]+$).
So, if you have a cron script backup.sh
, analyze-logs.pl
in cron.daily/
directory, you'd best to remove the extension names.
edited Jan 10 '17 at 15:20
community wiki
3 revs, 3 users 91%
Xiè Jìléi
10
It's a feature not a bug - it keeps things like myscript.backup or myscript.original or myscript.rpm-new from running right beside myscript.
– pbr
Apr 8 '12 at 22:45
@pbr: makes sense. At least it would have been helpful for debugging ifrun-parts --test
(or another imaginary option like--debug
would output the files it skips including the reason.
– Rabarberski
May 30 '13 at 8:46
7
If this is a feature, it's not a nice one :( A lot of people use dot in file name (backup.sh is the most common one). If you want to a script to stop executing, the most logical method will be to remove it from "cron.d" directory.
– MatuDuke
May 16 '14 at 13:59
5
This is such a bad feature that it's effectively a bug. It's common practice to require a particular ending (like ".list" or ".cron" or something) if people want to make sure that things only get run when intended. Arbitrarily picking dot as a likely separator for ".bak" or ".temp" or whatever, is completely unpredictable except in the way that it will predictably confuse people. Legitimate endings like ".sh", and ".pl" have been in widespread use for decades. Lots of people use "_bak" or "_temp" or "-bak" instead of a dot, however. This is an awful design choice; it's a design bug at best.
– Teekin
May 10 '17 at 20:42
add a comment |
10
It's a feature not a bug - it keeps things like myscript.backup or myscript.original or myscript.rpm-new from running right beside myscript.
– pbr
Apr 8 '12 at 22:45
@pbr: makes sense. At least it would have been helpful for debugging ifrun-parts --test
(or another imaginary option like--debug
would output the files it skips including the reason.
– Rabarberski
May 30 '13 at 8:46
7
If this is a feature, it's not a nice one :( A lot of people use dot in file name (backup.sh is the most common one). If you want to a script to stop executing, the most logical method will be to remove it from "cron.d" directory.
– MatuDuke
May 16 '14 at 13:59
5
This is such a bad feature that it's effectively a bug. It's common practice to require a particular ending (like ".list" or ".cron" or something) if people want to make sure that things only get run when intended. Arbitrarily picking dot as a likely separator for ".bak" or ".temp" or whatever, is completely unpredictable except in the way that it will predictably confuse people. Legitimate endings like ".sh", and ".pl" have been in widespread use for decades. Lots of people use "_bak" or "_temp" or "-bak" instead of a dot, however. This is an awful design choice; it's a design bug at best.
– Teekin
May 10 '17 at 20:42
10
10
It's a feature not a bug - it keeps things like myscript.backup or myscript.original or myscript.rpm-new from running right beside myscript.
– pbr
Apr 8 '12 at 22:45
It's a feature not a bug - it keeps things like myscript.backup or myscript.original or myscript.rpm-new from running right beside myscript.
– pbr
Apr 8 '12 at 22:45
@pbr: makes sense. At least it would have been helpful for debugging if
run-parts --test
(or another imaginary option like --debug
would output the files it skips including the reason.– Rabarberski
May 30 '13 at 8:46
@pbr: makes sense. At least it would have been helpful for debugging if
run-parts --test
(or another imaginary option like --debug
would output the files it skips including the reason.– Rabarberski
May 30 '13 at 8:46
7
7
If this is a feature, it's not a nice one :( A lot of people use dot in file name (backup.sh is the most common one). If you want to a script to stop executing, the most logical method will be to remove it from "cron.d" directory.
– MatuDuke
May 16 '14 at 13:59
If this is a feature, it's not a nice one :( A lot of people use dot in file name (backup.sh is the most common one). If you want to a script to stop executing, the most logical method will be to remove it from "cron.d" directory.
– MatuDuke
May 16 '14 at 13:59
5
5
This is such a bad feature that it's effectively a bug. It's common practice to require a particular ending (like ".list" or ".cron" or something) if people want to make sure that things only get run when intended. Arbitrarily picking dot as a likely separator for ".bak" or ".temp" or whatever, is completely unpredictable except in the way that it will predictably confuse people. Legitimate endings like ".sh", and ".pl" have been in widespread use for decades. Lots of people use "_bak" or "_temp" or "-bak" instead of a dot, however. This is an awful design choice; it's a design bug at best.
– Teekin
May 10 '17 at 20:42
This is such a bad feature that it's effectively a bug. It's common practice to require a particular ending (like ".list" or ".cron" or something) if people want to make sure that things only get run when intended. Arbitrarily picking dot as a likely separator for ".bak" or ".temp" or whatever, is completely unpredictable except in the way that it will predictably confuse people. Legitimate endings like ".sh", and ".pl" have been in widespread use for decades. Lots of people use "_bak" or "_temp" or "-bak" instead of a dot, however. This is an awful design choice; it's a design bug at best.
– Teekin
May 10 '17 at 20:42
add a comment |
In many environments cron executes commands using sh
, while many people assume it will use bash
.
Suggestions to test or fix this for a failing command:
- Try running the command in
sh
to see if it works - Wrap the command in a bash subshell to make sure it gets run in bash:
bash -c "mybashcommand"
- Tell cron to run all commands in bash by setting the shell at the top of your crontab:
SHELL=/bin/bash
- If the command is a script, make sure the script contains a shebang:
#!/bin/bash
bash suggestion is very helpful, fixed issue with my cron.
– Maxim Galushka
Feb 18 '16 at 22:38
This just caused me 1hr of fiddling/troubleshooting. Even more perplexing if you're not aware of the issue is the script will run manually just fine if you're typical shell isbash
, but not withcron
. Thanks!
– Hendy
Nov 22 '16 at 19:42
A long time ago I ran into something related: The commandsource
is in bash but not sh. In cron/sh, use a period:. envfile
rather thansource envfile
.
– kungphu
Dec 22 '17 at 2:24
add a comment |
In many environments cron executes commands using sh
, while many people assume it will use bash
.
Suggestions to test or fix this for a failing command:
- Try running the command in
sh
to see if it works - Wrap the command in a bash subshell to make sure it gets run in bash:
bash -c "mybashcommand"
- Tell cron to run all commands in bash by setting the shell at the top of your crontab:
SHELL=/bin/bash
- If the command is a script, make sure the script contains a shebang:
#!/bin/bash
bash suggestion is very helpful, fixed issue with my cron.
– Maxim Galushka
Feb 18 '16 at 22:38
This just caused me 1hr of fiddling/troubleshooting. Even more perplexing if you're not aware of the issue is the script will run manually just fine if you're typical shell isbash
, but not withcron
. Thanks!
– Hendy
Nov 22 '16 at 19:42
A long time ago I ran into something related: The commandsource
is in bash but not sh. In cron/sh, use a period:. envfile
rather thansource envfile
.
– kungphu
Dec 22 '17 at 2:24
add a comment |
In many environments cron executes commands using sh
, while many people assume it will use bash
.
Suggestions to test or fix this for a failing command:
- Try running the command in
sh
to see if it works - Wrap the command in a bash subshell to make sure it gets run in bash:
bash -c "mybashcommand"
- Tell cron to run all commands in bash by setting the shell at the top of your crontab:
SHELL=/bin/bash
- If the command is a script, make sure the script contains a shebang:
#!/bin/bash
In many environments cron executes commands using sh
, while many people assume it will use bash
.
Suggestions to test or fix this for a failing command:
- Try running the command in
sh
to see if it works - Wrap the command in a bash subshell to make sure it gets run in bash:
bash -c "mybashcommand"
- Tell cron to run all commands in bash by setting the shell at the top of your crontab:
SHELL=/bin/bash
- If the command is a script, make sure the script contains a shebang:
#!/bin/bash
answered Jun 25 '11 at 19:30
community wiki
Ian Mackinnon
bash suggestion is very helpful, fixed issue with my cron.
– Maxim Galushka
Feb 18 '16 at 22:38
This just caused me 1hr of fiddling/troubleshooting. Even more perplexing if you're not aware of the issue is the script will run manually just fine if you're typical shell isbash
, but not withcron
. Thanks!
– Hendy
Nov 22 '16 at 19:42
A long time ago I ran into something related: The commandsource
is in bash but not sh. In cron/sh, use a period:. envfile
rather thansource envfile
.
– kungphu
Dec 22 '17 at 2:24
add a comment |
bash suggestion is very helpful, fixed issue with my cron.
– Maxim Galushka
Feb 18 '16 at 22:38
This just caused me 1hr of fiddling/troubleshooting. Even more perplexing if you're not aware of the issue is the script will run manually just fine if you're typical shell isbash
, but not withcron
. Thanks!
– Hendy
Nov 22 '16 at 19:42
A long time ago I ran into something related: The commandsource
is in bash but not sh. In cron/sh, use a period:. envfile
rather thansource envfile
.
– kungphu
Dec 22 '17 at 2:24
bash suggestion is very helpful, fixed issue with my cron.
– Maxim Galushka
Feb 18 '16 at 22:38
bash suggestion is very helpful, fixed issue with my cron.
– Maxim Galushka
Feb 18 '16 at 22:38
This just caused me 1hr of fiddling/troubleshooting. Even more perplexing if you're not aware of the issue is the script will run manually just fine if you're typical shell is
bash
, but not with cron
. Thanks!– Hendy
Nov 22 '16 at 19:42
This just caused me 1hr of fiddling/troubleshooting. Even more perplexing if you're not aware of the issue is the script will run manually just fine if you're typical shell is
bash
, but not with cron
. Thanks!– Hendy
Nov 22 '16 at 19:42
A long time ago I ran into something related: The command
source
is in bash but not sh. In cron/sh, use a period: . envfile
rather than source envfile
.– kungphu
Dec 22 '17 at 2:24
A long time ago I ran into something related: The command
source
is in bash but not sh. In cron/sh, use a period: . envfile
rather than source envfile
.– kungphu
Dec 22 '17 at 2:24
add a comment |
I had some issues with the time zones. Cron was running with the fresh installation time zone. The solution was to restart cron:
sudo service cron restart
6
Yes, after changing the timezone on a system, one must either restart every service that cares about what time it is, or reboot. I prefer the reboot, to be sure I've caught everything.
– pbr
Apr 8 '12 at 22:48
Oh for God's sake, killed hours on this. Tried service restart after* * * * * touch /tmp/cronworks
did nothing, yet there isRELOAD
at cronlog.
– НЛО
Oct 1 '14 at 3:57
add a comment |
I had some issues with the time zones. Cron was running with the fresh installation time zone. The solution was to restart cron:
sudo service cron restart
6
Yes, after changing the timezone on a system, one must either restart every service that cares about what time it is, or reboot. I prefer the reboot, to be sure I've caught everything.
– pbr
Apr 8 '12 at 22:48
Oh for God's sake, killed hours on this. Tried service restart after* * * * * touch /tmp/cronworks
did nothing, yet there isRELOAD
at cronlog.
– НЛО
Oct 1 '14 at 3:57
add a comment |
I had some issues with the time zones. Cron was running with the fresh installation time zone. The solution was to restart cron:
sudo service cron restart
I had some issues with the time zones. Cron was running with the fresh installation time zone. The solution was to restart cron:
sudo service cron restart
answered Feb 7 '12 at 14:49
community wiki
luissquall
6
Yes, after changing the timezone on a system, one must either restart every service that cares about what time it is, or reboot. I prefer the reboot, to be sure I've caught everything.
– pbr
Apr 8 '12 at 22:48
Oh for God's sake, killed hours on this. Tried service restart after* * * * * touch /tmp/cronworks
did nothing, yet there isRELOAD
at cronlog.
– НЛО
Oct 1 '14 at 3:57
add a comment |
6
Yes, after changing the timezone on a system, one must either restart every service that cares about what time it is, or reboot. I prefer the reboot, to be sure I've caught everything.
– pbr
Apr 8 '12 at 22:48
Oh for God's sake, killed hours on this. Tried service restart after* * * * * touch /tmp/cronworks
did nothing, yet there isRELOAD
at cronlog.
– НЛО
Oct 1 '14 at 3:57
6
6
Yes, after changing the timezone on a system, one must either restart every service that cares about what time it is, or reboot. I prefer the reboot, to be sure I've caught everything.
– pbr
Apr 8 '12 at 22:48
Yes, after changing the timezone on a system, one must either restart every service that cares about what time it is, or reboot. I prefer the reboot, to be sure I've caught everything.
– pbr
Apr 8 '12 at 22:48
Oh for God's sake, killed hours on this. Tried service restart after
* * * * * touch /tmp/cronworks
did nothing, yet there is RELOAD
at cronlog.– НЛО
Oct 1 '14 at 3:57
Oh for God's sake, killed hours on this. Tried service restart after
* * * * * touch /tmp/cronworks
did nothing, yet there is RELOAD
at cronlog.– НЛО
Oct 1 '14 at 3:57
add a comment |
Absolute path should be used for scripts:
For example, /bin/grep
should be used instead of grep
:
# m h dom mon dow command
0 0 * * * /bin/grep ERROR /home/adam/run.log &> /tmp/errors
Instead of:
# m h dom mon dow command
0 0 * * * grep ERROR /home/adam/run.log &> /tmp/errors
This is especially tricky, because the same command will work when executed from shell. The reason is that cron
does not have the same PATH
environment variable as the user.
3
see geirha answer, you can (must) define cron's PATH
– Capi Etheriel
Jan 27 '11 at 3:22
9
Bzzt. you do NOT need to define the PATH - using absolute paths is the best practice here. "because an executable may be elsewhere on some other computer" doesn't trump "I want it to run exactly this program and not some other one someone put in the path in front of my original program"
– pbr
Apr 8 '12 at 22:55
1
yep this was it for me, outside the cron I could run the command directly, inside the cron it needed full/usr/bin/whatever
path
– Anentropic
Aug 14 '16 at 10:56
add a comment |
Absolute path should be used for scripts:
For example, /bin/grep
should be used instead of grep
:
# m h dom mon dow command
0 0 * * * /bin/grep ERROR /home/adam/run.log &> /tmp/errors
Instead of:
# m h dom mon dow command
0 0 * * * grep ERROR /home/adam/run.log &> /tmp/errors
This is especially tricky, because the same command will work when executed from shell. The reason is that cron
does not have the same PATH
environment variable as the user.
3
see geirha answer, you can (must) define cron's PATH
– Capi Etheriel
Jan 27 '11 at 3:22
9
Bzzt. you do NOT need to define the PATH - using absolute paths is the best practice here. "because an executable may be elsewhere on some other computer" doesn't trump "I want it to run exactly this program and not some other one someone put in the path in front of my original program"
– pbr
Apr 8 '12 at 22:55
1
yep this was it for me, outside the cron I could run the command directly, inside the cron it needed full/usr/bin/whatever
path
– Anentropic
Aug 14 '16 at 10:56
add a comment |
Absolute path should be used for scripts:
For example, /bin/grep
should be used instead of grep
:
# m h dom mon dow command
0 0 * * * /bin/grep ERROR /home/adam/run.log &> /tmp/errors
Instead of:
# m h dom mon dow command
0 0 * * * grep ERROR /home/adam/run.log &> /tmp/errors
This is especially tricky, because the same command will work when executed from shell. The reason is that cron
does not have the same PATH
environment variable as the user.
Absolute path should be used for scripts:
For example, /bin/grep
should be used instead of grep
:
# m h dom mon dow command
0 0 * * * /bin/grep ERROR /home/adam/run.log &> /tmp/errors
Instead of:
# m h dom mon dow command
0 0 * * * grep ERROR /home/adam/run.log &> /tmp/errors
This is especially tricky, because the same command will work when executed from shell. The reason is that cron
does not have the same PATH
environment variable as the user.
answered Jan 24 '11 at 10:02
community wiki
Adam Matan
3
see geirha answer, you can (must) define cron's PATH
– Capi Etheriel
Jan 27 '11 at 3:22
9
Bzzt. you do NOT need to define the PATH - using absolute paths is the best practice here. "because an executable may be elsewhere on some other computer" doesn't trump "I want it to run exactly this program and not some other one someone put in the path in front of my original program"
– pbr
Apr 8 '12 at 22:55
1
yep this was it for me, outside the cron I could run the command directly, inside the cron it needed full/usr/bin/whatever
path
– Anentropic
Aug 14 '16 at 10:56
add a comment |
3
see geirha answer, you can (must) define cron's PATH
– Capi Etheriel
Jan 27 '11 at 3:22
9
Bzzt. you do NOT need to define the PATH - using absolute paths is the best practice here. "because an executable may be elsewhere on some other computer" doesn't trump "I want it to run exactly this program and not some other one someone put in the path in front of my original program"
– pbr
Apr 8 '12 at 22:55
1
yep this was it for me, outside the cron I could run the command directly, inside the cron it needed full/usr/bin/whatever
path
– Anentropic
Aug 14 '16 at 10:56
3
3
see geirha answer, you can (must) define cron's PATH
– Capi Etheriel
Jan 27 '11 at 3:22
see geirha answer, you can (must) define cron's PATH
– Capi Etheriel
Jan 27 '11 at 3:22
9
9
Bzzt. you do NOT need to define the PATH - using absolute paths is the best practice here. "because an executable may be elsewhere on some other computer" doesn't trump "I want it to run exactly this program and not some other one someone put in the path in front of my original program"
– pbr
Apr 8 '12 at 22:55
Bzzt. you do NOT need to define the PATH - using absolute paths is the best practice here. "because an executable may be elsewhere on some other computer" doesn't trump "I want it to run exactly this program and not some other one someone put in the path in front of my original program"
– pbr
Apr 8 '12 at 22:55
1
1
yep this was it for me, outside the cron I could run the command directly, inside the cron it needed full
/usr/bin/whatever
path– Anentropic
Aug 14 '16 at 10:56
yep this was it for me, outside the cron I could run the command directly, inside the cron it needed full
/usr/bin/whatever
path– Anentropic
Aug 14 '16 at 10:56
add a comment |
If your crontab command has a %
symbol in it, cron tries to interpret it. So if you were using any command with a %
in it (such as a format specification to the date command) you will need to escape it.
That and other good gotchas here:
http://www.pantz.org/software/cron/croninfo.html
This is what has been causing my Cron job to fail for the last week. Finally figured out that my Date didn't have an escape character (backslash for any other folks looking for what the escape character is). Yay!
– Valien
Oct 14 '13 at 14:27
2
See also How can I executedate
inside of a cron tab job?
– Jared Beck
Apr 16 '15 at 20:49
This one bit me as well. Thanks!
– stefansundin
Jan 1 '17 at 21:54
add a comment |
If your crontab command has a %
symbol in it, cron tries to interpret it. So if you were using any command with a %
in it (such as a format specification to the date command) you will need to escape it.
That and other good gotchas here:
http://www.pantz.org/software/cron/croninfo.html
This is what has been causing my Cron job to fail for the last week. Finally figured out that my Date didn't have an escape character (backslash for any other folks looking for what the escape character is). Yay!
– Valien
Oct 14 '13 at 14:27
2
See also How can I executedate
inside of a cron tab job?
– Jared Beck
Apr 16 '15 at 20:49
This one bit me as well. Thanks!
– stefansundin
Jan 1 '17 at 21:54
add a comment |
If your crontab command has a %
symbol in it, cron tries to interpret it. So if you were using any command with a %
in it (such as a format specification to the date command) you will need to escape it.
That and other good gotchas here:
http://www.pantz.org/software/cron/croninfo.html
If your crontab command has a %
symbol in it, cron tries to interpret it. So if you were using any command with a %
in it (such as a format specification to the date command) you will need to escape it.
That and other good gotchas here:
http://www.pantz.org/software/cron/croninfo.html
edited Aug 26 '12 at 6:59
community wiki
2 revs, 2 users 75%
JMS
This is what has been causing my Cron job to fail for the last week. Finally figured out that my Date didn't have an escape character (backslash for any other folks looking for what the escape character is). Yay!
– Valien
Oct 14 '13 at 14:27
2
See also How can I executedate
inside of a cron tab job?
– Jared Beck
Apr 16 '15 at 20:49
This one bit me as well. Thanks!
– stefansundin
Jan 1 '17 at 21:54
add a comment |
This is what has been causing my Cron job to fail for the last week. Finally figured out that my Date didn't have an escape character (backslash for any other folks looking for what the escape character is). Yay!
– Valien
Oct 14 '13 at 14:27
2
See also How can I executedate
inside of a cron tab job?
– Jared Beck
Apr 16 '15 at 20:49
This one bit me as well. Thanks!
– stefansundin
Jan 1 '17 at 21:54
This is what has been causing my Cron job to fail for the last week. Finally figured out that my Date didn't have an escape character (backslash for any other folks looking for what the escape character is). Yay!
– Valien
Oct 14 '13 at 14:27
This is what has been causing my Cron job to fail for the last week. Finally figured out that my Date didn't have an escape character (backslash for any other folks looking for what the escape character is). Yay!
– Valien
Oct 14 '13 at 14:27
2
2
See also How can I execute
date
inside of a cron tab job?– Jared Beck
Apr 16 '15 at 20:49
See also How can I execute
date
inside of a cron tab job?– Jared Beck
Apr 16 '15 at 20:49
This one bit me as well. Thanks!
– stefansundin
Jan 1 '17 at 21:54
This one bit me as well. Thanks!
– stefansundin
Jan 1 '17 at 21:54
add a comment |
It is also possible that the user's password has expired. Even root's password can expire. You can tail -f /var/log/cron.log
and you will see cron fail with password expired. You can set the password to never expire by doing this: passwd -x -1 <username>
In some systems (Debian, Ubuntu) logging for cron is not enabled by default. In /etc/rsyslog.conf or /etc/rsyslog.d/50-default.conf the line:
# cron.* /var/log/cron.log
should be edited (sudo nano /etc/rsyslog.conf
) uncommented to:
cron.* /var/log/cron.log
After that, you need to restart rsyslog via
/etc/init.d/rsyslog restart
or
service rsyslog restart
Source: Enable crontab logging in Debian Linux
In some systems (Ubuntu) separate logging file for cron is not enabled by default, but cron related logs are appearing in syslog file. One may use
cat /var/log/syslog | grep cron -i
to view cron-related messages.
I have Debian (wheezy) but there is no /etc/init.d/rsyslog, only inetutils-syslogd and sysklogd. Do I have to install something or just restart one of the two?
– hgoebl
Oct 21 '16 at 11:41
add a comment |
It is also possible that the user's password has expired. Even root's password can expire. You can tail -f /var/log/cron.log
and you will see cron fail with password expired. You can set the password to never expire by doing this: passwd -x -1 <username>
In some systems (Debian, Ubuntu) logging for cron is not enabled by default. In /etc/rsyslog.conf or /etc/rsyslog.d/50-default.conf the line:
# cron.* /var/log/cron.log
should be edited (sudo nano /etc/rsyslog.conf
) uncommented to:
cron.* /var/log/cron.log
After that, you need to restart rsyslog via
/etc/init.d/rsyslog restart
or
service rsyslog restart
Source: Enable crontab logging in Debian Linux
In some systems (Ubuntu) separate logging file for cron is not enabled by default, but cron related logs are appearing in syslog file. One may use
cat /var/log/syslog | grep cron -i
to view cron-related messages.
I have Debian (wheezy) but there is no /etc/init.d/rsyslog, only inetutils-syslogd and sysklogd. Do I have to install something or just restart one of the two?
– hgoebl
Oct 21 '16 at 11:41
add a comment |
It is also possible that the user's password has expired. Even root's password can expire. You can tail -f /var/log/cron.log
and you will see cron fail with password expired. You can set the password to never expire by doing this: passwd -x -1 <username>
In some systems (Debian, Ubuntu) logging for cron is not enabled by default. In /etc/rsyslog.conf or /etc/rsyslog.d/50-default.conf the line:
# cron.* /var/log/cron.log
should be edited (sudo nano /etc/rsyslog.conf
) uncommented to:
cron.* /var/log/cron.log
After that, you need to restart rsyslog via
/etc/init.d/rsyslog restart
or
service rsyslog restart
Source: Enable crontab logging in Debian Linux
In some systems (Ubuntu) separate logging file for cron is not enabled by default, but cron related logs are appearing in syslog file. One may use
cat /var/log/syslog | grep cron -i
to view cron-related messages.
It is also possible that the user's password has expired. Even root's password can expire. You can tail -f /var/log/cron.log
and you will see cron fail with password expired. You can set the password to never expire by doing this: passwd -x -1 <username>
In some systems (Debian, Ubuntu) logging for cron is not enabled by default. In /etc/rsyslog.conf or /etc/rsyslog.d/50-default.conf the line:
# cron.* /var/log/cron.log
should be edited (sudo nano /etc/rsyslog.conf
) uncommented to:
cron.* /var/log/cron.log
After that, you need to restart rsyslog via
/etc/init.d/rsyslog restart
or
service rsyslog restart
Source: Enable crontab logging in Debian Linux
In some systems (Ubuntu) separate logging file for cron is not enabled by default, but cron related logs are appearing in syslog file. One may use
cat /var/log/syslog | grep cron -i
to view cron-related messages.
edited 4 hours ago
community wiki
7 revs, 6 users 33%
unknown
I have Debian (wheezy) but there is no /etc/init.d/rsyslog, only inetutils-syslogd and sysklogd. Do I have to install something or just restart one of the two?
– hgoebl
Oct 21 '16 at 11:41
add a comment |
I have Debian (wheezy) but there is no /etc/init.d/rsyslog, only inetutils-syslogd and sysklogd. Do I have to install something or just restart one of the two?
– hgoebl
Oct 21 '16 at 11:41
I have Debian (wheezy) but there is no /etc/init.d/rsyslog, only inetutils-syslogd and sysklogd. Do I have to install something or just restart one of the two?
– hgoebl
Oct 21 '16 at 11:41
I have Debian (wheezy) but there is no /etc/init.d/rsyslog, only inetutils-syslogd and sysklogd. Do I have to install something or just restart one of the two?
– hgoebl
Oct 21 '16 at 11:41
add a comment |
Cron is calling a script which is not executable.
By running chmod +x /path/to/scrip
the script becomes executable and should resolve this issue.
4
That's not unique tocron
, and easily traceable by simply trying to execute/path/to/script
from the command line.
– Adam Matan
Jan 27 '11 at 6:33
2
If you're used to executing scripts with. scriptname
orsh scriptname
orbash scriptname
, then this becomes acron
-specific problem.
– Eliah Kagan
Nov 24 '11 at 23:09
add a comment |
Cron is calling a script which is not executable.
By running chmod +x /path/to/scrip
the script becomes executable and should resolve this issue.
4
That's not unique tocron
, and easily traceable by simply trying to execute/path/to/script
from the command line.
– Adam Matan
Jan 27 '11 at 6:33
2
If you're used to executing scripts with. scriptname
orsh scriptname
orbash scriptname
, then this becomes acron
-specific problem.
– Eliah Kagan
Nov 24 '11 at 23:09
add a comment |
Cron is calling a script which is not executable.
By running chmod +x /path/to/scrip
the script becomes executable and should resolve this issue.
Cron is calling a script which is not executable.
By running chmod +x /path/to/scrip
the script becomes executable and should resolve this issue.
edited Jan 26 '11 at 18:24
community wiki
2 revs, 2 users 75%
jet
4
That's not unique tocron
, and easily traceable by simply trying to execute/path/to/script
from the command line.
– Adam Matan
Jan 27 '11 at 6:33
2
If you're used to executing scripts with. scriptname
orsh scriptname
orbash scriptname
, then this becomes acron
-specific problem.
– Eliah Kagan
Nov 24 '11 at 23:09
add a comment |
4
That's not unique tocron
, and easily traceable by simply trying to execute/path/to/script
from the command line.
– Adam Matan
Jan 27 '11 at 6:33
2
If you're used to executing scripts with. scriptname
orsh scriptname
orbash scriptname
, then this becomes acron
-specific problem.
– Eliah Kagan
Nov 24 '11 at 23:09
4
4
That's not unique to
cron
, and easily traceable by simply trying to execute /path/to/script
from the command line.– Adam Matan
Jan 27 '11 at 6:33
That's not unique to
cron
, and easily traceable by simply trying to execute /path/to/script
from the command line.– Adam Matan
Jan 27 '11 at 6:33
2
2
If you're used to executing scripts with
. scriptname
or sh scriptname
or bash scriptname
, then this becomes a cron
-specific problem.– Eliah Kagan
Nov 24 '11 at 23:09
If you're used to executing scripts with
. scriptname
or sh scriptname
or bash scriptname
, then this becomes a cron
-specific problem.– Eliah Kagan
Nov 24 '11 at 23:09
add a comment |
If your cronjob invokes GUI-apps, you need to tell them what DISPLAY they should use.
Example: Firefox launch with cron.
Your script should contain export DISPLAY=:0
somewhere.
aplay needed this one for some reason. thank you
– IljaBek
Oct 2 '16 at 10:47
* * * * * export DISPLAY=:0 && <command>
– LoMaPh
Jul 27 '17 at 22:27
add a comment |
If your cronjob invokes GUI-apps, you need to tell them what DISPLAY they should use.
Example: Firefox launch with cron.
Your script should contain export DISPLAY=:0
somewhere.
aplay needed this one for some reason. thank you
– IljaBek
Oct 2 '16 at 10:47
* * * * * export DISPLAY=:0 && <command>
– LoMaPh
Jul 27 '17 at 22:27
add a comment |
If your cronjob invokes GUI-apps, you need to tell them what DISPLAY they should use.
Example: Firefox launch with cron.
Your script should contain export DISPLAY=:0
somewhere.
If your cronjob invokes GUI-apps, you need to tell them what DISPLAY they should use.
Example: Firefox launch with cron.
Your script should contain export DISPLAY=:0
somewhere.
edited Jul 26 '12 at 15:46
community wiki
2 revs, 2 users 77%
andrew
aplay needed this one for some reason. thank you
– IljaBek
Oct 2 '16 at 10:47
* * * * * export DISPLAY=:0 && <command>
– LoMaPh
Jul 27 '17 at 22:27
add a comment |
aplay needed this one for some reason. thank you
– IljaBek
Oct 2 '16 at 10:47
* * * * * export DISPLAY=:0 && <command>
– LoMaPh
Jul 27 '17 at 22:27
aplay needed this one for some reason. thank you
– IljaBek
Oct 2 '16 at 10:47
aplay needed this one for some reason. thank you
– IljaBek
Oct 2 '16 at 10:47
* * * * * export DISPLAY=:0 && <command>
– LoMaPh
Jul 27 '17 at 22:27
* * * * * export DISPLAY=:0 && <command>
– LoMaPh
Jul 27 '17 at 22:27
add a comment |
Permissions problems are quite common, I'm afraid.
Note that a common workaround is to execute everything using root's crontab, which sometimes is a Really Bad Idea. Setting proper permissions is definitely a largely overlooked issue.
Note that if you have a crontab line that is set to pipe output to a file that does not yet exist, and the directory for the file is one that the cron user doesn't have access to, then the line will not execute.
– Evan Donovan
Sep 10 '15 at 16:51
add a comment |
Permissions problems are quite common, I'm afraid.
Note that a common workaround is to execute everything using root's crontab, which sometimes is a Really Bad Idea. Setting proper permissions is definitely a largely overlooked issue.
Note that if you have a crontab line that is set to pipe output to a file that does not yet exist, and the directory for the file is one that the cron user doesn't have access to, then the line will not execute.
– Evan Donovan
Sep 10 '15 at 16:51
add a comment |
Permissions problems are quite common, I'm afraid.
Note that a common workaround is to execute everything using root's crontab, which sometimes is a Really Bad Idea. Setting proper permissions is definitely a largely overlooked issue.
Permissions problems are quite common, I'm afraid.
Note that a common workaround is to execute everything using root's crontab, which sometimes is a Really Bad Idea. Setting proper permissions is definitely a largely overlooked issue.
answered Jan 26 '11 at 15:53
community wiki
user9521
Note that if you have a crontab line that is set to pipe output to a file that does not yet exist, and the directory for the file is one that the cron user doesn't have access to, then the line will not execute.
– Evan Donovan
Sep 10 '15 at 16:51
add a comment |
Note that if you have a crontab line that is set to pipe output to a file that does not yet exist, and the directory for the file is one that the cron user doesn't have access to, then the line will not execute.
– Evan Donovan
Sep 10 '15 at 16:51
Note that if you have a crontab line that is set to pipe output to a file that does not yet exist, and the directory for the file is one that the cron user doesn't have access to, then the line will not execute.
– Evan Donovan
Sep 10 '15 at 16:51
Note that if you have a crontab line that is set to pipe output to a file that does not yet exist, and the directory for the file is one that the cron user doesn't have access to, then the line will not execute.
– Evan Donovan
Sep 10 '15 at 16:51
add a comment |
Insecure cron table permission
A cron table is rejected if its permission is insecure
sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)
The problem is solved with
# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs
First I figured it out myself and then I found your answer! Still thanks a lot! In my case, I had reverted/restored some crontabs in /var/spool/cron/crontabs via SVN which changed its permissions!
– alfonx
Jun 8 '13 at 20:40
add a comment |
Insecure cron table permission
A cron table is rejected if its permission is insecure
sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)
The problem is solved with
# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs
First I figured it out myself and then I found your answer! Still thanks a lot! In my case, I had reverted/restored some crontabs in /var/spool/cron/crontabs via SVN which changed its permissions!
– alfonx
Jun 8 '13 at 20:40
add a comment |
Insecure cron table permission
A cron table is rejected if its permission is insecure
sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)
The problem is solved with
# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs
Insecure cron table permission
A cron table is rejected if its permission is insecure
sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)
The problem is solved with
# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs
edited Jun 15 '13 at 3:12
community wiki
4 revs
John Peterson
First I figured it out myself and then I found your answer! Still thanks a lot! In my case, I had reverted/restored some crontabs in /var/spool/cron/crontabs via SVN which changed its permissions!
– alfonx
Jun 8 '13 at 20:40
add a comment |
First I figured it out myself and then I found your answer! Still thanks a lot! In my case, I had reverted/restored some crontabs in /var/spool/cron/crontabs via SVN which changed its permissions!
– alfonx
Jun 8 '13 at 20:40
First I figured it out myself and then I found your answer! Still thanks a lot! In my case, I had reverted/restored some crontabs in /var/spool/cron/crontabs via SVN which changed its permissions!
– alfonx
Jun 8 '13 at 20:40
First I figured it out myself and then I found your answer! Still thanks a lot! In my case, I had reverted/restored some crontabs in /var/spool/cron/crontabs via SVN which changed its permissions!
– alfonx
Jun 8 '13 at 20:40
add a comment |
Script is location-sensitive. This is related to always using absolute paths in a script, but not quite the same. Your cron job may need to cd
to a specific directory before running, e.g. a rake task on a Rails application may need to be in the application root for Rake to find the correct task, not to mention the appropriate database configuration, etc.
So a crontab entry of
23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production
would be better as
23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production
Or, to keep the crontab entry simpler and less brittle:
23 3 * * * /home/<user>/scripts/session-purge.sh
with the following code in /home/<user>/scripts/session-purge.sh
:
cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production
1
If the script being invoked from cron is written in an interpreted language like PHP, you may need to set the working directory in the script itself. For example, in PHP:chdir(dirname(__FILE__));
– Evan Donovan
Sep 10 '15 at 16:14
Just got caught with this one: the script used to be in the root of my home directory, but then I moved it (and updated the crontab) and couldn't figure out why it wasn't working. Turns out the script was using a relative path, assuming that it was relative to the location of the script but it was in fact relative to the root of my home directory because that was the working directory that cron was using, which is why the script worked when it was in the root of my home directory (because the script's expected working directory and it's actual working just happened to coincide).
– Micheal Johnson
Feb 4 '16 at 18:36
add a comment |
Script is location-sensitive. This is related to always using absolute paths in a script, but not quite the same. Your cron job may need to cd
to a specific directory before running, e.g. a rake task on a Rails application may need to be in the application root for Rake to find the correct task, not to mention the appropriate database configuration, etc.
So a crontab entry of
23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production
would be better as
23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production
Or, to keep the crontab entry simpler and less brittle:
23 3 * * * /home/<user>/scripts/session-purge.sh
with the following code in /home/<user>/scripts/session-purge.sh
:
cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production
1
If the script being invoked from cron is written in an interpreted language like PHP, you may need to set the working directory in the script itself. For example, in PHP:chdir(dirname(__FILE__));
– Evan Donovan
Sep 10 '15 at 16:14
Just got caught with this one: the script used to be in the root of my home directory, but then I moved it (and updated the crontab) and couldn't figure out why it wasn't working. Turns out the script was using a relative path, assuming that it was relative to the location of the script but it was in fact relative to the root of my home directory because that was the working directory that cron was using, which is why the script worked when it was in the root of my home directory (because the script's expected working directory and it's actual working just happened to coincide).
– Micheal Johnson
Feb 4 '16 at 18:36
add a comment |
Script is location-sensitive. This is related to always using absolute paths in a script, but not quite the same. Your cron job may need to cd
to a specific directory before running, e.g. a rake task on a Rails application may need to be in the application root for Rake to find the correct task, not to mention the appropriate database configuration, etc.
So a crontab entry of
23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production
would be better as
23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production
Or, to keep the crontab entry simpler and less brittle:
23 3 * * * /home/<user>/scripts/session-purge.sh
with the following code in /home/<user>/scripts/session-purge.sh
:
cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production
Script is location-sensitive. This is related to always using absolute paths in a script, but not quite the same. Your cron job may need to cd
to a specific directory before running, e.g. a rake task on a Rails application may need to be in the application root for Rake to find the correct task, not to mention the appropriate database configuration, etc.
So a crontab entry of
23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production
would be better as
23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production
Or, to keep the crontab entry simpler and less brittle:
23 3 * * * /home/<user>/scripts/session-purge.sh
with the following code in /home/<user>/scripts/session-purge.sh
:
cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production
edited Nov 29 '11 at 15:20
community wiki
2 revs
pjmorse
1
If the script being invoked from cron is written in an interpreted language like PHP, you may need to set the working directory in the script itself. For example, in PHP:chdir(dirname(__FILE__));
– Evan Donovan
Sep 10 '15 at 16:14
Just got caught with this one: the script used to be in the root of my home directory, but then I moved it (and updated the crontab) and couldn't figure out why it wasn't working. Turns out the script was using a relative path, assuming that it was relative to the location of the script but it was in fact relative to the root of my home directory because that was the working directory that cron was using, which is why the script worked when it was in the root of my home directory (because the script's expected working directory and it's actual working just happened to coincide).
– Micheal Johnson
Feb 4 '16 at 18:36
add a comment |
1
If the script being invoked from cron is written in an interpreted language like PHP, you may need to set the working directory in the script itself. For example, in PHP:chdir(dirname(__FILE__));
– Evan Donovan
Sep 10 '15 at 16:14
Just got caught with this one: the script used to be in the root of my home directory, but then I moved it (and updated the crontab) and couldn't figure out why it wasn't working. Turns out the script was using a relative path, assuming that it was relative to the location of the script but it was in fact relative to the root of my home directory because that was the working directory that cron was using, which is why the script worked when it was in the root of my home directory (because the script's expected working directory and it's actual working just happened to coincide).
– Micheal Johnson
Feb 4 '16 at 18:36
1
1
If the script being invoked from cron is written in an interpreted language like PHP, you may need to set the working directory in the script itself. For example, in PHP:
chdir(dirname(__FILE__));
– Evan Donovan
Sep 10 '15 at 16:14
If the script being invoked from cron is written in an interpreted language like PHP, you may need to set the working directory in the script itself. For example, in PHP:
chdir(dirname(__FILE__));
– Evan Donovan
Sep 10 '15 at 16:14
Just got caught with this one: the script used to be in the root of my home directory, but then I moved it (and updated the crontab) and couldn't figure out why it wasn't working. Turns out the script was using a relative path, assuming that it was relative to the location of the script but it was in fact relative to the root of my home directory because that was the working directory that cron was using, which is why the script worked when it was in the root of my home directory (because the script's expected working directory and it's actual working just happened to coincide).
– Micheal Johnson
Feb 4 '16 at 18:36
Just got caught with this one: the script used to be in the root of my home directory, but then I moved it (and updated the crontab) and couldn't figure out why it wasn't working. Turns out the script was using a relative path, assuming that it was relative to the location of the script but it was in fact relative to the root of my home directory because that was the working directory that cron was using, which is why the script worked when it was in the root of my home directory (because the script's expected working directory and it's actual working just happened to coincide).
– Micheal Johnson
Feb 4 '16 at 18:36
add a comment |
Crontab specs which worked in the past can break when moved from one crontab file to another. Sometimes the reason is that you've moved the spec from a system crontab file to a user crontab file or vice-versa.
The cron job specification format differs between users' crontab files (/var/spool/cron/username or /var/spool/cron/crontabs/username) and the system crontabs (/etc/crontab
and the the files in /etc/cron.d
).
The system crontabs have an extra field 'user' right before the command-to-run.
This will cause errors stating things like george; command not found
when you move a command out of /etc/crontab
or a file in /etc/cron.d
into a user's crontab file.
Conversely, cron will deliver errors like /usr/bin/restartxyz is not a valid username
or similar when the reverse occurs.
add a comment |
Crontab specs which worked in the past can break when moved from one crontab file to another. Sometimes the reason is that you've moved the spec from a system crontab file to a user crontab file or vice-versa.
The cron job specification format differs between users' crontab files (/var/spool/cron/username or /var/spool/cron/crontabs/username) and the system crontabs (/etc/crontab
and the the files in /etc/cron.d
).
The system crontabs have an extra field 'user' right before the command-to-run.
This will cause errors stating things like george; command not found
when you move a command out of /etc/crontab
or a file in /etc/cron.d
into a user's crontab file.
Conversely, cron will deliver errors like /usr/bin/restartxyz is not a valid username
or similar when the reverse occurs.
add a comment |
Crontab specs which worked in the past can break when moved from one crontab file to another. Sometimes the reason is that you've moved the spec from a system crontab file to a user crontab file or vice-versa.
The cron job specification format differs between users' crontab files (/var/spool/cron/username or /var/spool/cron/crontabs/username) and the system crontabs (/etc/crontab
and the the files in /etc/cron.d
).
The system crontabs have an extra field 'user' right before the command-to-run.
This will cause errors stating things like george; command not found
when you move a command out of /etc/crontab
or a file in /etc/cron.d
into a user's crontab file.
Conversely, cron will deliver errors like /usr/bin/restartxyz is not a valid username
or similar when the reverse occurs.
Crontab specs which worked in the past can break when moved from one crontab file to another. Sometimes the reason is that you've moved the spec from a system crontab file to a user crontab file or vice-versa.
The cron job specification format differs between users' crontab files (/var/spool/cron/username or /var/spool/cron/crontabs/username) and the system crontabs (/etc/crontab
and the the files in /etc/cron.d
).
The system crontabs have an extra field 'user' right before the command-to-run.
This will cause errors stating things like george; command not found
when you move a command out of /etc/crontab
or a file in /etc/cron.d
into a user's crontab file.
Conversely, cron will deliver errors like /usr/bin/restartxyz is not a valid username
or similar when the reverse occurs.
edited Oct 25 '13 at 15:04
community wiki
4 revs, 3 users 80%
pbr
add a comment |
add a comment |
cron script is invoking a command with --verbose option
I had a cron script fail on me because I was in autopilot while typing the script and I included the --verbose option:
#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands
The script ran fine when executing from shell, but failed when running from crontab because the verbose output goes to stdout when run from shell, but nowhere when run from crontab. Easy fix to remove the 'v':
#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
5
Why is this causing a failure? Buffer issues?
– Adam Matan
May 31 '12 at 6:38
Any outputs or errors trriggred via cron jobs is gooing to sent to your mailbox.So we should never forget to care about these errors/output.We can redirect them to any file or /dev/null
– Nischay
Sep 27 '13 at 11:32
add a comment |
cron script is invoking a command with --verbose option
I had a cron script fail on me because I was in autopilot while typing the script and I included the --verbose option:
#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands
The script ran fine when executing from shell, but failed when running from crontab because the verbose output goes to stdout when run from shell, but nowhere when run from crontab. Easy fix to remove the 'v':
#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
5
Why is this causing a failure? Buffer issues?
– Adam Matan
May 31 '12 at 6:38
Any outputs or errors trriggred via cron jobs is gooing to sent to your mailbox.So we should never forget to care about these errors/output.We can redirect them to any file or /dev/null
– Nischay
Sep 27 '13 at 11:32
add a comment |
cron script is invoking a command with --verbose option
I had a cron script fail on me because I was in autopilot while typing the script and I included the --verbose option:
#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands
The script ran fine when executing from shell, but failed when running from crontab because the verbose output goes to stdout when run from shell, but nowhere when run from crontab. Easy fix to remove the 'v':
#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
cron script is invoking a command with --verbose option
I had a cron script fail on me because I was in autopilot while typing the script and I included the --verbose option:
#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands
The script ran fine when executing from shell, but failed when running from crontab because the verbose output goes to stdout when run from shell, but nowhere when run from crontab. Easy fix to remove the 'v':
#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
edited Jun 3 '12 at 6:59
community wiki
2 revs, 2 users 97%
Aaron Peart
5
Why is this causing a failure? Buffer issues?
– Adam Matan
May 31 '12 at 6:38
Any outputs or errors trriggred via cron jobs is gooing to sent to your mailbox.So we should never forget to care about these errors/output.We can redirect them to any file or /dev/null
– Nischay
Sep 27 '13 at 11:32
add a comment |
5
Why is this causing a failure? Buffer issues?
– Adam Matan
May 31 '12 at 6:38
Any outputs or errors trriggred via cron jobs is gooing to sent to your mailbox.So we should never forget to care about these errors/output.We can redirect them to any file or /dev/null
– Nischay
Sep 27 '13 at 11:32
5
5
Why is this causing a failure? Buffer issues?
– Adam Matan
May 31 '12 at 6:38
Why is this causing a failure? Buffer issues?
– Adam Matan
May 31 '12 at 6:38
Any outputs or errors trriggred via cron jobs is gooing to sent to your mailbox.So we should never forget to care about these errors/output.We can redirect them to any file or /dev/null
– Nischay
Sep 27 '13 at 11:32
Any outputs or errors trriggred via cron jobs is gooing to sent to your mailbox.So we should never forget to care about these errors/output.We can redirect them to any file or /dev/null
– Nischay
Sep 27 '13 at 11:32
add a comment |
Most frequent reason I have seen cron fail in an incorrectly stated schedule. It takes practice to specify a job scheduled for 11:15 pm as 30 23 * * *
instead of * * 11 15 *
or 11 15 * * *
. Day of week for jobs after midnight also gets confused M-F is 2-6
after midnight not 1-5
. Specific dates are usually a problem as we rarely use them * * 3 1 *
is not March 3rd.
If your work with different platforms using unsupported options such as 2/3
in time specifications can also cause failures. This is a very useful option but not universally available. I have also run across issues will lists like 1-5
or 1,3,5
.
Using unqualified paths have also caused problems. The default path is usually /bin:/usr/bin
so only standard commands will run. These directories usually don't have the desired command. This also affects scripts using non standard commands. Other environment variables can also be missing.
Clobbering an existing crontab entirely has caused me problems. I now load from a file copy. This can be recovered from the existing crontab using crontab -l
if it gets clobbered. I keep the copy of crontab in ~/bin. It is commented throughout and ends with the line # EOF
. This is reloaded daily from a crontab entry like:
#!/usr/bin/crontab
# Reload this crontab
#
54 12 * * * ${HOME}/bin/crontab
The reload command above relies on an executable crontab with a bang path running crontab. Some systems require the running crontab in the command and specifying the file. If the directory is network shared, then I often use crontab.$(hostname)
as the name of the file. This will eventually correct cases where the wrong crontab is loaded on the wrong server.
Using the file provides a backup of what the crontab should be, and allows temporary edits (the only time I use crontab -e
) to be backed out automatically. There are headers available which help with getting the scheduling parameters right. I have added them when inexperience users would be editing a crontab.
Rarely, I have run into commands that require user input. These fail under crontab, although some will work with input redirection.
2
This covers three separate problems. Can they be split into separate answers?
– Eliah Kagan
Nov 24 '11 at 23:07
9
Can you explain how30 23 * * *
translates to 11:15 PM?
– JYelton
Jan 10 '14 at 19:23
add a comment |
Most frequent reason I have seen cron fail in an incorrectly stated schedule. It takes practice to specify a job scheduled for 11:15 pm as 30 23 * * *
instead of * * 11 15 *
or 11 15 * * *
. Day of week for jobs after midnight also gets confused M-F is 2-6
after midnight not 1-5
. Specific dates are usually a problem as we rarely use them * * 3 1 *
is not March 3rd.
If your work with different platforms using unsupported options such as 2/3
in time specifications can also cause failures. This is a very useful option but not universally available. I have also run across issues will lists like 1-5
or 1,3,5
.
Using unqualified paths have also caused problems. The default path is usually /bin:/usr/bin
so only standard commands will run. These directories usually don't have the desired command. This also affects scripts using non standard commands. Other environment variables can also be missing.
Clobbering an existing crontab entirely has caused me problems. I now load from a file copy. This can be recovered from the existing crontab using crontab -l
if it gets clobbered. I keep the copy of crontab in ~/bin. It is commented throughout and ends with the line # EOF
. This is reloaded daily from a crontab entry like:
#!/usr/bin/crontab
# Reload this crontab
#
54 12 * * * ${HOME}/bin/crontab
The reload command above relies on an executable crontab with a bang path running crontab. Some systems require the running crontab in the command and specifying the file. If the directory is network shared, then I often use crontab.$(hostname)
as the name of the file. This will eventually correct cases where the wrong crontab is loaded on the wrong server.
Using the file provides a backup of what the crontab should be, and allows temporary edits (the only time I use crontab -e
) to be backed out automatically. There are headers available which help with getting the scheduling parameters right. I have added them when inexperience users would be editing a crontab.
Rarely, I have run into commands that require user input. These fail under crontab, although some will work with input redirection.
2
This covers three separate problems. Can they be split into separate answers?
– Eliah Kagan
Nov 24 '11 at 23:07
9
Can you explain how30 23 * * *
translates to 11:15 PM?
– JYelton
Jan 10 '14 at 19:23
add a comment |
Most frequent reason I have seen cron fail in an incorrectly stated schedule. It takes practice to specify a job scheduled for 11:15 pm as 30 23 * * *
instead of * * 11 15 *
or 11 15 * * *
. Day of week for jobs after midnight also gets confused M-F is 2-6
after midnight not 1-5
. Specific dates are usually a problem as we rarely use them * * 3 1 *
is not March 3rd.
If your work with different platforms using unsupported options such as 2/3
in time specifications can also cause failures. This is a very useful option but not universally available. I have also run across issues will lists like 1-5
or 1,3,5
.
Using unqualified paths have also caused problems. The default path is usually /bin:/usr/bin
so only standard commands will run. These directories usually don't have the desired command. This also affects scripts using non standard commands. Other environment variables can also be missing.
Clobbering an existing crontab entirely has caused me problems. I now load from a file copy. This can be recovered from the existing crontab using crontab -l
if it gets clobbered. I keep the copy of crontab in ~/bin. It is commented throughout and ends with the line # EOF
. This is reloaded daily from a crontab entry like:
#!/usr/bin/crontab
# Reload this crontab
#
54 12 * * * ${HOME}/bin/crontab
The reload command above relies on an executable crontab with a bang path running crontab. Some systems require the running crontab in the command and specifying the file. If the directory is network shared, then I often use crontab.$(hostname)
as the name of the file. This will eventually correct cases where the wrong crontab is loaded on the wrong server.
Using the file provides a backup of what the crontab should be, and allows temporary edits (the only time I use crontab -e
) to be backed out automatically. There are headers available which help with getting the scheduling parameters right. I have added them when inexperience users would be editing a crontab.
Rarely, I have run into commands that require user input. These fail under crontab, although some will work with input redirection.
Most frequent reason I have seen cron fail in an incorrectly stated schedule. It takes practice to specify a job scheduled for 11:15 pm as 30 23 * * *
instead of * * 11 15 *
or 11 15 * * *
. Day of week for jobs after midnight also gets confused M-F is 2-6
after midnight not 1-5
. Specific dates are usually a problem as we rarely use them * * 3 1 *
is not March 3rd.
If your work with different platforms using unsupported options such as 2/3
in time specifications can also cause failures. This is a very useful option but not universally available. I have also run across issues will lists like 1-5
or 1,3,5
.
Using unqualified paths have also caused problems. The default path is usually /bin:/usr/bin
so only standard commands will run. These directories usually don't have the desired command. This also affects scripts using non standard commands. Other environment variables can also be missing.
Clobbering an existing crontab entirely has caused me problems. I now load from a file copy. This can be recovered from the existing crontab using crontab -l
if it gets clobbered. I keep the copy of crontab in ~/bin. It is commented throughout and ends with the line # EOF
. This is reloaded daily from a crontab entry like:
#!/usr/bin/crontab
# Reload this crontab
#
54 12 * * * ${HOME}/bin/crontab
The reload command above relies on an executable crontab with a bang path running crontab. Some systems require the running crontab in the command and specifying the file. If the directory is network shared, then I often use crontab.$(hostname)
as the name of the file. This will eventually correct cases where the wrong crontab is loaded on the wrong server.
Using the file provides a backup of what the crontab should be, and allows temporary edits (the only time I use crontab -e
) to be backed out automatically. There are headers available which help with getting the scheduling parameters right. I have added them when inexperience users would be editing a crontab.
Rarely, I have run into commands that require user input. These fail under crontab, although some will work with input redirection.
edited Feb 1 '11 at 18:37
community wiki
2 revs
BillThor
2
This covers three separate problems. Can they be split into separate answers?
– Eliah Kagan
Nov 24 '11 at 23:07
9
Can you explain how30 23 * * *
translates to 11:15 PM?
– JYelton
Jan 10 '14 at 19:23
add a comment |
2
This covers three separate problems. Can they be split into separate answers?
– Eliah Kagan
Nov 24 '11 at 23:07
9
Can you explain how30 23 * * *
translates to 11:15 PM?
– JYelton
Jan 10 '14 at 19:23
2
2
This covers three separate problems. Can they be split into separate answers?
– Eliah Kagan
Nov 24 '11 at 23:07
This covers three separate problems. Can they be split into separate answers?
– Eliah Kagan
Nov 24 '11 at 23:07
9
9
Can you explain how
30 23 * * *
translates to 11:15 PM?– JYelton
Jan 10 '14 at 19:23
Can you explain how
30 23 * * *
translates to 11:15 PM?– JYelton
Jan 10 '14 at 19:23
add a comment |
If you are accessing an account via SSH keys it is possible to login to the account but not notice that the password on the account is locked (e.g. due to expiring or invalid password attempts)
If the system is using PAM and the account is locked, this can stop its cronjob from running. (I've tested this on Solaris, but not on Ubuntu)
You may find messages like this in /var/adm/messages:
Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
All you should need to do is run:
# passwd -u <USERNAME>
as root to unlock the account, and the crontab should work again.
add a comment |
If you are accessing an account via SSH keys it is possible to login to the account but not notice that the password on the account is locked (e.g. due to expiring or invalid password attempts)
If the system is using PAM and the account is locked, this can stop its cronjob from running. (I've tested this on Solaris, but not on Ubuntu)
You may find messages like this in /var/adm/messages:
Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
All you should need to do is run:
# passwd -u <USERNAME>
as root to unlock the account, and the crontab should work again.
add a comment |
If you are accessing an account via SSH keys it is possible to login to the account but not notice that the password on the account is locked (e.g. due to expiring or invalid password attempts)
If the system is using PAM and the account is locked, this can stop its cronjob from running. (I've tested this on Solaris, but not on Ubuntu)
You may find messages like this in /var/adm/messages:
Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
All you should need to do is run:
# passwd -u <USERNAME>
as root to unlock the account, and the crontab should work again.
If you are accessing an account via SSH keys it is possible to login to the account but not notice that the password on the account is locked (e.g. due to expiring or invalid password attempts)
If the system is using PAM and the account is locked, this can stop its cronjob from running. (I've tested this on Solaris, but not on Ubuntu)
You may find messages like this in /var/adm/messages:
Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
All you should need to do is run:
# passwd -u <USERNAME>
as root to unlock the account, and the crontab should work again.
answered Oct 24 '12 at 7:22
community wiki
JohnGH
add a comment |
add a comment |
If you have a command like this:
* * * * * /path/to/script >> /tmp/output
and it doesn't work and you can't see any output, it may not necessarily mean cron isn't working. The script could be broken and the output going to stderr which doesn't get passed to /tmp/output. Check this isn't the case, by capturing this output as well:
* * * * * /path/to/script >> /tmp/output 2>&1
to see if this helps you catch your issue.
add a comment |
If you have a command like this:
* * * * * /path/to/script >> /tmp/output
and it doesn't work and you can't see any output, it may not necessarily mean cron isn't working. The script could be broken and the output going to stderr which doesn't get passed to /tmp/output. Check this isn't the case, by capturing this output as well:
* * * * * /path/to/script >> /tmp/output 2>&1
to see if this helps you catch your issue.
add a comment |
If you have a command like this:
* * * * * /path/to/script >> /tmp/output
and it doesn't work and you can't see any output, it may not necessarily mean cron isn't working. The script could be broken and the output going to stderr which doesn't get passed to /tmp/output. Check this isn't the case, by capturing this output as well:
* * * * * /path/to/script >> /tmp/output 2>&1
to see if this helps you catch your issue.
If you have a command like this:
* * * * * /path/to/script >> /tmp/output
and it doesn't work and you can't see any output, it may not necessarily mean cron isn't working. The script could be broken and the output going to stderr which doesn't get passed to /tmp/output. Check this isn't the case, by capturing this output as well:
* * * * * /path/to/script >> /tmp/output 2>&1
to see if this helps you catch your issue.
edited Apr 18 '18 at 18:26
community wiki
3 revs, 3 users 76%
Philluminati
add a comment |
add a comment |
=== Docker alert ===
If you're using docker,
I think it is proper to add that I couldn't manage to make cron to run in the background.
To run a cron job inside the container, I used supervisor and ran cron -f
, together with the other process.
Edit: Another issue - I also didn't manage to get it work when running the container with HOST networking. See this issue here also: https://github.com/phusion/baseimage-docker/issues/144
1
stackoverflow.com/questions/37458287/…
– Simon D
Dec 17 '18 at 9:53
add a comment |
=== Docker alert ===
If you're using docker,
I think it is proper to add that I couldn't manage to make cron to run in the background.
To run a cron job inside the container, I used supervisor and ran cron -f
, together with the other process.
Edit: Another issue - I also didn't manage to get it work when running the container with HOST networking. See this issue here also: https://github.com/phusion/baseimage-docker/issues/144
1
stackoverflow.com/questions/37458287/…
– Simon D
Dec 17 '18 at 9:53
add a comment |
=== Docker alert ===
If you're using docker,
I think it is proper to add that I couldn't manage to make cron to run in the background.
To run a cron job inside the container, I used supervisor and ran cron -f
, together with the other process.
Edit: Another issue - I also didn't manage to get it work when running the container with HOST networking. See this issue here also: https://github.com/phusion/baseimage-docker/issues/144
=== Docker alert ===
If you're using docker,
I think it is proper to add that I couldn't manage to make cron to run in the background.
To run a cron job inside the container, I used supervisor and ran cron -f
, together with the other process.
Edit: Another issue - I also didn't manage to get it work when running the container with HOST networking. See this issue here also: https://github.com/phusion/baseimage-docker/issues/144
edited May 20 '15 at 15:48
community wiki
2 revs
AlonL
1
stackoverflow.com/questions/37458287/…
– Simon D
Dec 17 '18 at 9:53
add a comment |
1
stackoverflow.com/questions/37458287/…
– Simon D
Dec 17 '18 at 9:53
1
1
stackoverflow.com/questions/37458287/…
– Simon D
Dec 17 '18 at 9:53
stackoverflow.com/questions/37458287/…
– Simon D
Dec 17 '18 at 9:53
add a comment |
In my case cron and crontab had different owners.
NOT working I had this:
User@Uva ~ $ ps -ef | grep cron | grep -v grep
User 2940 7284 pty1 19:58:41 /usr/bin/crontab
SYSTEM 11292 636 ? 22:14:15 /usr/sbin/cro
Basically I had to run cron-config and answer the questions correctly. There is a point where I was required to enter my Win7 user password for my 'User' account. From reading I did, it looks like this is a potential security issue but I am the only administrator on a single home network so I decided it was OK.
Here is the command sequence that got me going:
User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.
Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec
You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
the passwords. There are three methods to do that, as explained in
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
which provides access to network drives, or if you are using the
cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no
Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no
Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User
Reenter: User
Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.
Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.
Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.
In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.
Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.
If you cannot fix the problem, then report it to cygwin@cygwin.com.
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.
WARNING: PATH may be set differently under cron than in interactive shells.
Names such as "find" and "date" may refer to Windows programs.
User@Uva ~ $ ps -ef | grep cron | grep -v grep
User 2944 11780 ? 03:31:10 /usr/sbin/cron
User 2940 7284 pty1 19:58:41 /usr/bin/crontab
User@Uva ~ $
1
Although well documented, this looks like a Cygwin-specific point; does it really belong in askubuntu?
– sxc731
Feb 7 '16 at 11:14
add a comment |
In my case cron and crontab had different owners.
NOT working I had this:
User@Uva ~ $ ps -ef | grep cron | grep -v grep
User 2940 7284 pty1 19:58:41 /usr/bin/crontab
SYSTEM 11292 636 ? 22:14:15 /usr/sbin/cro
Basically I had to run cron-config and answer the questions correctly. There is a point where I was required to enter my Win7 user password for my 'User' account. From reading I did, it looks like this is a potential security issue but I am the only administrator on a single home network so I decided it was OK.
Here is the command sequence that got me going:
User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.
Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec
You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
the passwords. There are three methods to do that, as explained in
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
which provides access to network drives, or if you are using the
cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no
Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no
Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User
Reenter: User
Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.
Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.
Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.
In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.
Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.
If you cannot fix the problem, then report it to cygwin@cygwin.com.
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.
WARNING: PATH may be set differently under cron than in interactive shells.
Names such as "find" and "date" may refer to Windows programs.
User@Uva ~ $ ps -ef | grep cron | grep -v grep
User 2944 11780 ? 03:31:10 /usr/sbin/cron
User 2940 7284 pty1 19:58:41 /usr/bin/crontab
User@Uva ~ $
1
Although well documented, this looks like a Cygwin-specific point; does it really belong in askubuntu?
– sxc731
Feb 7 '16 at 11:14
add a comment |
In my case cron and crontab had different owners.
NOT working I had this:
User@Uva ~ $ ps -ef | grep cron | grep -v grep
User 2940 7284 pty1 19:58:41 /usr/bin/crontab
SYSTEM 11292 636 ? 22:14:15 /usr/sbin/cro
Basically I had to run cron-config and answer the questions correctly. There is a point where I was required to enter my Win7 user password for my 'User' account. From reading I did, it looks like this is a potential security issue but I am the only administrator on a single home network so I decided it was OK.
Here is the command sequence that got me going:
User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.
Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec
You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
the passwords. There are three methods to do that, as explained in
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
which provides access to network drives, or if you are using the
cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no
Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no
Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User
Reenter: User
Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.
Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.
Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.
In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.
Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.
If you cannot fix the problem, then report it to cygwin@cygwin.com.
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.
WARNING: PATH may be set differently under cron than in interactive shells.
Names such as "find" and "date" may refer to Windows programs.
User@Uva ~ $ ps -ef | grep cron | grep -v grep
User 2944 11780 ? 03:31:10 /usr/sbin/cron
User 2940 7284 pty1 19:58:41 /usr/bin/crontab
User@Uva ~ $
In my case cron and crontab had different owners.
NOT working I had this:
User@Uva ~ $ ps -ef | grep cron | grep -v grep
User 2940 7284 pty1 19:58:41 /usr/bin/crontab
SYSTEM 11292 636 ? 22:14:15 /usr/sbin/cro
Basically I had to run cron-config and answer the questions correctly. There is a point where I was required to enter my Win7 user password for my 'User' account. From reading I did, it looks like this is a potential security issue but I am the only administrator on a single home network so I decided it was OK.
Here is the command sequence that got me going:
User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.
Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec
You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
the passwords. There are three methods to do that, as explained in
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
which provides access to network drives, or if you are using the
cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no
Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no
Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User
Reenter: User
Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.
Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.
Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.
In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.
Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.
If you cannot fix the problem, then report it to cygwin@cygwin.com.
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.
WARNING: PATH may be set differently under cron than in interactive shells.
Names such as "find" and "date" may refer to Windows programs.
User@Uva ~ $ ps -ef | grep cron | grep -v grep
User 2944 11780 ? 03:31:10 /usr/sbin/cron
User 2940 7284 pty1 19:58:41 /usr/bin/crontab
User@Uva ~ $
answered Dec 10 '15 at 9:20
community wiki
KiloOne
1
Although well documented, this looks like a Cygwin-specific point; does it really belong in askubuntu?
– sxc731
Feb 7 '16 at 11:14
add a comment |
1
Although well documented, this looks like a Cygwin-specific point; does it really belong in askubuntu?
– sxc731
Feb 7 '16 at 11:14
1
1
Although well documented, this looks like a Cygwin-specific point; does it really belong in askubuntu?
– sxc731
Feb 7 '16 at 11:14
Although well documented, this looks like a Cygwin-specific point; does it really belong in askubuntu?
– sxc731
Feb 7 '16 at 11:14
add a comment |
I was writing an install shell script that creates another script to purge old transaction data from a database. As a part of the task it had to configure daily cron
job to run at an arbitrary time, when the database load was low.
I created a file mycronjob
with cron schedule, username & the command and copied it to the /etc/cron.d
directory. My two gotchas:
mycronjob
file had to be owned by root to run- I had to set permissions of the file to 644 - 664 would not run.
A permission problem will appear in /var/log/syslog
as something similar to:
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)
The first line refers to /etc/crontab
file and the later to a file I placed under /etc/cront.d
.
add a comment |
I was writing an install shell script that creates another script to purge old transaction data from a database. As a part of the task it had to configure daily cron
job to run at an arbitrary time, when the database load was low.
I created a file mycronjob
with cron schedule, username & the command and copied it to the /etc/cron.d
directory. My two gotchas:
mycronjob
file had to be owned by root to run- I had to set permissions of the file to 644 - 664 would not run.
A permission problem will appear in /var/log/syslog
as something similar to:
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)
The first line refers to /etc/crontab
file and the later to a file I placed under /etc/cront.d
.
add a comment |
I was writing an install shell script that creates another script to purge old transaction data from a database. As a part of the task it had to configure daily cron
job to run at an arbitrary time, when the database load was low.
I created a file mycronjob
with cron schedule, username & the command and copied it to the /etc/cron.d
directory. My two gotchas:
mycronjob
file had to be owned by root to run- I had to set permissions of the file to 644 - 664 would not run.
A permission problem will appear in /var/log/syslog
as something similar to:
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)
The first line refers to /etc/crontab
file and the later to a file I placed under /etc/cront.d
.
I was writing an install shell script that creates another script to purge old transaction data from a database. As a part of the task it had to configure daily cron
job to run at an arbitrary time, when the database load was low.
I created a file mycronjob
with cron schedule, username & the command and copied it to the /etc/cron.d
directory. My two gotchas:
mycronjob
file had to be owned by root to run- I had to set permissions of the file to 644 - 664 would not run.
A permission problem will appear in /var/log/syslog
as something similar to:
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)
The first line refers to /etc/crontab
file and the later to a file I placed under /etc/cront.d
.
edited Apr 24 '17 at 19:53
community wiki
4 revs, 4 users 41%
Izik Golan
add a comment |
add a comment |
Line written in a way crontab doesn't understand. It needs to be correctly written. Here's CrontabHowTo.
1
How can this be debugged?
– Adam Matan
Jan 27 '11 at 6:34
Reviewing cron's error log is the most common way. IIRC 'crontab -e' does a syntax parse after you've edited the file as well - but that might not be universal.
– pbr
Apr 8 '12 at 22:47
add a comment |
Line written in a way crontab doesn't understand. It needs to be correctly written. Here's CrontabHowTo.
1
How can this be debugged?
– Adam Matan
Jan 27 '11 at 6:34
Reviewing cron's error log is the most common way. IIRC 'crontab -e' does a syntax parse after you've edited the file as well - but that might not be universal.
– pbr
Apr 8 '12 at 22:47
add a comment |
Line written in a way crontab doesn't understand. It needs to be correctly written. Here's CrontabHowTo.
Line written in a way crontab doesn't understand. It needs to be correctly written. Here's CrontabHowTo.
edited Feb 2 '11 at 19:52
community wiki
4 revs, 3 users 67%
Kangarooo
1
How can this be debugged?
– Adam Matan
Jan 27 '11 at 6:34
Reviewing cron's error log is the most common way. IIRC 'crontab -e' does a syntax parse after you've edited the file as well - but that might not be universal.
– pbr
Apr 8 '12 at 22:47
add a comment |
1
How can this be debugged?
– Adam Matan
Jan 27 '11 at 6:34
Reviewing cron's error log is the most common way. IIRC 'crontab -e' does a syntax parse after you've edited the file as well - but that might not be universal.
– pbr
Apr 8 '12 at 22:47
1
1
How can this be debugged?
– Adam Matan
Jan 27 '11 at 6:34
How can this be debugged?
– Adam Matan
Jan 27 '11 at 6:34
Reviewing cron's error log is the most common way. IIRC 'crontab -e' does a syntax parse after you've edited the file as well - but that might not be universal.
– pbr
Apr 8 '12 at 22:47
Reviewing cron's error log is the most common way. IIRC 'crontab -e' does a syntax parse after you've edited the file as well - but that might not be universal.
– pbr
Apr 8 '12 at 22:47
add a comment |
Cron daemon could be running, but not actually working. Try restarting cron:
sudo /etc/init.d/cron restart
3
I've NEVER seen this case in production. Doesn't mean it hasn't happened - just that I've not seen it in the 30 years I've been using UNIX and Linux. Cron is insanely robust.
– pbr
Apr 8 '12 at 22:42
1
I'm not sure but I think this did actually just happen to me. I triedpidof
cron and got nothing. Tried usingservice
utility and it said cron was already running. Just ran this command and ranpidof
again and I get a result.
– Colleen
Apr 6 '15 at 17:13
add a comment |
Cron daemon could be running, but not actually working. Try restarting cron:
sudo /etc/init.d/cron restart
3
I've NEVER seen this case in production. Doesn't mean it hasn't happened - just that I've not seen it in the 30 years I've been using UNIX and Linux. Cron is insanely robust.
– pbr
Apr 8 '12 at 22:42
1
I'm not sure but I think this did actually just happen to me. I triedpidof
cron and got nothing. Tried usingservice
utility and it said cron was already running. Just ran this command and ranpidof
again and I get a result.
– Colleen
Apr 6 '15 at 17:13
add a comment |
Cron daemon could be running, but not actually working. Try restarting cron:
sudo /etc/init.d/cron restart
Cron daemon could be running, but not actually working. Try restarting cron:
sudo /etc/init.d/cron restart
edited Nov 24 '11 at 23:20
community wiki
2 revs, 2 users 67%
Phil Dodd
3
I've NEVER seen this case in production. Doesn't mean it hasn't happened - just that I've not seen it in the 30 years I've been using UNIX and Linux. Cron is insanely robust.
– pbr
Apr 8 '12 at 22:42
1
I'm not sure but I think this did actually just happen to me. I triedpidof
cron and got nothing. Tried usingservice
utility and it said cron was already running. Just ran this command and ranpidof
again and I get a result.
– Colleen
Apr 6 '15 at 17:13
add a comment |
3
I've NEVER seen this case in production. Doesn't mean it hasn't happened - just that I've not seen it in the 30 years I've been using UNIX and Linux. Cron is insanely robust.
– pbr
Apr 8 '12 at 22:42
1
I'm not sure but I think this did actually just happen to me. I triedpidof
cron and got nothing. Tried usingservice
utility and it said cron was already running. Just ran this command and ranpidof
again and I get a result.
– Colleen
Apr 6 '15 at 17:13
3
3
I've NEVER seen this case in production. Doesn't mean it hasn't happened - just that I've not seen it in the 30 years I've been using UNIX and Linux. Cron is insanely robust.
– pbr
Apr 8 '12 at 22:42
I've NEVER seen this case in production. Doesn't mean it hasn't happened - just that I've not seen it in the 30 years I've been using UNIX and Linux. Cron is insanely robust.
– pbr
Apr 8 '12 at 22:42
1
1
I'm not sure but I think this did actually just happen to me. I tried
pidof
cron and got nothing. Tried using service
utility and it said cron was already running. Just ran this command and ran pidof
again and I get a result.– Colleen
Apr 6 '15 at 17:13
I'm not sure but I think this did actually just happen to me. I tried
pidof
cron and got nothing. Tried using service
utility and it said cron was already running. Just ran this command and ran pidof
again and I get a result.– Colleen
Apr 6 '15 at 17:13
add a comment |
Writing to cron via "crontab -e" with the username argument in a line. I've seen examples of users (or sysadmins) writing their shell scripts and not understanding why they don't automate. The "user" argument exists in /etc/crontab, but not the user-defined files. so, for example, your personal file would be something like:
# m h dom mon dow command
* * */2 * * /some/shell/script
whereas /etc/crontab would be:
# m h dom mon dow user command
* * */2 * * jdoe /some/shell/script
So, why would you do the latter? Well, depending on how you want to set your permissions, this can become very convoluted. I've written scripts to automate tasks for users who don't understand the intricacies, or don't want to bother with the drudgery. By setting permissions to --x------
, I can make the script executable without them being able to read (and perhaps accidentally change) it. However, I might want to run this command with several others from one file (thus making it easier to maintain) but make sure file output is assigned the right owner. Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute, plus the afore-mentioned issue with putting periods in /etc/crontab (which, funnily enough, causes no error when going through crontab -e
).
As an example, I've seen instances of sudo crontab -e
used to run a script with root permissions, with a corresponding chown username file_output
in the shell script. Sloppy, but it works. IMHO, The more graceful option is to put it in /etc/crontab
with username declared and proper permissions, so file_output
goes to the right place and owner.
"Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute....." I should clarify: /etc/crontab (by default) requires read AND execute permissions, whereas you COULD run "sudo crontab -e" to create a cronjob which overrides both the need for the "w" permission, and the problem with extensions like ".sh". I haven't had time to pull apart the cron code and check why this works, just a detail I've noticed.
– Mange
Jun 12 '12 at 19:54
add a comment |
Writing to cron via "crontab -e" with the username argument in a line. I've seen examples of users (or sysadmins) writing their shell scripts and not understanding why they don't automate. The "user" argument exists in /etc/crontab, but not the user-defined files. so, for example, your personal file would be something like:
# m h dom mon dow command
* * */2 * * /some/shell/script
whereas /etc/crontab would be:
# m h dom mon dow user command
* * */2 * * jdoe /some/shell/script
So, why would you do the latter? Well, depending on how you want to set your permissions, this can become very convoluted. I've written scripts to automate tasks for users who don't understand the intricacies, or don't want to bother with the drudgery. By setting permissions to --x------
, I can make the script executable without them being able to read (and perhaps accidentally change) it. However, I might want to run this command with several others from one file (thus making it easier to maintain) but make sure file output is assigned the right owner. Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute, plus the afore-mentioned issue with putting periods in /etc/crontab (which, funnily enough, causes no error when going through crontab -e
).
As an example, I've seen instances of sudo crontab -e
used to run a script with root permissions, with a corresponding chown username file_output
in the shell script. Sloppy, but it works. IMHO, The more graceful option is to put it in /etc/crontab
with username declared and proper permissions, so file_output
goes to the right place and owner.
"Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute....." I should clarify: /etc/crontab (by default) requires read AND execute permissions, whereas you COULD run "sudo crontab -e" to create a cronjob which overrides both the need for the "w" permission, and the problem with extensions like ".sh". I haven't had time to pull apart the cron code and check why this works, just a detail I've noticed.
– Mange
Jun 12 '12 at 19:54
add a comment |
Writing to cron via "crontab -e" with the username argument in a line. I've seen examples of users (or sysadmins) writing their shell scripts and not understanding why they don't automate. The "user" argument exists in /etc/crontab, but not the user-defined files. so, for example, your personal file would be something like:
# m h dom mon dow command
* * */2 * * /some/shell/script
whereas /etc/crontab would be:
# m h dom mon dow user command
* * */2 * * jdoe /some/shell/script
So, why would you do the latter? Well, depending on how you want to set your permissions, this can become very convoluted. I've written scripts to automate tasks for users who don't understand the intricacies, or don't want to bother with the drudgery. By setting permissions to --x------
, I can make the script executable without them being able to read (and perhaps accidentally change) it. However, I might want to run this command with several others from one file (thus making it easier to maintain) but make sure file output is assigned the right owner. Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute, plus the afore-mentioned issue with putting periods in /etc/crontab (which, funnily enough, causes no error when going through crontab -e
).
As an example, I've seen instances of sudo crontab -e
used to run a script with root permissions, with a corresponding chown username file_output
in the shell script. Sloppy, but it works. IMHO, The more graceful option is to put it in /etc/crontab
with username declared and proper permissions, so file_output
goes to the right place and owner.
Writing to cron via "crontab -e" with the username argument in a line. I've seen examples of users (or sysadmins) writing their shell scripts and not understanding why they don't automate. The "user" argument exists in /etc/crontab, but not the user-defined files. so, for example, your personal file would be something like:
# m h dom mon dow command
* * */2 * * /some/shell/script
whereas /etc/crontab would be:
# m h dom mon dow user command
* * */2 * * jdoe /some/shell/script
So, why would you do the latter? Well, depending on how you want to set your permissions, this can become very convoluted. I've written scripts to automate tasks for users who don't understand the intricacies, or don't want to bother with the drudgery. By setting permissions to --x------
, I can make the script executable without them being able to read (and perhaps accidentally change) it. However, I might want to run this command with several others from one file (thus making it easier to maintain) but make sure file output is assigned the right owner. Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute, plus the afore-mentioned issue with putting periods in /etc/crontab (which, funnily enough, causes no error when going through crontab -e
).
As an example, I've seen instances of sudo crontab -e
used to run a script with root permissions, with a corresponding chown username file_output
in the shell script. Sloppy, but it works. IMHO, The more graceful option is to put it in /etc/crontab
with username declared and proper permissions, so file_output
goes to the right place and owner.
edited Jun 12 '12 at 17:42
community wiki
3 revs, 2 users 77%
Mange
"Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute....." I should clarify: /etc/crontab (by default) requires read AND execute permissions, whereas you COULD run "sudo crontab -e" to create a cronjob which overrides both the need for the "w" permission, and the problem with extensions like ".sh". I haven't had time to pull apart the cron code and check why this works, just a detail I've noticed.
– Mange
Jun 12 '12 at 19:54
add a comment |
"Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute....." I should clarify: /etc/crontab (by default) requires read AND execute permissions, whereas you COULD run "sudo crontab -e" to create a cronjob which overrides both the need for the "w" permission, and the problem with extensions like ".sh". I haven't had time to pull apart the cron code and check why this works, just a detail I've noticed.
– Mange
Jun 12 '12 at 19:54
"Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute....." I should clarify: /etc/crontab (by default) requires read AND execute permissions, whereas you COULD run "sudo crontab -e" to create a cronjob which overrides both the need for the "w" permission, and the problem with extensions like ".sh". I haven't had time to pull apart the cron code and check why this works, just a detail I've noticed.
– Mange
Jun 12 '12 at 19:54
"Doing so (at least in Ubuntu 10.10) breaks on both the inability to read the file as well as execute....." I should clarify: /etc/crontab (by default) requires read AND execute permissions, whereas you COULD run "sudo crontab -e" to create a cronjob which overrides both the need for the "w" permission, and the problem with extensions like ".sh". I haven't had time to pull apart the cron code and check why this works, just a detail I've noticed.
– Mange
Jun 12 '12 at 19:54
add a comment |
Building off what Aaron Peart mentioned about verbose mode, sometimes scripts not in verbose mode will initialize but not finish if the default behavior of an included command is to output a line or more to the screen once the proc starts. For example, I wrote a backup script for our intranet which used curl, a utility that downloads or uploads files to remote servers, and is quite handy if you can only access said remote files through HTTP. Using 'curl http://something.com/somefile.xls' was causing a script I wrote to hang and never complete because it spits out a newline followed by a progress line. I had to use the silent flag (-s) to tell it not to output any information, and write in my own code to handle if the file failed to download.
1
For programs that don't have a silent mode, you can redirect their output to/dev/null
. For example:some-command > /dev/null
This will redirect only standard output, and not error output (which is usually what you want, since you want to be informed of errors). To redirect error output too, usesome-command &> /dev/null
.
– Eliah Kagan
Jun 12 '12 at 20:22
Yeah, that was my first thought when writing the afore-mentioneed script. I forget why I didn't use that, possibly some non-standard behavior that circumvented said solution. I know that verbose/interactive mode is the default on some commands (I'm looking at YOU, scp!), which means you need to hadle said output for smooth operation of shell scripts.
– Mange
Jun 13 '12 at 12:09
add a comment |
Building off what Aaron Peart mentioned about verbose mode, sometimes scripts not in verbose mode will initialize but not finish if the default behavior of an included command is to output a line or more to the screen once the proc starts. For example, I wrote a backup script for our intranet which used curl, a utility that downloads or uploads files to remote servers, and is quite handy if you can only access said remote files through HTTP. Using 'curl http://something.com/somefile.xls' was causing a script I wrote to hang and never complete because it spits out a newline followed by a progress line. I had to use the silent flag (-s) to tell it not to output any information, and write in my own code to handle if the file failed to download.
1
For programs that don't have a silent mode, you can redirect their output to/dev/null
. For example:some-command > /dev/null
This will redirect only standard output, and not error output (which is usually what you want, since you want to be informed of errors). To redirect error output too, usesome-command &> /dev/null
.
– Eliah Kagan
Jun 12 '12 at 20:22
Yeah, that was my first thought when writing the afore-mentioneed script. I forget why I didn't use that, possibly some non-standard behavior that circumvented said solution. I know that verbose/interactive mode is the default on some commands (I'm looking at YOU, scp!), which means you need to hadle said output for smooth operation of shell scripts.
– Mange
Jun 13 '12 at 12:09
add a comment |
Building off what Aaron Peart mentioned about verbose mode, sometimes scripts not in verbose mode will initialize but not finish if the default behavior of an included command is to output a line or more to the screen once the proc starts. For example, I wrote a backup script for our intranet which used curl, a utility that downloads or uploads files to remote servers, and is quite handy if you can only access said remote files through HTTP. Using 'curl http://something.com/somefile.xls' was causing a script I wrote to hang and never complete because it spits out a newline followed by a progress line. I had to use the silent flag (-s) to tell it not to output any information, and write in my own code to handle if the file failed to download.
Building off what Aaron Peart mentioned about verbose mode, sometimes scripts not in verbose mode will initialize but not finish if the default behavior of an included command is to output a line or more to the screen once the proc starts. For example, I wrote a backup script for our intranet which used curl, a utility that downloads or uploads files to remote servers, and is quite handy if you can only access said remote files through HTTP. Using 'curl http://something.com/somefile.xls' was causing a script I wrote to hang and never complete because it spits out a newline followed by a progress line. I had to use the silent flag (-s) to tell it not to output any information, and write in my own code to handle if the file failed to download.
answered Jun 12 '12 at 20:06
community wiki
Mange
1
For programs that don't have a silent mode, you can redirect their output to/dev/null
. For example:some-command > /dev/null
This will redirect only standard output, and not error output (which is usually what you want, since you want to be informed of errors). To redirect error output too, usesome-command &> /dev/null
.
– Eliah Kagan
Jun 12 '12 at 20:22
Yeah, that was my first thought when writing the afore-mentioneed script. I forget why I didn't use that, possibly some non-standard behavior that circumvented said solution. I know that verbose/interactive mode is the default on some commands (I'm looking at YOU, scp!), which means you need to hadle said output for smooth operation of shell scripts.
– Mange
Jun 13 '12 at 12:09
add a comment |
1
For programs that don't have a silent mode, you can redirect their output to/dev/null
. For example:some-command > /dev/null
This will redirect only standard output, and not error output (which is usually what you want, since you want to be informed of errors). To redirect error output too, usesome-command &> /dev/null
.
– Eliah Kagan
Jun 12 '12 at 20:22
Yeah, that was my first thought when writing the afore-mentioneed script. I forget why I didn't use that, possibly some non-standard behavior that circumvented said solution. I know that verbose/interactive mode is the default on some commands (I'm looking at YOU, scp!), which means you need to hadle said output for smooth operation of shell scripts.
– Mange
Jun 13 '12 at 12:09
1
1
For programs that don't have a silent mode, you can redirect their output to
/dev/null
. For example: some-command > /dev/null
This will redirect only standard output, and not error output (which is usually what you want, since you want to be informed of errors). To redirect error output too, use some-command &> /dev/null
.– Eliah Kagan
Jun 12 '12 at 20:22
For programs that don't have a silent mode, you can redirect their output to
/dev/null
. For example: some-command > /dev/null
This will redirect only standard output, and not error output (which is usually what you want, since you want to be informed of errors). To redirect error output too, use some-command &> /dev/null
.– Eliah Kagan
Jun 12 '12 at 20:22
Yeah, that was my first thought when writing the afore-mentioneed script. I forget why I didn't use that, possibly some non-standard behavior that circumvented said solution. I know that verbose/interactive mode is the default on some commands (I'm looking at YOU, scp!), which means you need to hadle said output for smooth operation of shell scripts.
– Mange
Jun 13 '12 at 12:09
Yeah, that was my first thought when writing the afore-mentioneed script. I forget why I didn't use that, possibly some non-standard behavior that circumvented said solution. I know that verbose/interactive mode is the default on some commands (I'm looking at YOU, scp!), which means you need to hadle said output for smooth operation of shell scripts.
– Mange
Jun 13 '12 at 12:09
add a comment |
Although you can define environment variables in your crontable, you're not in a shell script. So constructions like the following won't work:
SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log
BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file
0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
This is because variables are not interpreted in the crontable: all values are taken litterally. And this is the same if you omit the brackets.
So your commands won't run, and your log files won't be written...
Instead you must define all your environment variables straight:
SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log
BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file
0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
add a comment |
Although you can define environment variables in your crontable, you're not in a shell script. So constructions like the following won't work:
SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log
BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file
0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
This is because variables are not interpreted in the crontable: all values are taken litterally. And this is the same if you omit the brackets.
So your commands won't run, and your log files won't be written...
Instead you must define all your environment variables straight:
SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log
BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file
0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
add a comment |
Although you can define environment variables in your crontable, you're not in a shell script. So constructions like the following won't work:
SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log
BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file
0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
This is because variables are not interpreted in the crontable: all values are taken litterally. And this is the same if you omit the brackets.
So your commands won't run, and your log files won't be written...
Instead you must define all your environment variables straight:
SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log
BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file
0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
Although you can define environment variables in your crontable, you're not in a shell script. So constructions like the following won't work:
SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log
BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file
0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
This is because variables are not interpreted in the crontable: all values are taken litterally. And this is the same if you omit the brackets.
So your commands won't run, and your log files won't be written...
Instead you must define all your environment variables straight:
SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log
BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file
0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
edited Jun 7 '13 at 9:13
community wiki
2 revs
Alexandre
add a comment |
add a comment |
When a task is run within cron, stdin is closed. Programs that act differently based on whether stdin is available or not will behave differently between the shell session and in cron.
An example is the program goaccess
for analysing web server log files. This does NOT work in cron:
goaccess -a -f /var/log/nginx/access.log > output.html
and goaccess
shows the help page instead of creating the report. In the shell this can be reproduced with
goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null
The fix for goaccess
is to make it read the log from stdin instead of reading from the file, so the solution is to change the crontab entry to
cat /var/log/nginx/access.log | goaccess -a > output.html
add a comment |
When a task is run within cron, stdin is closed. Programs that act differently based on whether stdin is available or not will behave differently between the shell session and in cron.
An example is the program goaccess
for analysing web server log files. This does NOT work in cron:
goaccess -a -f /var/log/nginx/access.log > output.html
and goaccess
shows the help page instead of creating the report. In the shell this can be reproduced with
goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null
The fix for goaccess
is to make it read the log from stdin instead of reading from the file, so the solution is to change the crontab entry to
cat /var/log/nginx/access.log | goaccess -a > output.html
add a comment |
When a task is run within cron, stdin is closed. Programs that act differently based on whether stdin is available or not will behave differently between the shell session and in cron.
An example is the program goaccess
for analysing web server log files. This does NOT work in cron:
goaccess -a -f /var/log/nginx/access.log > output.html
and goaccess
shows the help page instead of creating the report. In the shell this can be reproduced with
goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null
The fix for goaccess
is to make it read the log from stdin instead of reading from the file, so the solution is to change the crontab entry to
cat /var/log/nginx/access.log | goaccess -a > output.html
When a task is run within cron, stdin is closed. Programs that act differently based on whether stdin is available or not will behave differently between the shell session and in cron.
An example is the program goaccess
for analysing web server log files. This does NOT work in cron:
goaccess -a -f /var/log/nginx/access.log > output.html
and goaccess
shows the help page instead of creating the report. In the shell this can be reproduced with
goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null
The fix for goaccess
is to make it read the log from stdin instead of reading from the file, so the solution is to change the crontab entry to
cat /var/log/nginx/access.log | goaccess -a > output.html
answered Aug 9 '13 at 20:27
community wiki
Martijn de Milliano
add a comment |
add a comment |
On my RHEL7 servers, root cron jobs would run, but user jobs would not. I found that without a home directory, the jobs won't run (but you will see good errors in /var/log/cron). When I created the home directory, the problem was solved.
add a comment |
On my RHEL7 servers, root cron jobs would run, but user jobs would not. I found that without a home directory, the jobs won't run (but you will see good errors in /var/log/cron). When I created the home directory, the problem was solved.
add a comment |
On my RHEL7 servers, root cron jobs would run, but user jobs would not. I found that without a home directory, the jobs won't run (but you will see good errors in /var/log/cron). When I created the home directory, the problem was solved.
On my RHEL7 servers, root cron jobs would run, but user jobs would not. I found that without a home directory, the jobs won't run (but you will see good errors in /var/log/cron). When I created the home directory, the problem was solved.
answered Feb 2 '17 at 21:29
community wiki
Dennis Parslow
add a comment |
add a comment |
If you edited your crontab file using a windows editor (via samba or something) and it's replaced the newlines with nr or just r, cron won't run.
Also, if you're using /etc/cron.d/* and one of those files has a r in it, cron will move through the files and stop when it hits a bad file. Not sure if that's the problem?
Use:
od -c /etc/cron.d/* | grep r
add a comment |
If you edited your crontab file using a windows editor (via samba or something) and it's replaced the newlines with nr or just r, cron won't run.
Also, if you're using /etc/cron.d/* and one of those files has a r in it, cron will move through the files and stop when it hits a bad file. Not sure if that's the problem?
Use:
od -c /etc/cron.d/* | grep r
add a comment |
If you edited your crontab file using a windows editor (via samba or something) and it's replaced the newlines with nr or just r, cron won't run.
Also, if you're using /etc/cron.d/* and one of those files has a r in it, cron will move through the files and stop when it hits a bad file. Not sure if that's the problem?
Use:
od -c /etc/cron.d/* | grep r
If you edited your crontab file using a windows editor (via samba or something) and it's replaced the newlines with nr or just r, cron won't run.
Also, if you're using /etc/cron.d/* and one of those files has a r in it, cron will move through the files and stop when it hits a bad file. Not sure if that's the problem?
Use:
od -c /etc/cron.d/* | grep r
edited Apr 20 '17 at 1:38
community wiki
4 revs, 2 users 91%
Doug
add a comment |
add a comment |
1 2
next
protected by heemayl May 9 '17 at 3:07
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
10
You must close
crontab -e
for the cron to take affect. For instance using vim I edit the file and use:w
to write it but the job is not added to cron until I quit also. So I will not see the job until after I:q
also.– DutGRIFF
Jun 24 '14 at 14:58
I think best way to debug cron is to check syslog and find the problems.
– Suneel Kumar
Jun 23 '16 at 7:49
In my case - the email was going to my SPAM folder, so..... check that before you spend hours on debugging :D
– almaruf
Nov 6 '17 at 14:54
Electricity outages
– Josef Klimuk
Mar 21 '18 at 7:38