What happens if you type
crontab -r instead of
crontab -e ? Well, your crontab gets immediately deleted, without any further confirmation request. That is sub-optimal, especially because ‘r’ lays next to ‘e’, which is frequently used for editing the crontab (I really would appreciate it if
crontab -r would ask the user, while
crontab -R would not ask).
The first thing to try to undo the mistake, is to check whether there are some backups of the previously installed crontab (e.g. in /etc/cron* or some system-dependent backup) and then reinstall these.
If this is not the case (as usual), then there is no other way than creating a new crontab. But how do we know which entries were defined in it before deleting? Here, the system logs in /var/logs/ help us a lot, since it stores all crontab-calls of the long past and makes them easily to extract, since “/usr/sbin/cron” is part of the message (possibly in upper-case!). So, depending on your system, cat and grep all crontab lines from the messages* files into some output file, e.g.,
cat /var/logs/messages | grep -i "`which cron`" > /tmp/cron
where `which cron` is used to automatically be replaced by for example /usr/sbin/cron, depending on your system. You should also append all data from older messages, as usually stored as .gz or .bz archive. For .gz you might use:
gzip -d /var/logs/messages*.gz -c | grep -i "`which cron`" >> /tmp/cron
Now /tmp/cron is a file that contains all crontab-calls. You might use the
less command to display its entries. Choose any line to handle at first, and Copy&Paste its <command> call (where <command> denotes the stuff in the bracktes after ‘CMD’) to a new textfile in which you rebuild your new crontab. To get the time interval for this command call, use the search function and have a look at the date/time when this call is repeated. Using
less, just type /<command>, this will highlight all occurences. So, once you have extracted this call and recreated it using the appropriate * * * * * <command> syntax, you might delete all its occurences from /tmp/cron. You might do this by
cat /tmp/cron | grep -v "<command>" > /tmp/cron.out; mv /tmp/cron.out /tmp/cron
By repeating these steps, the file /tmp/cron gets smaller and smaller and you finally can be sure to have all crontab-calls handled that were made in the past since the first log entry.
Furthermore, since the file /tmp/cron decreases quite rapidly over time (there might be thousands of lines for just 10 crontab commands or so), you get the feeling to make progress, so its not that awful anymore that you called
crontab -r before 🙂
After installing the newly created crontab, you should call the following command to manually backup your crontab:
crontab -l > ~/crontab.bak
Hopefully, this helps some of you out there that are in the same problematic situation…