When a database environment is being patched, entries from crontab are commented and then removed when patching is completed.
The process works well when there are only a few entries from crontab, but it does not scale when crontab has dozens of entries and when some entries are commented and some are not.
I believe a more efficient method is to backup and restore the existing crontab.
Here’s a demo:
Crontab entries.
[[email protected] ~]$ crontab -l */05 * * * * /bin/date > /tmp/date.out 2>&1 */15 * * * * /bin/date > /tmp/date.out 2>&1 #*/25 * * * * /bin/date > /tmp/date.out 2>&1 */35 * * * * /bin/date > /tmp/date.out 2>&1 */45 * * * * /bin/date > /tmp/date.out 2>&1 */55 * * * * /bin/date > /tmp/date.out 2>&1
Backup crontab and display contents. Extra precaution in case crontab.save.dinh is removed.
[[email protected] ~]$ crontab -l > crontab.save.dinh; cat crontab.save.dinh */05 * * * * /bin/date > /tmp/date.out 2>&1 */15 * * * * /bin/date > /tmp/date.out 2>&1 #*/25 * * * * /bin/date > /tmp/date.out 2>&1 */35 * * * * /bin/date > /tmp/date.out 2>&1 */45 * * * * /bin/date > /tmp/date.out 2>&1 */55 * * * * /bin/date > /tmp/date.out 2>&1
Remove crontab.
[[email protected] ~]$ crontab -r; crontab -l no crontab for oracle
Restore crontab.
[[email protected] ~]$ crontab crontab.save.dinh; crontab -l */05 * * * * /bin/date > /tmp/date.out 2>&1 */15 * * * * /bin/date > /tmp/date.out 2>&1 #*/25 * * * * /bin/date > /tmp/date.out 2>&1 */35 * * * * /bin/date > /tmp/date.out 2>&1 */45 * * * * /bin/date > /tmp/date.out 2>&1 */55 * * * * /bin/date > /tmp/date.out 2>&1
If you are lazy like me, then backup can be done in one command.
[[email protected] ~]$ crontab -l > crontab.save.dinh; cat crontab.save.dinh; crontab -r; crontab -l */05 * * * * /bin/date > /tmp/date.out 2>&1 */15 * * * * /bin/date > /tmp/date.out 2>&1 #*/25 * * * * /bin/date > /tmp/date.out 2>&1 */35 * * * * /bin/date > /tmp/date.out 2>&1 */45 * * * * /bin/date > /tmp/date.out 2>&1 */55 * * * * /bin/date > /tmp/date.out 2>&1 no crontab for oracle [[email protected] ~]$
4 Comments. Leave new
Worth noting it!!!
I remember an incident when a DBA just typed crontab -r instead of crontab -l, not to blame him completely as ‘R’ and ‘L’ keys are just besides each other.. scheduled jobs were wiped off without any warning..
Regards
Maaz
Base on current event, this is better
crontab -l > crontab.save.dinh; cat crontab.save.dinh; chmod 600 crontab.save.dinh
This will prevent accidents such as shown below:
crontab -l > crontab.save.dinh; cat crontab.save.dinh
crontab -r; crontab -l
Got distracted and if this is run again the crontab will be really bad.
crontab -l > crontab.save.dinh; cat crontab.save.dinh
This will prevent accident due to distractions.
Noted Michael,
Also, a monthly backup with root user can be really helpful just in case if these entries are messed up –
/var/spool/cron contains files for all users that have cron scheduled jobs.
Thanks for sharing Maaz.