Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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. Over to you.

share|improve this question
1  
it would be nice if someone could also give a reason WHY it's wiped out –  Walter Tross Nov 13 '12 at 14:52
    
@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

4 Answers 4

up vote 30 down vote accepted

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.

share|improve this answer
2  
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

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

share|improve this answer

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.

share|improve this answer
    
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. –  neon_overload Jun 30 at 5:42
    
    
Note also that write count is no longer an issue with modern SSDs. –  neon_overload Jun 30 at 5:45

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
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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