I am trying to update root's crontab by running crontab -e under roots login.

However, I find that after saving :x and then listing the crontab, it is not updated.

All is well for other users crontabs.

Any ideas?

Slack9.1

Come on, someone must know something about this...

Please....

I can't help much with a solution, but I'm having the same problem. Crontab -e creates a temp file named crontab.12345 (or whatever) under /var/spool/cron, and if you save the file in your text editor but do not close it, you can see the changes if you cat out the file. However, when you exit the text editor, this temp file isn't copied into /var/spool/cron/crontabs/root. It's not a permissions problem, since chmod 777 doesn't seem to resolve it. I suspect something like a lockfile, but I don't know enough about the nuts and bolts of dillon-cron to know where one might be. /var/log/cron is empty, and no helpful error messages are to be found in any of the other usual logfiles.

We first experienced this on a Slackware 8.0 box, and I've tried various things to resolve it -- restarting crond, reinstalling crontab from package, reinstalling crontab from source, deleting and recreating the /var/spool/cron directory. I can reproduce it on two separate Slack 9.1 installs, so it's not the result of some funkiness on one particular box. Like plisken says, it's not a problem for regular users, only for root.

I realize I can just manually edit /var/spool/cron/crontabs/root, but I would like to know what's going on here.

I've also noticed that as root, if you were to make changes to another users crontab by doing the following:

crontab -u otheruser -e

It does not update either, it has to be done by the user itself.

I did think it was something on my setup, but it is good to see that others have the same problem, well not good, but you know what I mean

Today, I was expecienced this crontab strange behaviour, crontab -e didn't update my cron job list. What is really a concern is it happened some days after the april fool day... It's the very first time (after more than a decade of system administration) I'm faced to such a basic refusal. Is it a vi flaw ? (surely not), a hacked cron ? (I should consider this as a plausible and definetely possible reason). Would like to know much more about all this. Thanks for reporting your fix.

Actually the real concern is that you make a link with something not working as you expect and april fools... ;-)

Anyway... it does sound like a locking thing. Did you try to update it when crond isn't running?

I found that i get this because i linked /usr/bin/vi to vim.

export VISUAL=/usr/bin/elvis
crontab -e

^ this should work

coderock

OK, I was kidding, there's no kind of link nor correlation with april fools . I shut down crond then I reinstalled my rpm. Didn't change anything at all. Then I compilled source....same result ( I didn't expect anything else frankly ). Permissions on implied files are correct, I test this on a daily basis for all the system. Well, the one and only "fix" is atee's one (thread just above mine).
You should ask me about my RedHat box environment. It acts as a java application server, as apache server and as an automated GIS image processor. I never run into any kind of conflicts between them.
Thanks for your suggestion.

A precision: crond daemon was running when I was editing crontab ( my fetching automat does need it ).