UNIX for Dummies Questions & Answers

Thanks for your suggestions guys, sorry for the radio silence, been on holiday up in the mountains and hence arguing with crontab wasn't at the top of my to do list. Anyway back to it...

I've checked the disk usage and there's no problems there.

I've compared the permissions on the existing /var/spool/cron/crontabs/root file (so it must have worked at some point) and the enclosing directories with another more co-operative machine and can find no differences.

cat-ing the root crontab gives:

Code:

 
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.XXXXfllSSh installed on Sun Jun 20 18:46:36 2004)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
0 21 * * * /root/bin/backup.pl

I can touch a file matching my username (as root) in /var/spool/cron/crontabs/ but not under my user account (same behaviour as on the other machine) which I've then 600-ed and root.users-ed to match the permissions on the other machine.

Running:

Code:

crontab -u username /var/spool/cron/crontabs/username

and then cat-ing the file reveals that it has been populated with the cron header:

Code:

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/var/spool/cron/crontabs/username installed on Tue Apr  5 12:57:35 2005)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)

But still crontab -u username -e results in the same error message and the changes not being written to the file.

As for finding documentation for permissions for my OS (debian), I've checked out the man pages for cron and crontab but I'll hunt the web for more info, any suggestions? Also it does talk about making sure that the editor edits the file in place and does not make a copy. I'm using vim which I would have thought wouldn't be a problem but when editing my crontab using a crontab -u username -e does show "/tmp/crontab.XXXX2qwBiu" in the status bar. Although the other machine which plays nice also exhibits this behaviour.

what about creating the crontab file through vi(m), saving it in /tmp, manually moving it to /var/spool/cron/crontabs, and then restarting cron?

Ah ha!

My inkling that the problem may lie with vim seems to have some legs. Temporarily changing the $EDITOR environment variable to /usr/bin/nano and then doing the crontab edit did the job. No more error message and crontab -u username -l reports that the changes were saved successfully. Oh the joy.

Anyone know what vim's problem is? I personally think its just looking for a slap but any other solutions more technical in nature would be gratefully received.

Cheers Ice, just missed your post before posting my last. Thanks for the reply, I've found a workaround now tho. Its not perfect but it gets the job done, any idea why vim doesn't want to play nice with crontab?

i actually don't use vim but i'm guessing that it uses some code that crontab doesn't understand ... anyways, glad to hear you've solved your problem.

Just curious what version of vim you are using? We aren't using the latest one atm, just lazy I guess. We are still on version 5.7.2001-06-12

http://www.vim.org/ You might try the latest version if you are not on it right now.

Also, you can directly edit the crontab file which I suspect you are doing now, but you didnt mention... mine are in /var/spool/cron/crontabs.... hpux.

I'm using vim version 6.1.18, which isn't that old and its the latest available using apt-get.

No, I didn't directly edit the crontab when I got it working, I just temporarily changed the EDITOR environment variable from /usr/bin/vim to /usr/bin/nano and then did a crontab -u username -e.

Having just done a quick google on 'crontab vim' I came across this thread which might have something to do with it. Next time I need to play with crontab, I'll see if .vimrc is causing the problem.