337

Since upgrading my user's crontab has been wiped out. This is not the first time this has happened this year and it's a pain restoring it each time.

I'd like to be able to back up the crontab for my user but for that I need to know where it's stored.

7ochem
  • 191
Oli
  • 293,335
  • 6
    it would be nice if someone could also give a reason WHY it's wiped out – Walter Tross Nov 13 '12 at 14:52
  • 1
    @WalterTross Yeah it's quite annoying. I would guess it's a side-effect of updating the cron package but I agree - it's not something that should happen. – Oli Nov 13 '12 at 16:04
  • Uh, I don't that user cron's get wiped per cron package upgrade! – pl1nk Mar 28 '13 at 12:15
  • @pl1nk I've no idea what's wiping it out but it does keep happening. Ghost in the machine, I guess. – Oli Mar 28 '13 at 12:19
  • User tables are stored on a temporary area /var/spool/cron/crontabs/$USER, as such the may be deleted on your next boot or upgrading. – fcm Jun 09 '16 at 02:51
  • 1
    Just want to mention that there are instructions here about how to reconstruct an accidentally deleted crontab using logs: http://superuser.com/questions/384109/crontab-deleted It's not really what you were asking but it might be of use to someone. – msouth Dec 09 '16 at 16:01

4 Answers4

444

Actually, it's not recommended to handle those files by hand. Per crontab man page:

Each user can have their own crontab, and though
these are files in /var/spool/cron/crontabs, they are not
intended to be edited directly.

Files under /var/spool are considered temporary/working, that's why they probably get deleted during an upgrade, though a closer look at the cron package's upgrade scripts may shed some light on this.

Anyway, it's always a good practice to back up your cron entries or keep them in a file in your home directory.

I assume you're using crontab -e to create crontab files on the fly. If so, you can get a "copy" of your crontab file by doing crontab -l. Pipe that to a file to get a "backup":

crontab -l > my-crontab

Then you can edit that my-crontab file to add or modify entries, and then "install" it by giving it to crontab:

crontab my-crontab

This does the same syntax checking as crontab -e.

Oli
  • 293,335
roadmr
  • 34,222
  • 9
  • 81
  • 93
  • 16
    crontab -l is easier than going through /var/spool/cron/crontabs/$USER mostly because of the bizarre permissions on that file. – Oli Nov 13 '12 at 16:02
  • 2
    The iptables-save of cron. Nice... – Parthian Shot Jul 18 '15 at 00:10
  • if you use your root account for crontab, then its sudo crontab -l > root-crontab for roots crontab! – FreeSoftwareServers Jul 20 '15 at 03:06
  • 13
    Perhaps we should put a crontab to automatically back itself up >:)? – PascalVKooten Jul 27 '15 at 16:28
  • 5
    Poking through /var/spool/cron/crontabs is handy when you want to curate or examine crontabs from multiple users. – dhasenan Aug 06 '16 at 14:59
  • "Files under /var/spool are considered temporary/working" while true they can still contain important data (for example mail that is yet to be sent), so they shouldn't just be cleared out arbiterally. – Peter Green Sep 22 '16 at 13:37
  • 3
    When investigating mysteries on a server you aren't familiar with, it is common to sudo grep -rHin "$string" /etc/cron* (where string might be a command like docker, lftp, iptables, etc. It's a good idea to check user crontabs also. That's what lead me to this Q&A. sudo grep -rHin "$string" /etc/cron* /var/spool/cron* – Bruno Bronosky Dec 29 '17 at 17:10
68

Its stored inside /var/spool/cron/crontabs folder under username.

Manula Waidyanatha
  • 8,555
  • Thanks, I realize this is an old answer. It's at var/spool/cron/tabs/<user> on a recent OpenSuse Tumbleweed installation. – Pavin Joseph Feb 19 '24 at 07:56
36

I finally found out why my crontabs and Postfix installation kept breaking after boot. It's a really stupid reason but...

I had /var/spool mounted as a tmpfs RAM-drive.

Sounds idiotic and it is, but I had followed one of the old SSD-tweaks to lengthen the life of my SSD. In doing so, I blindly mounted /tmp, /var/tmp and /var/spool as tmpfs without thinking of the repercussions. I thought /var/spool was like /proc/ or /run/ and that it was only useful for the duration of the session. I was clearly wrong.

Ward Muylaert
  • 3,882
Oli
  • 293,335
  • 13
    It should be safe to mount /tmp as tmpfs, but not /var/tmp or /var/spool. /tmp is used for temporary storage that may be lost upon reboot. /var/tmp is used for temporary storage that will remain after a reboot. And as you've discovered, /var/spool is for data to be processed, which will also remain after a reboot. – thomasrutter Jun 30 '14 at 05:42
  • 2
    See http://www.pathname.com/fhs/2.2/fhs-5.15.html – thomasrutter Jun 30 '14 at 05:43
  • 2
    Note also that write count is no longer an issue with modern SSDs. – thomasrutter Jun 30 '14 at 05:45
20

To list all cron jobs from all users in your system:

for user in $(cut -f1 -d: /etc/passwd)
do
  echo $user
  crontab -u $user -l
done

An alternative to your issue would be to place them in cron.d folder and specify the appropriate user per cron as in example:

00 01 * * * user /home/user/user-script.sh
Pablo Bianchi
  • 15,657
pl1nk
  • 6,399
  • if you're recovering the crontab from another drive, this will not work because crontab -u is running from your current system. – JVE999 Oct 09 '14 at 21:38
  • While I suppose that is a one-liner in that it fits in less than 80 characters and is somewhat readable, I generally like to put code in a format such that a person can either copy-paste or put it in a script (and, in a script, this would not be one line of code). Suggesting edit... – Parthian Shot Jul 18 '15 at 00:14
  • Also, I was about to turn it into a while read user loop, to handle the case where the username contains spaces, but apparently that's not an issue. Very limited set of username characters. – Parthian Shot Jul 18 '15 at 00:24