HP-UX

crontab -e by default uses vi. The point here is avoiding corrupting or deleting content in an important file like /etc/crontab just because you want to look at it. Obviously vi works. crontab -l is safe. view is safe. vi is not a safe tool to piddle around with the /etc/crontab file.

Safe habits include using crontab, not vi.

I agree with Jim, that using -e just to view can be unsafe... I always vi a freshly generated file... or crontab -l|more ...( some of our DBAs used to till they lost their file and realised they had no spare...It so easy to not know what you are doing with people entering in your office and distract you while the phone starts ringing...)

I agree with vbe. I copy the crontab twice (both with and without a date suffix) to backed-up workspace. Edit with vi and then publish the crontab with "crontab <filename>". This means you have a safe copy of the current crontab, and a copy of all previous crontabs. If you want to check your changes you can run "diff".

Hi, a new question about crontab.
I have some machine in cluster to avoid interuption in manufacturing process. When one is alive the other one is sleep.
Some time happens to switch between them. So i stop the crontab in one and start it in other one. The question is how can i ensure that the two cron are the same? I made a shell to check the difference in the two /var/spool/cron/crontabs directory and it work fine. When an alarm arrive i manualy align the user crontab file in the sleeping machine using crontab -e. My boss ask to me to do this action automaticaly. Do u think that is correct to align the crontab using the remote copy of the users crontab file? I'm not sure, for instance if i make the user crontab using the vi the shell doesn't start. For the same reason i prefer align the crontab manualy beaside with a shell that make a rcp. That's is correct or do u think that i could be use the rcp between the /var/spool/cron/crontabs files?

Best Regards,
Andrea.

Ive seen people spend weeks building up a (redoutable...) cron file after it was lost after a crash and needed to reinstall to OS ( for many sites DONT backup /var in root vg (vg00) eg /var/opt here is another file system as is /var/opt/oracle also and are backed up...)
if you had a copy of you cronfile elsewhere (home directory of that cron user or dedicated directory e.g. /sm/cron) you would always use vi to edit/save followed by a crontab cronfile, you could then compare the file with what is in /var/spool and also rdist it to the other box without using crontab -e, starting the alternate box would be to do just the same with the difference of a first crontab cronfile Im sure it could be automated if needed

This is a timely topic for me. I was looking into just such a problem since I have a two node Service Guard cluster, in use. We have an applications volume group active on only one server at a time. Depending upon which server it is active on, the crontab file has extra jobs to run.

So I thought of having a dedicated and separate area for the local crontab file, and one on the application volume group for the crontab file specific to it.

Then a script could be made to merge the local cron job file with the cron file from the application volume group (if it's mounted) and then submit the merged crontab file to cron. This script would run with the startup of the cluster package for the application volume group.

The local crontab file would look something like this

Code:

 
#<header info>
# LOCAL start
<cron job>
<another cron job>
<etc>
# LOCAL end

And the app volume group crontab file

Code:

 
# APP start
<cron job>
<another cron job>
<etc>
# APP end

A script could easily cat those two files, together into a new crontab file keeping the application specific information last in the file. The process can be "reversed" by resubmitting just the local file when the app volume group is switched back to its primary node. If changes were made in the meantime, to the local portion, no problem, as a simple:

Code:

 
crontab -l | sed -n -e '1,/\# LOCAL end/ p' > newlocal.cron

should give me the most current local listing that can be submitted to eliminate the application volume group entries (of course the changes should have been made to a separate file first, and then submitted so I already have a record of them).

I haven't put this together, yet, it's just been rattling around in my brain at this point, but that's the gist of it. Seems so easy, I must be missing something!