HP-UX

Hi All,

We are working on HP_UNIX.
I am facing a strange problem regarding crontab in our unix environment.Whenever a server reboot takes place on our server the old crontab gets reflected due to which several scripts which were earlier uncommented starts running causing a huge problem .Is there any solution this as to why this is happening and how it can be avoided?


Thanks in advance

you need to become root to do this:

1. who owns the crontab? this is hpux, I do not remember where the actual file lives - I THINK it may be

Code:

/var/spool/cron/crontabs/[username]

Please show the output of:

Code:

# note: use correct directory
find /var/spool/cron/crontabs -exec ls -l {} \;

Exactly: when a server reboots, it reloads what is in /var/spool/cron/crontabs/ You should never leave anything unused in there... It is not to say you should delete without taking any precaution... I create a .save (as root and 750) directory one level above and mv what is unwanted in .save, the same I historize the cron files also in case of corruption or disagreement with production e.g. How come this job never finish when it used to? If you can prove someone changed the schedule, your out of trouble...
This is important to be done when you are going through a upgrade/update process where you risk rebooting a few times during one-two days : MOVE all cron file out or /var/spool/cron/crontabs while in maintenance!

Hi vbe,

Thanks for your reply.
Generally we plan reboot every 3 months ..thats when we get this problem.
Also,can elaborate more on below :

"I create a .save (as root and 750) directory one level above and mv what is unwanted in .save, the same I historize the cron files also in case of corruption or disagreement with production e.g. How come this job never finish when it used to? If you can prove someone changed the schedule, your out of trouble...
This is important to be done when you are going through a upgrade/update process where you risk rebooting a few times during one-two days : MOVE all cron file out or /var/spool/cron/crontabs while in maintenance!"

with example....

I had in older times 2 very bad issues with cron...
Since,I changed my way of doing, see above...I taught my cron users to be safe and not use anymore or at their own risk crontab -e and have a cronfile in their home directory and use -l option, it allows them to before complaining, compare what it is actually in cron v.s. their cronfile if different find out why... the ile itself should have the name of the cronfile and where it is otherwise if I pass and dont find that information I remove...
Now Im going in maintenance, I mv * to .save (no sentimetalism...) and od my job...
When finished, you have 2 options:
a) You put back ( not preferred except for root (but I know why, for root that is...)).

b) you tell your folk, ( you have their names in the cronfiles, see...) they can reload...
They can do it for they are the owners and have their files in $HOME (if they did follow the rules...) or they must know where they have the file...
This is preferable because it forces them to look at they schedule again to see if they were not affect timewise by the maintenance...
Is it important? depending where you work, yes... the unpredictable behaviour can make you loose $$$$$$$$ ...
In the second case you are initialysing your schedule, its from now-- on
In the first case, you are what????

Hi Vbe,

Thanks for quick reply..
In short u mean I should follow below steps :

1) become the root and take backup of crontab file
e.g : I am user "xyz".Now my crontab file is located in /var/spool/crontabs/"xyz".

2) In order to modify this xyz file I should first become root(how to ,I don't know? I guess our server team will be able to help)
Then I should take backup of this crontab file in my $HOME dir ..say xyz2..

3) Then I should modify the original xyz file (say mod_xyz) .So now I have backup of my crontab file in case something goes wrong.

Please correct me wherever I am wrong. Also,which file out of xyz or mod_xyz will be reflected in crontab after server reboot.

Read the man pages of crontab ( 1) then perhaps cron (1M)