I'm trying to create a new crontab entry for a user on a debian box but whenever I do a crontab -e or crontab -u username -e then edit the crontab (with vim as my default editor) and :wq. I get the error message:
no crontab for username - using an empty one
crontab: no changes made to crontab
I've tried editing as both the user and as root and have the same problem. I've also tried editing the root crontab and have the same problem. Crontab just doesn't want to play nice on this machine (I've tried it on another debian box and its all fine).
The entry I'm trying to add is:
0,15,30,45 * * * * php /home/username/sandbox/X/xxxx/codebase/bin/client.php all
and I've added a blank line after it as I read somewhere that not having it may cause problems.
Anyone got any ideas?
So far I've checked permissions of /var/spool/cron and /var/spool/crontabs, and they are the same on both machines.
My editor is set to /usr/bin/vi (which is a symlink to vim). The only other thing of note is that on this, for some reason /tmp has been symlinked to /var/www/tmp (its one of our web dev servers) but the permissions seem fine on that directory.
Check the contents of /etc/cron.allow and /etc/cron.deny. Also check the log file for cron (default is /var/log/cron.log I believe - check /etc/syslog.conf to see if it's changed).
I forgot to mention before that I had checked for both /etc/cron.allow and /etc/cron.deny, neither of which exist. The man page for crontab doesn't seem to think that would be a problem tho. (Quoted for others who might have this problem):
"If the /etc/cron.allow file exists, then you must be listed therein in order to be allowed to use this command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does exist, then you must not be listed in the /etc/cron.deny file in order to use this command. If neither of these files exists, then depending on site-dependent configuration parameters, only the super user will be allowed to use this command, or all users will be able to use this command. For standard Debian systems, all users may use this command."
For some reason cron logging had been commented out in syslog.conf so after de-commenting it:
Mar 9 14:49:27 hostname crontab[10627]: (root) BEGIN EDIT (username)
Mar 9 14:49:58 hostname crontab[10627]: (root) END EDIT (username)
I know this may sound dumb but did you check the permission on the crontab file. Even if you are root you can't write to a file that doesn't have writ permission. Sometime we often over look the simple thing.
Good point larryase. I had had a look at the permissions on the crontab files but not the binary itself. Anyway this is what I got on /usr/bin/crontab:
# ls -l /usr/bin/crontab
-rwsr-xr-x 1 root root 22460 Oct 1 2001 /usr/bin/crontab
Not sure what the 's' in the owner permissions is about?!?
I tried chmodding it to 755 but I'm still getting the same problem.
The -rws is the set-user-ID (or set-group-ID if it's in the group) bit - see the man pages for ls and chmod (by the way, you need it on there).
As far as your original problem, check your permissions on the directories above where the crontab files are - to make sure you can create or change files, try creating a new file in the directory (touch justsomejunkfile) and then delete it if it does get created (as cron won't like it being there).
See if you can find documentation for your OS as far as the permissions set for the directories and crontab files.
I had this same problem, I looked the the disk free space and found that /var was at 100% I went into /var/log and cleaned out some old logs and the problem went away. Try command: "df -k"
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:
# 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.
and then cat-ing the file reveals that it has been populated with the cron header:
# 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.
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?
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.
My preference is not to use that method of editing the crontab. I prefer to save it to a file then edit then upload it again. That way I also have a local copy.
For some reason the combination of vi and the /tmp being linked to /var/www/tmp is what is causing the problem. I have a system that exhibits the same problem, using vi with a linked /tmp directory and the 'crontab -e' command refuses to update my cron entries for any user. I then definied two environment variables:
TMP=/var/www/tmp
TEMP=/var/www/tmp
and exported them, and now 'crontab -e' works fine with vi! Seems that either vi or crontab needs to know where your /tmp folder actually lives, since it does not seem to figure it out from the symbolic link from /tmp to /var/www/tmp.
Also, the command 'crontab -e' really is the best way to update your cron entries since this command actually edits a copy of you cron table (hence the need to define your real /tmp folder), and when you are done editing that copy, cron then parses your edits for syntax problems, and if everything looks fine it places your new crontab in place of the old. If there are any problems, it will let you know and give you a chance to make further edits.
