If adding a command that repeats every 10 minutes to crontab, when does the first job run? - linux

As part of the setup of a docker container, the following gets injected into crontab:
*/10 * * * * /opt/run.sh >> /opt/run_log.log
According to the behavior of crontab, when should the first run kick off? Should the 10 minute cycle begin instantly, or 10 minutes after this is put into crontab. Neither behavior is happening so I am trying to debug this in more depth by trying to understand the intended behavior.

This cron sandbox simulator gives you an idea:
Mins Hrs Day Mth DoW
*/10 * * * *
This run time (UTC) Sat 2016-Jan-23 0653
Forward Schedule Sat 2016-Jan-23 0700
Sat 2016-Jan-23 0710
Sat 2016-Jan-23 0720
It uses the syntax:
Every nth '0-23/n', '*/2' would be every other.
'*/1' is generally acceptable elsewhere, but is flagged here as possibly an unintended entry.
See for example "Run a cron job with Docker" (by Julien Boulay)
Let’s create a new file called “crontab” to describe our job.
* * * * * root echo "Hello world" >> /var/log/cron.log 2>&1
# An empty line is required at the end of this file for a valid cron file.
The following DockerFile describes all the steps to build your image
FROM ubuntu:latest
MAINTAINER docker#ekito.fr
# Add crontab file in the cron directory
ADD crontab /etc/cron.d/hello-cron
# Give execution rights on the cron job
RUN chmod 0644 /etc/cron.d/hello-cron
# Create the log file to be able to run tail
RUN touch /var/log/cron.log
# Run the command on container startup
CMD cron && tail -f /var/log/cron.log
Then you can build the image with
sudo docker build --rm -t ekito/cron-example .
And run it:
sudo docker run -t -i ekito/cron-example
Be patient, wait for 2 minutes and your commandline should display:
Hello world
Hello world
If you replaced the first '' by '/10', you would have to wait to the next 0 or 10 or 20 or... of the hour.

Related

Docker cron scheduled job not running

