330

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
  • 1
  • 5
  • 16
Oli
  • 289,791
  • 117
  • 680
  • 835
  • 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

436

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
  • 289,791
  • 117
  • 680
  • 835
roadmr
  • 33,892
  • 9
  • 80
  • 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
  • 1
    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
  • 10
    Perhaps we should put a crontab to automatically back itself up >:)? – PascalVKooten Jul 27 '15 at 16:28
  • 4
    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
  • 2
    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,465
  • 1
  • 21
  • 20
35

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,864
  • 2
  • 23
  • 31
Oli
  • 289,791
  • 117
  • 680
  • 835
  • 12
    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
19

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
  • 14,308
  • 4
  • 74
  • 117
pl1nk
  • 6,229
  • 5
  • 26
  • 46
  • 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