Crontab tasks aren't running
up vote
0
down vote
favorite
I tried created a very simple cron task that echo's "Hello World" into a file named /tmp/example.txt
.
You can see from the screenshot, I tried:
28 23 * * * echo "Hello World" >> /tmp/example.txt
28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt
Also in the screenshot, you can see the date. I have also tried getting the exact date in the cron task (e.g.: 28 23 29 11 4), but that didn't work either.
I also tried using an actual file
28 23 * * * ./pingstuff
The pingstuff file just pings Google. I can run this file and it executes properly. But, when I try using it in the crontab -e, nothing happens at the scheduled time. (Times have been changed accordingly after each attempt.)
I am logged in as a super user. I have permissions to read/write/execute all of these files. I'm not really sure what I'm doing wrong.
linux bash cron
New contributor
add a comment |
up vote
0
down vote
favorite
I tried created a very simple cron task that echo's "Hello World" into a file named /tmp/example.txt
.
You can see from the screenshot, I tried:
28 23 * * * echo "Hello World" >> /tmp/example.txt
28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt
Also in the screenshot, you can see the date. I have also tried getting the exact date in the cron task (e.g.: 28 23 29 11 4), but that didn't work either.
I also tried using an actual file
28 23 * * * ./pingstuff
The pingstuff file just pings Google. I can run this file and it executes properly. But, when I try using it in the crontab -e, nothing happens at the scheduled time. (Times have been changed accordingly after each attempt.)
I am logged in as a super user. I have permissions to read/write/execute all of these files. I'm not really sure what I'm doing wrong.
linux bash cron
New contributor
2
What Linux distribution are you using? Is your cron daemon enabled and started?
– n.st
Nov 30 at 4:41
1
Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a34 12 …
cronjob at 12:33:30.
– n.st
Nov 30 at 4:47
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I tried created a very simple cron task that echo's "Hello World" into a file named /tmp/example.txt
.
You can see from the screenshot, I tried:
28 23 * * * echo "Hello World" >> /tmp/example.txt
28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt
Also in the screenshot, you can see the date. I have also tried getting the exact date in the cron task (e.g.: 28 23 29 11 4), but that didn't work either.
I also tried using an actual file
28 23 * * * ./pingstuff
The pingstuff file just pings Google. I can run this file and it executes properly. But, when I try using it in the crontab -e, nothing happens at the scheduled time. (Times have been changed accordingly after each attempt.)
I am logged in as a super user. I have permissions to read/write/execute all of these files. I'm not really sure what I'm doing wrong.
linux bash cron
New contributor
I tried created a very simple cron task that echo's "Hello World" into a file named /tmp/example.txt
.
You can see from the screenshot, I tried:
28 23 * * * echo "Hello World" >> /tmp/example.txt
28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt
Also in the screenshot, you can see the date. I have also tried getting the exact date in the cron task (e.g.: 28 23 29 11 4), but that didn't work either.
I also tried using an actual file
28 23 * * * ./pingstuff
The pingstuff file just pings Google. I can run this file and it executes properly. But, when I try using it in the crontab -e, nothing happens at the scheduled time. (Times have been changed accordingly after each attempt.)
I am logged in as a super user. I have permissions to read/write/execute all of these files. I'm not really sure what I'm doing wrong.
linux bash cron
linux bash cron
New contributor
New contributor
edited Nov 30 at 5:21
Rui F Ribeiro
38.3k1477127
38.3k1477127
New contributor
asked Nov 30 at 4:36
Pixii Bomb
71
71
New contributor
New contributor
2
What Linux distribution are you using? Is your cron daemon enabled and started?
– n.st
Nov 30 at 4:41
1
Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a34 12 …
cronjob at 12:33:30.
– n.st
Nov 30 at 4:47
add a comment |
2
What Linux distribution are you using? Is your cron daemon enabled and started?
– n.st
Nov 30 at 4:41
1
Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a34 12 …
cronjob at 12:33:30.
– n.st
Nov 30 at 4:47
2
2
What Linux distribution are you using? Is your cron daemon enabled and started?
– n.st
Nov 30 at 4:41
What Linux distribution are you using? Is your cron daemon enabled and started?
– n.st
Nov 30 at 4:41
1
1
Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a
34 12 …
cronjob at 12:33:30.– n.st
Nov 30 at 4:47
Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a
34 12 …
cronjob at 12:33:30.– n.st
Nov 30 at 4:47
add a comment |
3 Answers
3
active
oldest
votes
up vote
12
down vote
A cronjob may fail to execute because
- the cron daemon is not running
- there's a syntax error in the crontab
- there's a syntax error in the command
- or there's a permission problem (e.g. execute bit not set)
To check if the daemon is running, try service cron status
or systemctl status cron
(the service manager depends on your distribution). The daemon may also be called something slightly different, like crond
or cronie
.
If it's not running, start it (replace status
with start
).
If it's running, proceed to check the relevant log files to see whether the job was actually run. Depending on your distribution, this might be logged to /var/log/syslog
, /var/log/messages
, a daemon-specific file like /var/log/cron
, or a systemd binary log file (journalctl -u cron
to view). You should see a line for each execution of the job.
When testing crontabs, set an execution time that's more than one minute in the future. Some cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 …
cronjob at 12:33:30.
If the job runs but doesn't produce the expected result, try running the command from the crontab manually, as the same user, with the same shell (usually the minimalistic /bin/sh
).
One common pitfall (though not the case here) are %
characters in the command: they are treated specially by cron and need to be escaped (%
) to be seen by the actual command invocation.
Most cron implementations also send the output (if any) of each cronjob as an email. If you haven't set up mail delivery over the internet, those mails should be stored locally and be readable using the mail
command.
Several good points.
– G-Man
Nov 30 at 5:03
add a comment |
up vote
5
down vote
Your biggest problem is that /bin/bash echo "Hello World"
is not a valid command.
It looks for a script called echo
.
Try /bin/bash -c 'echo "Hello World"'
instead.
The second problem is that you should specify an absolute pathname
for pingstuff
.
A third issue that caught my eye is that /tmp/example.txt
already exists (the cat
command didn't get an error message).
Are you sure that you have write permission to it?
(Of course, that shouldn't be an issue if you're running as root.)
See also Ubuntu 14.04, 16.04, 18.04 Cron job doesn't execute,
although it probably isn't related.
add a comment |
up vote
3
down vote
There are two crontab syntaxes that apply to different crontab files.
The first form:
28 23 * * * echo "Hello World" >> /tmp/example.txt
applies to user crontabs. These are edited with crontab -e
.
The second form:
28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt
which has the additional user column, applies to the system-wide crontab file /etc/crontab
.
So, since you're editing the crontab file with crontab -e
,
you shouldn't specify a username as the sixth field.
cron
will know to run the command as root
because you were root when you ran crontab -e
,
and, if you enter "root" as the sixth field,
cron
will try to execute a program called root
.
Note, however, that cron runs the commands in a shell. Also, in the second example, you are starting the shell explicitly. Have you tried that command on your interactive shell?
$ /bin/bash echo hello
/usr/bin/echo: /usr/bin/echo: cannot execute binary file
In order to test that correctly, you may want to use a Hello World Shell script:
#!/bin/bash
echo 'Hello, world!'
Note that the redirection should be done in the crontab, not within the script (just a style-guide).
Save that as helloworld.sh
in any directory, make it executable (chmod +x helloworld.sh
) and call this script in your crontab. Take care if you use the user crontab or the system-wide crontab.
So, the entry in the user crontab (crontab -e
) should look like this:
28 23 * * * /path/to/helloworld.sh >> /tmp/example.txt
Usercrontab
files (including root's) don't have the extra user field. That is reserved for the systemcrontab
files found under/etc
.
– roaima
Nov 30 at 8:51
I haven't downvoted. Your alternate syntax is completely irrelevant, and quite possibly adding confusion for the OP, who is already using valid syntax for the scenario they are demonstrating.
– roaima
Nov 30 at 8:54
@roaima Ah, now I got it. The entry sentences did not make it clear in the first place. Also, the OP used both syntaxes in the user crontab file and none of these worked because of another mistake, so he may not have been able to track it down.
– rexkogitans
Nov 30 at 9:08
Good point about the different crontab syntaxes. I knew that, but it slipped my mind. However, I believe that the rest of your answer was already covered by my answer (aside from verifying that scripts are executable, which seems irrelevant, inasmuch as the OP has successfully run her script from an interactive shell).
– G-Man
Nov 30 at 13:40
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
12
down vote
A cronjob may fail to execute because
- the cron daemon is not running
- there's a syntax error in the crontab
- there's a syntax error in the command
- or there's a permission problem (e.g. execute bit not set)
To check if the daemon is running, try service cron status
or systemctl status cron
(the service manager depends on your distribution). The daemon may also be called something slightly different, like crond
or cronie
.
If it's not running, start it (replace status
with start
).
If it's running, proceed to check the relevant log files to see whether the job was actually run. Depending on your distribution, this might be logged to /var/log/syslog
, /var/log/messages
, a daemon-specific file like /var/log/cron
, or a systemd binary log file (journalctl -u cron
to view). You should see a line for each execution of the job.
When testing crontabs, set an execution time that's more than one minute in the future. Some cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 …
cronjob at 12:33:30.
If the job runs but doesn't produce the expected result, try running the command from the crontab manually, as the same user, with the same shell (usually the minimalistic /bin/sh
).
One common pitfall (though not the case here) are %
characters in the command: they are treated specially by cron and need to be escaped (%
) to be seen by the actual command invocation.
Most cron implementations also send the output (if any) of each cronjob as an email. If you haven't set up mail delivery over the internet, those mails should be stored locally and be readable using the mail
command.
Several good points.
– G-Man
Nov 30 at 5:03
add a comment |
up vote
12
down vote
A cronjob may fail to execute because
- the cron daemon is not running
- there's a syntax error in the crontab
- there's a syntax error in the command
- or there's a permission problem (e.g. execute bit not set)
To check if the daemon is running, try service cron status
or systemctl status cron
(the service manager depends on your distribution). The daemon may also be called something slightly different, like crond
or cronie
.
If it's not running, start it (replace status
with start
).
If it's running, proceed to check the relevant log files to see whether the job was actually run. Depending on your distribution, this might be logged to /var/log/syslog
, /var/log/messages
, a daemon-specific file like /var/log/cron
, or a systemd binary log file (journalctl -u cron
to view). You should see a line for each execution of the job.
When testing crontabs, set an execution time that's more than one minute in the future. Some cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 …
cronjob at 12:33:30.
If the job runs but doesn't produce the expected result, try running the command from the crontab manually, as the same user, with the same shell (usually the minimalistic /bin/sh
).
One common pitfall (though not the case here) are %
characters in the command: they are treated specially by cron and need to be escaped (%
) to be seen by the actual command invocation.
Most cron implementations also send the output (if any) of each cronjob as an email. If you haven't set up mail delivery over the internet, those mails should be stored locally and be readable using the mail
command.
Several good points.
– G-Man
Nov 30 at 5:03
add a comment |
up vote
12
down vote
up vote
12
down vote
A cronjob may fail to execute because
- the cron daemon is not running
- there's a syntax error in the crontab
- there's a syntax error in the command
- or there's a permission problem (e.g. execute bit not set)
To check if the daemon is running, try service cron status
or systemctl status cron
(the service manager depends on your distribution). The daemon may also be called something slightly different, like crond
or cronie
.
If it's not running, start it (replace status
with start
).
If it's running, proceed to check the relevant log files to see whether the job was actually run. Depending on your distribution, this might be logged to /var/log/syslog
, /var/log/messages
, a daemon-specific file like /var/log/cron
, or a systemd binary log file (journalctl -u cron
to view). You should see a line for each execution of the job.
When testing crontabs, set an execution time that's more than one minute in the future. Some cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 …
cronjob at 12:33:30.
If the job runs but doesn't produce the expected result, try running the command from the crontab manually, as the same user, with the same shell (usually the minimalistic /bin/sh
).
One common pitfall (though not the case here) are %
characters in the command: they are treated specially by cron and need to be escaped (%
) to be seen by the actual command invocation.
Most cron implementations also send the output (if any) of each cronjob as an email. If you haven't set up mail delivery over the internet, those mails should be stored locally and be readable using the mail
command.
A cronjob may fail to execute because
- the cron daemon is not running
- there's a syntax error in the crontab
- there's a syntax error in the command
- or there's a permission problem (e.g. execute bit not set)
To check if the daemon is running, try service cron status
or systemctl status cron
(the service manager depends on your distribution). The daemon may also be called something slightly different, like crond
or cronie
.
If it's not running, start it (replace status
with start
).
If it's running, proceed to check the relevant log files to see whether the job was actually run. Depending on your distribution, this might be logged to /var/log/syslog
, /var/log/messages
, a daemon-specific file like /var/log/cron
, or a systemd binary log file (journalctl -u cron
to view). You should see a line for each execution of the job.
When testing crontabs, set an execution time that's more than one minute in the future. Some cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 …
cronjob at 12:33:30.
If the job runs but doesn't produce the expected result, try running the command from the crontab manually, as the same user, with the same shell (usually the minimalistic /bin/sh
).
One common pitfall (though not the case here) are %
characters in the command: they are treated specially by cron and need to be escaped (%
) to be seen by the actual command invocation.
Most cron implementations also send the output (if any) of each cronjob as an email. If you haven't set up mail delivery over the internet, those mails should be stored locally and be readable using the mail
command.
edited Nov 30 at 5:05
answered Nov 30 at 5:01
n.st
5,14311842
5,14311842
Several good points.
– G-Man
Nov 30 at 5:03
add a comment |
Several good points.
– G-Man
Nov 30 at 5:03
Several good points.
– G-Man
Nov 30 at 5:03
Several good points.
– G-Man
Nov 30 at 5:03
add a comment |
up vote
5
down vote
Your biggest problem is that /bin/bash echo "Hello World"
is not a valid command.
It looks for a script called echo
.
Try /bin/bash -c 'echo "Hello World"'
instead.
The second problem is that you should specify an absolute pathname
for pingstuff
.
A third issue that caught my eye is that /tmp/example.txt
already exists (the cat
command didn't get an error message).
Are you sure that you have write permission to it?
(Of course, that shouldn't be an issue if you're running as root.)
See also Ubuntu 14.04, 16.04, 18.04 Cron job doesn't execute,
although it probably isn't related.
add a comment |
up vote
5
down vote
Your biggest problem is that /bin/bash echo "Hello World"
is not a valid command.
It looks for a script called echo
.
Try /bin/bash -c 'echo "Hello World"'
instead.
The second problem is that you should specify an absolute pathname
for pingstuff
.
A third issue that caught my eye is that /tmp/example.txt
already exists (the cat
command didn't get an error message).
Are you sure that you have write permission to it?
(Of course, that shouldn't be an issue if you're running as root.)
See also Ubuntu 14.04, 16.04, 18.04 Cron job doesn't execute,
although it probably isn't related.
add a comment |
up vote
5
down vote
up vote
5
down vote
Your biggest problem is that /bin/bash echo "Hello World"
is not a valid command.
It looks for a script called echo
.
Try /bin/bash -c 'echo "Hello World"'
instead.
The second problem is that you should specify an absolute pathname
for pingstuff
.
A third issue that caught my eye is that /tmp/example.txt
already exists (the cat
command didn't get an error message).
Are you sure that you have write permission to it?
(Of course, that shouldn't be an issue if you're running as root.)
See also Ubuntu 14.04, 16.04, 18.04 Cron job doesn't execute,
although it probably isn't related.
Your biggest problem is that /bin/bash echo "Hello World"
is not a valid command.
It looks for a script called echo
.
Try /bin/bash -c 'echo "Hello World"'
instead.
The second problem is that you should specify an absolute pathname
for pingstuff
.
A third issue that caught my eye is that /tmp/example.txt
already exists (the cat
command didn't get an error message).
Are you sure that you have write permission to it?
(Of course, that shouldn't be an issue if you're running as root.)
See also Ubuntu 14.04, 16.04, 18.04 Cron job doesn't execute,
although it probably isn't related.
edited Nov 30 at 4:57
answered Nov 30 at 4:51
G-Man
12.3k92961
12.3k92961
add a comment |
add a comment |
up vote
3
down vote
There are two crontab syntaxes that apply to different crontab files.
The first form:
28 23 * * * echo "Hello World" >> /tmp/example.txt
applies to user crontabs. These are edited with crontab -e
.
The second form:
28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt
which has the additional user column, applies to the system-wide crontab file /etc/crontab
.
So, since you're editing the crontab file with crontab -e
,
you shouldn't specify a username as the sixth field.
cron
will know to run the command as root
because you were root when you ran crontab -e
,
and, if you enter "root" as the sixth field,
cron
will try to execute a program called root
.
Note, however, that cron runs the commands in a shell. Also, in the second example, you are starting the shell explicitly. Have you tried that command on your interactive shell?
$ /bin/bash echo hello
/usr/bin/echo: /usr/bin/echo: cannot execute binary file
In order to test that correctly, you may want to use a Hello World Shell script:
#!/bin/bash
echo 'Hello, world!'
Note that the redirection should be done in the crontab, not within the script (just a style-guide).
Save that as helloworld.sh
in any directory, make it executable (chmod +x helloworld.sh
) and call this script in your crontab. Take care if you use the user crontab or the system-wide crontab.
So, the entry in the user crontab (crontab -e
) should look like this:
28 23 * * * /path/to/helloworld.sh >> /tmp/example.txt
Usercrontab
files (including root's) don't have the extra user field. That is reserved for the systemcrontab
files found under/etc
.
– roaima
Nov 30 at 8:51
I haven't downvoted. Your alternate syntax is completely irrelevant, and quite possibly adding confusion for the OP, who is already using valid syntax for the scenario they are demonstrating.
– roaima
Nov 30 at 8:54
@roaima Ah, now I got it. The entry sentences did not make it clear in the first place. Also, the OP used both syntaxes in the user crontab file and none of these worked because of another mistake, so he may not have been able to track it down.
– rexkogitans
Nov 30 at 9:08
Good point about the different crontab syntaxes. I knew that, but it slipped my mind. However, I believe that the rest of your answer was already covered by my answer (aside from verifying that scripts are executable, which seems irrelevant, inasmuch as the OP has successfully run her script from an interactive shell).
– G-Man
Nov 30 at 13:40
add a comment |
up vote
3
down vote
There are two crontab syntaxes that apply to different crontab files.
The first form:
28 23 * * * echo "Hello World" >> /tmp/example.txt
applies to user crontabs. These are edited with crontab -e
.
The second form:
28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt
which has the additional user column, applies to the system-wide crontab file /etc/crontab
.
So, since you're editing the crontab file with crontab -e
,
you shouldn't specify a username as the sixth field.
cron
will know to run the command as root
because you were root when you ran crontab -e
,
and, if you enter "root" as the sixth field,
cron
will try to execute a program called root
.
Note, however, that cron runs the commands in a shell. Also, in the second example, you are starting the shell explicitly. Have you tried that command on your interactive shell?
$ /bin/bash echo hello
/usr/bin/echo: /usr/bin/echo: cannot execute binary file
In order to test that correctly, you may want to use a Hello World Shell script:
#!/bin/bash
echo 'Hello, world!'
Note that the redirection should be done in the crontab, not within the script (just a style-guide).
Save that as helloworld.sh
in any directory, make it executable (chmod +x helloworld.sh
) and call this script in your crontab. Take care if you use the user crontab or the system-wide crontab.
So, the entry in the user crontab (crontab -e
) should look like this:
28 23 * * * /path/to/helloworld.sh >> /tmp/example.txt
Usercrontab
files (including root's) don't have the extra user field. That is reserved for the systemcrontab
files found under/etc
.
– roaima
Nov 30 at 8:51
I haven't downvoted. Your alternate syntax is completely irrelevant, and quite possibly adding confusion for the OP, who is already using valid syntax for the scenario they are demonstrating.
– roaima
Nov 30 at 8:54
@roaima Ah, now I got it. The entry sentences did not make it clear in the first place. Also, the OP used both syntaxes in the user crontab file and none of these worked because of another mistake, so he may not have been able to track it down.
– rexkogitans
Nov 30 at 9:08
Good point about the different crontab syntaxes. I knew that, but it slipped my mind. However, I believe that the rest of your answer was already covered by my answer (aside from verifying that scripts are executable, which seems irrelevant, inasmuch as the OP has successfully run her script from an interactive shell).
– G-Man
Nov 30 at 13:40
add a comment |
up vote
3
down vote
up vote
3
down vote
There are two crontab syntaxes that apply to different crontab files.
The first form:
28 23 * * * echo "Hello World" >> /tmp/example.txt
applies to user crontabs. These are edited with crontab -e
.
The second form:
28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt
which has the additional user column, applies to the system-wide crontab file /etc/crontab
.
So, since you're editing the crontab file with crontab -e
,
you shouldn't specify a username as the sixth field.
cron
will know to run the command as root
because you were root when you ran crontab -e
,
and, if you enter "root" as the sixth field,
cron
will try to execute a program called root
.
Note, however, that cron runs the commands in a shell. Also, in the second example, you are starting the shell explicitly. Have you tried that command on your interactive shell?
$ /bin/bash echo hello
/usr/bin/echo: /usr/bin/echo: cannot execute binary file
In order to test that correctly, you may want to use a Hello World Shell script:
#!/bin/bash
echo 'Hello, world!'
Note that the redirection should be done in the crontab, not within the script (just a style-guide).
Save that as helloworld.sh
in any directory, make it executable (chmod +x helloworld.sh
) and call this script in your crontab. Take care if you use the user crontab or the system-wide crontab.
So, the entry in the user crontab (crontab -e
) should look like this:
28 23 * * * /path/to/helloworld.sh >> /tmp/example.txt
There are two crontab syntaxes that apply to different crontab files.
The first form:
28 23 * * * echo "Hello World" >> /tmp/example.txt
applies to user crontabs. These are edited with crontab -e
.
The second form:
28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt
which has the additional user column, applies to the system-wide crontab file /etc/crontab
.
So, since you're editing the crontab file with crontab -e
,
you shouldn't specify a username as the sixth field.
cron
will know to run the command as root
because you were root when you ran crontab -e
,
and, if you enter "root" as the sixth field,
cron
will try to execute a program called root
.
Note, however, that cron runs the commands in a shell. Also, in the second example, you are starting the shell explicitly. Have you tried that command on your interactive shell?
$ /bin/bash echo hello
/usr/bin/echo: /usr/bin/echo: cannot execute binary file
In order to test that correctly, you may want to use a Hello World Shell script:
#!/bin/bash
echo 'Hello, world!'
Note that the redirection should be done in the crontab, not within the script (just a style-guide).
Save that as helloworld.sh
in any directory, make it executable (chmod +x helloworld.sh
) and call this script in your crontab. Take care if you use the user crontab or the system-wide crontab.
So, the entry in the user crontab (crontab -e
) should look like this:
28 23 * * * /path/to/helloworld.sh >> /tmp/example.txt
edited Nov 30 at 13:39
G-Man
12.3k92961
12.3k92961
answered Nov 30 at 8:47
rexkogitans
383112
383112
Usercrontab
files (including root's) don't have the extra user field. That is reserved for the systemcrontab
files found under/etc
.
– roaima
Nov 30 at 8:51
I haven't downvoted. Your alternate syntax is completely irrelevant, and quite possibly adding confusion for the OP, who is already using valid syntax for the scenario they are demonstrating.
– roaima
Nov 30 at 8:54
@roaima Ah, now I got it. The entry sentences did not make it clear in the first place. Also, the OP used both syntaxes in the user crontab file and none of these worked because of another mistake, so he may not have been able to track it down.
– rexkogitans
Nov 30 at 9:08
Good point about the different crontab syntaxes. I knew that, but it slipped my mind. However, I believe that the rest of your answer was already covered by my answer (aside from verifying that scripts are executable, which seems irrelevant, inasmuch as the OP has successfully run her script from an interactive shell).
– G-Man
Nov 30 at 13:40
add a comment |
Usercrontab
files (including root's) don't have the extra user field. That is reserved for the systemcrontab
files found under/etc
.
– roaima
Nov 30 at 8:51
I haven't downvoted. Your alternate syntax is completely irrelevant, and quite possibly adding confusion for the OP, who is already using valid syntax for the scenario they are demonstrating.
– roaima
Nov 30 at 8:54
@roaima Ah, now I got it. The entry sentences did not make it clear in the first place. Also, the OP used both syntaxes in the user crontab file and none of these worked because of another mistake, so he may not have been able to track it down.
– rexkogitans
Nov 30 at 9:08
Good point about the different crontab syntaxes. I knew that, but it slipped my mind. However, I believe that the rest of your answer was already covered by my answer (aside from verifying that scripts are executable, which seems irrelevant, inasmuch as the OP has successfully run her script from an interactive shell).
– G-Man
Nov 30 at 13:40
User
crontab
files (including root's) don't have the extra user field. That is reserved for the system crontab
files found under /etc
.– roaima
Nov 30 at 8:51
User
crontab
files (including root's) don't have the extra user field. That is reserved for the system crontab
files found under /etc
.– roaima
Nov 30 at 8:51
I haven't downvoted. Your alternate syntax is completely irrelevant, and quite possibly adding confusion for the OP, who is already using valid syntax for the scenario they are demonstrating.
– roaima
Nov 30 at 8:54
I haven't downvoted. Your alternate syntax is completely irrelevant, and quite possibly adding confusion for the OP, who is already using valid syntax for the scenario they are demonstrating.
– roaima
Nov 30 at 8:54
@roaima Ah, now I got it. The entry sentences did not make it clear in the first place. Also, the OP used both syntaxes in the user crontab file and none of these worked because of another mistake, so he may not have been able to track it down.
– rexkogitans
Nov 30 at 9:08
@roaima Ah, now I got it. The entry sentences did not make it clear in the first place. Also, the OP used both syntaxes in the user crontab file and none of these worked because of another mistake, so he may not have been able to track it down.
– rexkogitans
Nov 30 at 9:08
Good point about the different crontab syntaxes. I knew that, but it slipped my mind. However, I believe that the rest of your answer was already covered by my answer (aside from verifying that scripts are executable, which seems irrelevant, inasmuch as the OP has successfully run her script from an interactive shell).
– G-Man
Nov 30 at 13:40
Good point about the different crontab syntaxes. I knew that, but it slipped my mind. However, I believe that the rest of your answer was already covered by my answer (aside from verifying that scripts are executable, which seems irrelevant, inasmuch as the OP has successfully run her script from an interactive shell).
– G-Man
Nov 30 at 13:40
add a comment |
Pixii Bomb is a new contributor. Be nice, and check out our Code of Conduct.
Pixii Bomb is a new contributor. Be nice, and check out our Code of Conduct.
Pixii Bomb is a new contributor. Be nice, and check out our Code of Conduct.
Pixii Bomb is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485065%2fcrontab-tasks-arent-running%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
What Linux distribution are you using? Is your cron daemon enabled and started?
– n.st
Nov 30 at 4:41
1
Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a
34 12 …
cronjob at 12:33:30.– n.st
Nov 30 at 4:47