I am trying to use a docker container based on an Alpine image to run a scheduled cron job, following this tutorial, but after printing the statement in my startup script, the container just exits, without running my other script.
My docker-compose service is configured as follows:
cron:
image: alpine:3.11
command: /usr/local/startup.sh && crond -f -l 8
volumes:
- ./cron_tasks_folder/1min:/etc/periodic/1min/:ro
- ./cron_tasks_folder/15min:/etc/periodic/15min/:ro
- ./cron_tasks_folder/hourly:/etc/periodic/hourly/:ro
- ./scripts/startup.sh:/usr/local/startup.sh:ro
So it runs an initial script called startup.sh and then starts the cron daemon. The startup.sh script contains the following:
#!/bin/sh
echo "Starting startup.sh.."
echo "* * * * * run-parts /etc/periodic/1min" >> /etc/crontabs/root
crontab -l
sleep 300
I dropped a sleep command in there just so I could launch an interactive shell on the container and make sure everything inside it looks good. The script creates another folder for 1min scripts. I have added a test script in there, and I can verify it's there:
/etc/periodic/1min # ls -a
. .. testScript
The script is executable:
/etc/periodic/1min # ls -l testScript
-rwxr-xr-x 1 root root 31 Jul 30 01:51 testScript
And testScript is just an echo statement to make sure it's working first:
echo "The donkey is in charge"
And looking at the root file in etc/crontabs, I see the following (I've re-run the container several times, and each time it's creating a new 1min folder, which is unnecessary, but I think not the problem here):
# do daily/weekly/monthly maintenance
# min hour day month weekday command
*/15 * * * * run-parts /etc/periodic/15min
0 * * * * run-parts /etc/periodic/hourly
0 2 * * * run-parts /etc/periodic/daily
0 3 * * 6 run-parts /etc/periodic/weekly
0 5 1 * * run-parts /etc/periodic/monthly
* * * * * run-parts /etc/periodic/1min
* * * * * run-parts /etc/periodic/1min
* * * * * run-parts /etc/periodic/1min
* * * * * run-parts /etc/periodic/1min
* * * * * run-parts /etc/periodic/1min
The echo statement in testScript is never printed to my terminal, and the container exits with exit code 0 shortly after starting. I want to print this statement every minute... what am I missing?
In the docker compose file you have
command: /usr/local/startup.sh && crond -f -l 8
The intention is to run as a shell command, but it's not at all clear from the question that's what's going to happen; that depends on your ENTRYPOINT. Since it's defined with [] brackets, not additional shell will be provided. The command value will be passed as arguments to the ENTRYPOINT.
Assuming that will become a shell command, && in the shell runs the left hand side, and if that succeeds, then runs the right hand side. So startup.sh needs to complete before crond is executed. startup.sh ends with
sleep 300
crond is invoked only after that 300 seconds.
In either case, crond is either not invoked at all, or sleep has not been completing. The comments show that an error starting crond was discovered.
Using an entrypoint such as this is standard practice to configure the environment before, or provide runtime parameters when, invoking the main executable. To do it right, you should make sure to use exec to run the main executable so that it receives the signals that would otherwise go to the bash shell running the entrypoint script.
So at the end of startup.sh:
exec crond -f -l 8
Will replace the shell running startup.sh with crond, so that crond receives all signals (at this point the shell is gone). It's subtle but important!
In general, keep the invocation of the application as simple as possible. Case in point, your execution process was split between entrypoint, command, and startup script, with no clear interface between them. You wouldn't have gotten hung up on the invocation if you had put crond directly into the Dockerfile and left it at that. Sometimes arguments must be provided at runtime, but environment variables - which have names, not just positions - are often preferred. This keeps invocations simple and debugging straightforward. But, when that doesn't work, a shell script entrypoint is a great solution - just make sure to exec your final process!

How to update the crontab and check if its running correctly?

I've modified the crontab with:
sudo crontab -e
and added a cron for a script to run every minute so I can test if it works:
1 * * * * /scripts/backup-script.sh > /scripts/backup-script.logs
Afterwards, I tried to restart the cron service to restart the server but the cron doesn't seem to be working, I tried to use:
crontab -l
and it appears to have the old content as if I didnt even modify it. However, going into crontab -e does show the updated content.
To make your script run every minute your cron record must be:
* * * * * /scripts/backup-script.sh > /scripts/backup-script.logs
What you enter will run every 1st minute every hour
And if you add record via crontab command you do not need to touch cron daemon
To see the cron record you add with sudo crontab -e you must check it with command sudo crontab -l. Otherwise you list cron record of different user

Cron job not auto runs inside a Docker container

