I have a few cron jobs at server machine scheduled to do few things. I want to let user modify those cron jobs using a web application (jsp page). So lets say (example scenario) some job is scheduled to run at 2 PM, I want user the option to change its time.
It looked very trivial to start with, but now I am stuck. I am new to Linux. How to create cron jobs currently is : crontab - e ; and then I manually add new jobs as required. But I want to provide this capability to a remote user through a web interface.
Please help !
Let's say that your crontab has a following line:
20 3 * * * /home/somebody/somescript.sh
You can list your crontab using the following command:
crontab -l
Then you can change the scheduled time using the command sed:
sed 's/20 3 \* \* \* \/home\/somebody\/somescript.sh/30 4 \* \* \* \/home\/somebody\/somescript.sh/'
Finaly, you'll commit it to crontab again by passing the new file to the crontab command.
The result will be combination of the three commands discussed above and will be connected by pipes:
crontab -l | sed 's/20 3 \* \* \* \/home\/somebody\/somescript.sh/30 4 \* \* \* \/home\/somebody\/somescript.sh/' | crontab
The first command will list the current crontab to standard output. Then sed will replace the time and pass the replaced file to the crontab command, which will install it as a new crontab.
Be aware though, that most servlets do not have sufficient system rights to create or modify crontab.
Related
I am currently working on some school project where we should be dealing with cron jobs, basically, we are building a simple CLI to do CRUD operations using Bash.
I found this snippet of code that inserts a new job into my crontab, yet I have no idea how it works... I understand it uses subshell and pipes, yet I just don't know why I would have to do it
read job
{ crontab -l; echo "$job"; } | crontab -
crontab is a file which contains jobs (instructions) for cron daemon (time-based job scheduler for Unix operating system).
If you put your bash lines into a script , let's say cron_test.sh
#!/usr/bin/sh
read job
{ crontab -l; echo "$job"; } | crontab -
And afterwards if you execute the script ./cron_test.sh, you'll see that the scripts awaits from stdin your input (which stores it into variable named job) in order to create a new job for your user.
Be careful because you have to respect the job syntax:
1 2 3 4 5 /path/to/command arg1 arg2
where:
1: Minute (0-59)
2: Hours (0-23)
3: Day (0-31)
4: Month (0-12 [12 == December])
5: Day of the week(0-7 [7 or 0 == sunday])
/path/to/command – Script or command name to schedule
Some commands:
crontab -l - list current crontab (for the user which you're using)
crontab -e - edit the crontab file
I'm trying to run the following script through crontab every day at 12 :
#!/bin/sh
mount -t nfs 10.1.25.7:gadal /mnt/NAS_DFG
echo >> ~/Documents/Crontab_logs/logs.txt
date >> ~/Documents/Crontab_logs/logs.txt
rsync -ar /home /mnt/NAS_DFG/ >> ~/Documents/Crontab_logs/logs.txt 2>&1
unmout /mnt/NAS_DFG
As it needs to run in sudo, I added the following line to 'sudo crontab' such that I have :
someone#something:~$ sudo crontab -l
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
0 12 * * * ~/Documents/Crontab_logs/Making_save.sh
But it does not run. I mention that just executing the script thourgh :
sudo ~/Documents/Crontab_logs/Making_save.sh
works well, except that no output of the rsync command is written in the log file.
Any ideas what's going wrong ? I think I checked the main source of mistakes, i.e. using shell, leaving an empty line at the end, etc ...
sudo crontab creates a job which runs out of the crontab of root (if you manage to configure it correctly; the syntax in root crontabs is different). When cron runs the job, $HOME (and ~ if you use a shell or scripting language with tilde expansion) will refer to the home of root etc.
You should probably simply add
0 12 * * * sudo ./Documents/Crontab_logs/Making_save.sh
to your own crontab instead.
Notice that crontab does not have tilde expansion at all (but we can rely on the fact that cron will always run out of your home directory).
... Though this will still have issues, because if the script runs under sudo and it creates new files, those files will be owned by root, and cannot be changed by your regular user account. A better solution still is to only run the actual mount and umount commands with sudo, and minimize the amount of code which runs on the privileged account, i.e. remove the sudo from your crontab and instead add it within the script to the individual commands which require it.
I want to edit system cron tab (/etc/crontab). I read that crontab -e is the best way to edit crontab and you need not restart cron services if you edit this way. However I am not able to edit /etc/crontab using crontab -e (this command edits the crontab associated with the user, not system crontab). So is there any better way of editing /etc/crontab (other than using VI editor- which I am doing now). Do I need to restart cron services if I edit /etc/crontab using VI edior?
There are two ways of cronjobs, one is by editing /etc/crontab and sending a SIGHUP the cron daemon. The other way is to use crontab -e to edit
a crontab entry, which is done for the current user or the one mentioned with -u. The -u option can only be used by root. The crontabs
created this way can be found in the directory
/var/spool/cron/crontabs/
and are named after the user with which uid the jobs will be started. In this case you don't need to SIGHUP cron, a normal user can't do this anyway.
Note: The syntax is slightly different to /etc/crontab: You can't enter an other user name to execute the cronjob.
You could do something like this
echo "0 23 * * * yum -y update > /dev/null 2>&1" >> /var/spool/cron/root
Then verify with
crontab -l
I developed a script in which I add lines to the crontab file with echo command and I remove lines with sed command.
I do not know the risk of that especially that I find in some web site that we have to edit crontab file with
crontab -e
What is the risk of does not using crontab -e?
Are there a risk that my edit will not taken account in the cron
schedule?
Should I restart cron with /etc/init.d/cron restart?
The main risk to not using crontab to edit or replace cronfiles is that directly writing to the cronfile (including using sed to do so) does not lock the file, and therefore two simultaneous edits could have unpredictable and even disastrous consequences.
You don't have to use crontab -e; the following forms of editing are semi-safe, in the sense that they won't randomly combine two edits. (But they are still unsafe; an edit could be overwritten):
To add lines:
{ crontab -u user -l; echo "$this"; echo "$this_too"; } | crontab -u user -
To delete lines or do more complicated edits:
crontab -u user -l | sed "$my_wonderful_sed_script" | crontab -u user -
In any case, you don't need to restart cron. It will notice the changed modification time of the cronfile.
When editing the crontab file using your regular editor, the schedule will not be updated. The system will still do the scheduled tasks as before the edit. This will drive the administrator mad.
When cron restarts, such as a reboot or a restart of the process, the current crontab files will be read and processes are scheduled as described in the current present files.
I remember sending a 'kill -HUP' or 'kill -15' to the PID of the cron process to force the process flushing the cache and reading the crontab files again.
I want to get the details of the last run cron job. If the job is interrupted due to some internal problems, I want to re-run the cron job.
Note: I don't have superuser privilege.
You can see the date, time, user and command of previously executed cron jobs using:
grep CRON /var/log/syslog
This will show all cron jobs. If you only wanted to see jobs run by a certain user, you would use something like this:
grep CRON.*\(root\) /var/log/syslog
Note that cron logs at the start of a job so you may want to have lengthy jobs keep their own completion logs; if the system went down halfway through a job, it would still be in the log!
Edit: If you don't have root access, you will have to keep your own job logs. This can be done simply by tacking the following onto the end of your job command:
&& date > /home/user/last_completed
The file /home/user/last_completed would always contain the last date and time the job completed. You would use >> instead of > if you wanted to append completion dates to the file.
You could also achieve the same by putting your command in a small bash or sh script and have cron execute that file.
#!/bin/bash
[command]
date > /home/user/last_completed
The crontab for this would be:
* * * * * bash /path/to/script.bash
/var/log/cron contains cron job logs. But you need a root privilege to see.
CentOs,
sudo grep CRON /var/log/cron