crontab -e not working

[michaelwild]

SCO 5.04
Thanks to KarverR & trunix for their responses to my cron problem. Tried crontab -e to properly edit the cron. Got this message: could not exec the editor: no such file or directory (error 2).

I did use the hash mark to comment out the cron giving problems. Trunix said I need to restart the cron daemon if I use vi to edit the cron. I have taken the system to single user mode and back to multi-user mode since editing the cron. Does this restart the cron daemon?

So: why is crontab -e not working and how do you restart the cron daemon?

 

[marktee]

Try this:
Copy your crontab to another file, like 'usercron'.
Then, edit 'usercron'. When you're done, login as the user and run 'crontab usercron'. I do this in /usr/spool/cron/crontabs. That way, I never directly edit the crontab files. Crontab also does some limited syntax checking. Also, I've never had to stop and start my cron - the new crontab file kicks right in.

As for the failure of crontab -e, sounds like your EDITOR environment variable is set to a non-existent editor.

Hope this helps,
Mark.

 

[pcunix]

As marktee suggests, you shouldn't use crontab -e anyway, but if you foolisj\hly insist upon doing so, do

EDITOR=/pathto/yourfavorite/editor
export EDITOR

first.

The safe way is to do this:

crontab -l > mycrontab
# call "mycrontab" whatever you want
vi mycrontab
crontab mycrontab
# this writes the crontab and restarts cron


DON'T DO THIS IN THE CRONTABS DIRECTORY. Keep "mycrontab" elsewhere.


If you are root, you can do other users this way:

crontab -u sys -l syscrontab
vi syscrontab
crontab -u sys syscrontab


See

http://pcunix.com/Unixart/cron.html

also

Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com

 

[Guest_imported]

Ok, my problem is that I get this mail every day: cronsched: No response from server errno=2, t_error=0. Based on the time the cron tries to run I identified the line in the cron for root that causes the problem:
3 3 *** /usr/lib/cleantmp > /dev/null. I had hashed it out but from what I learned from your responses I did not do it correctly.

The responses seem to be telling me to create a copy of /usr/spool/cron/crontabs/root in another directory (using another user name), edit that copy to hash out the offending line and then run crontab. Okay, that would create a copy of the cron for root that doesn't run the offending line of the cron. But the cron for root still runs & I would still get the error message, right?

What about the original problem? What is wrong with the line from the cron I listed above? The executable file cleantmp does exist in /usr/lib. Why the error message "no response from server"? I assume (I know, never assume nothing) that cleantmp empties temporary files.

Thanks for your responses. I am new to UNIX and this site has been very helpful.

 

[pcunix]

I doubt that it is cleantmp. "cronsched" is in your crontab, and it is that which is complaining, not cron itself. If it isn't in root's crontab, it's in sys.

See

http://pcunix.com/SCOFAQ/scotec2.html#cronsched

and

http://stage.caldera.com/cgi-bin/ssl_reference?102995

Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com

 

[trunix]

Have you tried running your /usr/lib/cleantmp script from the command line ?

Does this run ok without errors ?

We need to determine if your problem is with cron or with your script.

Is your script accessing other servers ? If so, the error may be because the other server is unavailable at the time your cron is running.

Rather than send output to /dev/null try sending to a log file. This may provide useful information.

 

[marktee]

You may want to enable cron logging by changing CRONLOG= to YES in /etc/default/cron. This will create a file named log in /usr/lib/cron that may give you some clues.

Regards,
Mark.

 

[Guest_imported]

There are 2 cronsched entries in the root cron. I will comment them out and see what happens.

 

[pcunix]

What will hapen is that you won't get that error anymore

However, keep in mind that you did this if you ever do want to use the calendar facility..

Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com

 

[pcunix]

In re-reading what you wrote before, I think you may be confused about something. You wrote:

"The responses seem to be telling me to create a copy of /usr/spool/cron/crontabs/root in another directory (using another user name), edit that copy to hash out the offending line and then run crontab. Okay, that would create a copy of the cron for root that doesn't run the offending line of the cron. But the cron for root still runs & I would still get the error message, right?"

No. If you (as root) do

crontab -l > /tmp/mycrontab
vi /tmp/mycrontab # change stuff
crontab /tmp/myrontab

then root's crontab is REPLACED by whatever you had in /tmp/mycrontab.


Likewise (still as root)

crontab -u sys -l > /tmp/mycrontab
vi /tmp/mycrontab # change stuff
crontab -u sys /tmp/myrontab

replaces the "sys" crontab.


Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com

 

[Guest_imported]

Ok. No more daily mail from cronsched. But I do have a few questions then I'll end this discussion.

What is cronsched? I tried man cronsched and no luck.
Here are the lines from the cron for root:
#0 0 * * 1-5 scosh cronsched -r
#0 0 * * 1 scosh cronsched -wr

What were these commands supposed to do?
They run at midnight, one Mon-Fri, the other Monday only. Why is the mail with the no response from server timestamped around 3:00 a.m.? That's what led me to suspect the cleantmp cron as the problem.

Why all the caution about editing crons in crontab? Fear of corrupting the whole directory? I did make a copy of root called root.save but it is in the usr/spool/cron/crontab directory so I guess if the directory got messed up I would have a problem (I also have a printout of root's cron). The user crons there are mostly the defaults supplied by SCO and are commented out. Root's cron is fairly simple.

Thanks pcunix for all your very professional (though brief) tips, directions and help. Most especially the links. I will do a better job of searching FAQ's next time.

 

[pcunix]

Cronsched is related to calendar scheduling:

http://pcunix.com/SCOFAQ/scotec2.html#cronsched

Sorry I'm so laconic Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com