I have a LAMP container with supervisor.
I add a simple cron
* * * * * root /bin/date >> /var/log/cron.log
from my Dockerfile
ADD ./crons/test /etc/cron.d/test
RUN chmod 0777 /etc/cron.d/test
I start cron via supervisor with a supervisor-cron.conf like this:
[program:cron]
command=/bin/bash -c "cron -f"
numprocs=1
autostart=true
autorestart=true
startretries=2
Cron starts fine and stays up and running. The strange thing is that no cronjob is running automatically [as it should] but when I execute docker exec lamp crontab /etc/cron.d/test the cron job starts and works as expected.
Am I missing something? Everywhere I have read that cron jobs are executed automatically by cron.
I solved it.
I tried both setting them up in /etc/crontab and /etc/cron.d/ .
Cron didn’t auto-start the cron jobs .
However, when I run docker exec lamp crontab /etc/cron.d/my_cronjob_file all played nice. This made me suspicious , and then I read this . So, after adding my_cronjob_file in the container [in the dockerfile] I added RUN crontab /etc/cron.d/my_cronjob_file . This essentially ‘installs’ the cronjob to the crontab table. [I don’t know the internals of cron/tab but that’s the gist I understood.] .
After that , the cron service comes up by supervisor and the cronjob runs like a charm.
This can be solved with the bash file, due to the layered architecture of the Docker, cron service doesn't get initiated with RUN/CMD/ENTRYPOINT commands.
Simply add a bash file which will initiate the cron and other services (if required)
DockerFile
FROM gradle:6.5.1-jdk11 AS build
# apt
RUN apt-get update
RUN apt-get -y install cron
# Setup cron to run every minute to print (you can add/update your cron here)
RUN touch /var/log/cron-1.log
RUN (crontab -l ; echo "* * * * * echo testing cron.... >> /var/log/cron-1.log 2>&1") | crontab
# entrypoint.sh
RUN chmod +x entrypoint.sh
CMD ["bash","entrypoint.sh"]
entrypoint.sh
#!/bin/sh
service cron start & tail -f /var/log/cron-2.log
If any other service is also required to run along with cron then add that service with & in the same command, for example: /opt/wildfly/bin/standalone.sh & service cron start & tail -f /var/log/cron-2.log
Once you will get into the docker container there you can see that testing cron.... will be getting printed every minute in file: /var/log/cron-1.log

Linux bash shell script output is different from cronjob vs manually running the script

I wrote a linux bash shell script which works fine except the output when I run it manually is different than when I run it from a cronjob.
The particular command is lftp:
lftp -e "lcd $outgoingpathlocal;mput -O $incomingpathremote *.CSV;exit" -u $FTPUSERNAME,$FTPPASSWORD $FTPSERVER >> ${SCRIPTLOGFILE} 2>&1
When I run the script manually, the ${SCRIPTLOGFILE} contains a lot of info such as how many files/bytes/etc transferred. But when I run the same script from a cronjob there is no output unless there was an error (such as could not connect). I have tried various terminal output configurations but none work for this lftp command. Suggestions?
It's worth reading this:
crontab PATH and USER
In particular, cron won't set the same environment variables you're used to an interactive shell.
You might want to wrap your entire cron job up in a script, and then you can, for example, temporarily add some code like export >> scriptenvironment.txt and see what the difference is between the cron invoked script and the interactively invoked script.
Try man 5 crontab for details.
Once you know what envrionment variables you need for your script to run, you can set them in the crontab as necessary, or source at the start of your own script.
EXAMPLE CRON FILE
# use /bin/sh to run commands, overriding the default set by cron
SHELL=/bin/sh
# mail any output to `paul', no matter whose crontab this is
MAILTO=paul
#
# run five minutes after midnight, every day
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
# run at 2:15pm on the first of every month -- output mailed to paul
15 14 1 * * $HOME/bin/monthly
# run at 10 pm on weekdays, annoy Joe
0 22 * * 1-5 mail -s "It's 10pm" joe%Joe,%%Where are your kids?%
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
5 4 * * sun echo "run at 5 after 4 every sunday"

Cron job does not run in RHEL

I'm running RHEL and I'm trying to set up a cron job to run a shell script every 5 minutes.
Following the directions here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Automating_System_Tasks.html#s2-configuring-cron-jobs
I have service crond start and chkconfig crond on. Then I edited /etc/crontab and added:
*/5 * * * * my-user /path/to/shell.sh
I did a chmod +x shell.sh. And I made sure to add a new line character at the end.
I'm expecting it to run every 5 minutes but it never executes.
What am I doing wrong?
Simply try to add the cronjob entry and check the script is working fine or not by taking the viewable output in the script.
echo "test time - $(date)" > script.sh
chmod +x script.sh
crontab -e
Then enter the cronjob as below,
*/5 * * * * sh /path/to/script.sh > /path/to/log.file
Check if the log is writing correctly. If its fine, better cross check the script that you are trying to execute via cron. Otherwise it will be a cron issue.

Resources