326

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.

Improve this question
6
  • 6
    it would be nice if someone could also give a reason WHY it's wiped out
    – Walter Tross
    Nov 13, 2012 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, 2012 at 16:04
  • Uh, I don't that user cron's get wiped per cron package upgrade!
    – pl1nk
    Mar 28, 2013 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, 2013 at 12:19
  • 1
    Just want to mention that there are instructions here about how to reconstruct an accidentally deleted crontab using logs: superuser.com/questions/384109/crontab-deleted It's not really what you were asking but it might be of use to someone.
    – msouth
    Dec 9, 2016 at 16:01

4 Answers 4

Reset to default
431

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.

Improve this answer
7
  • 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, 2012 at 16:02
  • 1
    The iptables-save of cron. Nice...
    – Parthian Shot
    Jul 18, 2015 at 0:10
  • 10
    Perhaps we should put a crontab to automatically back itself up >:)?
    – PascalVKooten
    Jul 27, 2015 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 6, 2016 at 14:59
  • 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, 2017 at 17:10
68

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

Improve this answer
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.

Improve this answer
3
  • 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, 2014 at 5:42
  • 2
    See pathname.com/fhs/2.2/fhs-5.15.html
    – thomasrutter
    Jun 30, 2014 at 5:43
  • 2
    Note also that write count is no longer an issue with modern SSDs.
    – thomasrutter
    Jun 30, 2014 at 5:45
18

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
Improve this answer
3
  • if you're recovering the crontab from another drive, this will not work because crontab -u is running from your current system.
    – JVE999
    Oct 9, 2014 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, 2015 at 0: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, 2015 at 0:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.