Arch Linux

Originally I can't reproduce the problem in my system, but because I setup $EDITOR env var, and I use mcedit. Anyway setting EDITOR=vi also works fine.

Hi,
I can't reproduce it too. It works for me with vim and without setted $EDITOR.

@toomanymirrors: Can you tell us the output of
ls -la /var/spool/cron/

and of

ls -la /var/spool/cronstamps/

Weird, i can't reproduce it again. Waiting response from original reporter...

ls -la /var/spool/cron/
total 12
drwxr-xr-x 2 root root 4096 Feb 15 15:40 .
drwxr-xr-x 9 root root 4096 Feb 15 10:17 ..
-rw------- 1 root jalley 0 Feb 14 15:09 jalley
-rw------- 1 root root 513 Feb 15 15:39 root

ls -la /var/spool/cronstamps/
total 24
drwxr-xr-x 2 root root 4096 Jan 26 09:30 .
drwxr-xr-x 9 root root 4096 Feb 15 10:17 ..
-rw-r--r-- 1 root root 16 Feb 15 10:42 root.sys-daily
-rw-r--r-- 1 root root 16 Feb 15 19:41 root.sys-hourly
-rw-r--r-- 1 root root 16 Feb 13 15:30 root.sys-monthly
-rw-r--r-- 1 root root 16 Feb 9 17:54 root.sys-weekly

EDIT: I'm confused by what you mean by Fixed. Is there a patched version of crontab to deal with backup files or does everyone who uses vim have to disable backup files?

I have exactly the same problem here. I just installed Arch, didn't touch anything at all regarding cron, but crontab -e will just not record my changes NOT EVEN FOR ROOT. And no, it DOES NOT HAVE ANYTHING TO DO WITH THE EDITOR (just in case you suggest that). Used the 2009.08 netinstall for amd64. I'm currently pretty anoyed by this.
Stuff in /etc/cron.* get's executed just fine, and the prick is in DAEMONS. Now, there's no cron or crontab group in the system but if it doesn't even work for root, guess this is not the source of the problem.

EDIT: yes it did have to do with the editor, but it was not 100% the editor's fault =/

FIXED: The problem is that crontab checks if the file was changed checking the file descriptor, which is pointed to the backup file when backup is enabled in the editor. Another thing: when moving the original file to the backup name, and the edited version is written in it's place, the file is written without preserving the same permissions as the original, so if you have a umask that prevents others from reading your stuff, crontab won't be able to load the new file.

I've noticed this before, doing a :wq with vim as EDITOR will not save the changes. Hitting ZZ instead does write, save, quit, and update the crontab.

I now have this problem and can reliably reproduce it on 2 machines with 2 different users on each. Even if this is deemed to be 'not a bug' with dcron, please can we make sure that this bug is closed with clear instructions on how to fix the problem, since many others are likely to be affected. Thanks.

The problem: crontab resolves the path to a file handle, then runs the editor. Once the editor quits, it checks the original file handle for changes. It does not resolve the path again, so if the file has been moved/renamed, crontab maintains a handle on that file.

Many editors, particularly vim, make a form of backup (known in vim as 'writebackup') when writing, in case the write goes wrong (bad disk, hardware failure, power outage, etc), then at least the original file can be recovered. To do this, it moves the original file foo to foo~, and then saves the new version as foo. Because crontab keeps the same handle open, it's handle is still pointing to foo~, not foo. Thus, crontab sees no changes.

Personally I consider this to be a bug in crontab. Don't use file handles this way. Sure it might be slower to do it differently, but crontabs are small and don't change often.

In the meantime, there are 4 ways to fix this problem, at least in vim. Add one of the following to your .vimrc:
1. Disable writebackups completely:
set nowritebackup
2. Disable writebackups for crontab files only:
au BufEnter crontab.* setl nowritebackup ## This doesn't work for me, I don't know why ##
3. Set writebackup to copy instead of move, for all files:
set backupcopy=yes ##### SLOW, NOT RECOMMENDED #####
4. Set writebackup to copy instead of move for crontab files only:
au BufEnter crontab.* setl backupcopy=yes

I recommend option 4, though I still maintain that this is a bug in crontab. Other editors may have this problem, consult the documentation or support channels for your editor to find a similar fix.

(I am upstream maintainer.) Thanks for this input; and apologies for the long delay handling it. I hadn't seen this behavior myself. Keeping the file handle open is a deliberate part of crontab's security model. I think the best fix for now is to fold option 4 into the packaging scripts; I'll provide a stub crontab.vim file in the tarball. Where is the best place to install this---perhaps /usr/share/vim/vimfiles/ftplugin/crontab.vim? This will only address the problem for vim and not for other editors, but as I said, changing crontab's handling of file handles would require fundamentally changing the security model.