Where is the user crontab stored?

  • 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.

    it would be nice if someone could also give a reason WHY it's wiped out

    @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.

    Uh, I don't that user cron's get wiped per cron package upgrade!

    @pl1nk I've no idea what's wiping it out but it does keep happening. Ghost in the machine, I guess.

    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.

    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.

  • roadmr

    roadmr Correct answer

    8 years ago

    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.

    `crontab -l` is easier than going through `/var/spool/cron/crontabs/$USER` mostly because of the bizarre permissions on that file.

    The `iptables-save` of cron. Nice...

    if you use your root account for crontab, then its sudo crontab -l > root-crontab for roots crontab!

    Perhaps we should put a crontab to automatically back itself up >:)?

    Poking through `/var/spool/cron/crontabs` is handy when you want to curate or examine crontabs from multiple users.

    "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.

    PERFECT answer. Thank you from October 2017.

    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*`

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

  • 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.

    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.

    Note also that write count is no longer an issue with modern SSDs.

  • 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
    

    if you're recovering the crontab from another drive, this will not work because `crontab -u` is running from your current system.

    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...

    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.

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM