Editing crontab files the wrong way...

[Denise_22]

Hi Gents and Gals,

I believe I goofed when I tried to edit the crontab files. I edited the files directly with vi...and when poking around this site and executing a search on 'edit crontabs' I came across some interesting topics, one which states that a user should do this:

crontab -l > cron.file
vi cron.file
(make the changes you want)
crontab cron.file

I have a question, since I edited the crontab file directly (as sudo root), and want to undo my changes, do I just vi to the crontab file and remove what changes I made?

Another question, the procedure I have indicated above, this simply takes the crontab file contents, and puts in another file (or renames it), and makes the necessary changes, and makes this recently renamed file the crontab file. What is wrong with editing the ctonrab file directly, if you make a coly of the file and append .old to the file?

Should I just try to use crontab -e?

Please mention if I should remove the edits I made to the file via vi directly.

By the way, I was going to set up the system to reboot on a weekly basis, and this never happened and I believe it is because I did not edit the crontab file correctly, even though I set up the parameters right.

Thanks for your help.

[James R. Ferguson · Accepted solution]

Hi Denise:

I never use 'crontab -e'. Instead I use the sequence you described:

# crontab -l > mycrontab
# vi mycrontab
# crontab mycrontab

The rationale for *not* editing directly (with '-e' is that if I bungle the edit and exit 'vi' the copy (overwrite) of the crontab entry occurs anyway -- not very desirable.

Regards!

...JRF...

[Denise_22]

JRF,

Thanks. Ok...now do I need to vi the crontab file directly and remove what I put in the crontab. That is...undo my errors?

I figured I would just use the procedure I indicated in the post, but would my original edit show up?

Also, the server never rebooted after I edited the crontab file directoyl. Do you think that it is because of the wrong way I edited the crontab file?

Thanks.

[Pete Randall]

Denise,

You're choices for undoing what you've done are:

1) vi it and undo, as you said.

2) restore from backup.


Pete

[Elena Leontieva]

Hi Denise,

In my HP student workbook (HP-UX System Administration I) it says that " files in /var/spool/cron/crontabs should never be edited directly or removed because doing so can leave the cron daemon in an idefined state" (??)

I guess you need kill and restart the cron daemon with these two commands:

/sbin/init.d/cron stop
/sbin/init.d/cron start

and resubmit your jobs correctly.

Elena.

[Elena Leontieva]

Sorry for typo: "undefined state"

[Mark Greene_1]

If you are sure of your editing skills, you can use crontab -e to undo the changes. This will also reload the files to the cron daemon so you will be actually scheduled for what's in the file.

Alternatively, you can do the crontab -l > file routine and use *view* to edit. View has the inherant benefit of being explicitly read-only. This means you have to do wq! to commit any changes before exiting the editor.

mark

[Michael Steele_2]

Your EDITOR environment variable will determine how crontab -e works.

echo $EDITOR

Chances are its the default value, vi.

Which is what you're using, right?

The only difference that I'm aware of with crontab is the use of csh instead of POSIX or korn.

[Denise_22]

I will vi the crontab file and edit it directly. And start stop the daemon, just to be sure its running. I will then edit my crontab file using this method:

crontab -l > cron.file
vi cron.file
crontab cron.file

I just hope when I edit the file directly via vi, it does not screw anything up or make it worse, which is why I inquired.

Thank you folks!

[doug mielke]

Editing the cron files directly can cause problems, like multiple cron processes running, or none at all. Otherwise, there is likely little perminant damage done by your procedure.

I'd use the procedures listed above to stop cron, look for any other cron processes. assuming none, recreate the cron file, put it back, as described, then start cron.

Put a test job in as well, that runs soon after you anticapate being finished.

10 * * * * * mailx me@.com < testfile

make sure you get the mail, and only one of them.

[doug mielke]

...darn,
" make sure you get only one mail" when my example will give you one every hour forever.
sorry :(

[A. Clay Stephenson]

After editing, you DO NOT NEED OR WANT to stop cron. If you insist upon editing directly then you must tell the cron daemon that the file has changed. Do a ps -e grep "cron" and note the PID of the cron daemon and then issue a kill -1 pid (or if you prefer a kill -s HUP pid) to send a HANGUP signal to the cron daemon. Cron will then fire off a signal handler to reread the file. This is done automatically by crontab after checking for syntax errors. That's why it's always best to use crontab but since you have already done gone and edited the file directly all you really need is a kill -1 and, assuming your little fingers didn't make no mistakes, you are done.

[doug mielke]

I certainly defer to Clay, and I'm wondering...

Clay, Are there any risks to stopping and starting cron from init.d? ( I suppose we could prevent a job from running if it's scheduled time passes while we're moving files around)

Any others?

[Darren Prior]

Hi,

Just a couple of points from your original question.

1) If you append .old to a copy of the crontab file it may cause problems. Any files in that directory are assumed to be valid crontab files named after a specific user, hence I believe cron will try to run the .old file and will look through /etc/passwd to find the owner (which It will never find.) This will cause complications if you ever try to trust the system for example.

2) You don't need to remove the edits you made directly to a file if you've already resubmitted using crontab as that will have overwritten the original user's crontab.

regards,

Darren

[Denise_22]

I made the changes by doing this:

cd /var/spool/cron

crontab -l>cronfile
vi cronfile (then saved with wq!)
crontab cronfile

Then I got this line showing up

"commands will be executed using /usr/bin/sh"

What does the previous line mean?

Also, since one poster said that if you names the file .old then it will be read when cron executes. Well, I now have the file 'cronfile' listed in /var/spool/cron, should I then remove the cronfile now or leave it there? I don't think this should be in /var/spool/cron.

Thanks.

[John Poff]

Hi,

The line about commands being executed by /usr/bin/sh means that your cron jobs will be running under the POSIX shell. If you wrote and tested your scripts using another shell [Korn, csh, etc.] you might need to try them again using the POSIX shell. This is just a reminder message.

As for the file in /var/spool/cron, it should be ok. The cron daemon looks for the files in /var/spool/cron/crontabs.

JP