How to make crontabs permanent?

[Ron Kinner]

We have some old Linux boxes which run 1.2.1 and 2.2.13. Recently I needed to add a cron entry to crontab. Did the usual crontab -e and added a second line to the existing crontab. Saved the file and exited. Verified that it took with crontab -l. No problem. Everything worked fine for weeks.

Yesterday we rebooted them and the new crontab entry is gone though the old one remains.

How do I make it stick through a reboot?

Ron

[Steven E. Protter · Accepted solution]

crontabs are permanent.

It would appear there is a problem with your system or a start of script puts back the old crontabs.

I would check the cron startup script in /etc/init.d and anything else thats custom.

After making your changes on the file, try changing the permissions on the actual crontab file(deep in /var/spool/cron) to read only.

Then boot and see what happens.

SEP

[Olivier Drouin]

like he said...something looks wrong with your system.
Just a thought: could be cfengine if you use it...

[Paul Cross_1]

Is this happening on multiple machines??
Although I would hope the data was actually written out to the disk after 2 weeks, was it a clean reboot?

[Ron Kinner]

Thanks for confirming that the crontab is supposed to be permanent.

I found the culprit. Stephen, I think you must have meant inittab as there was no init.d. I followed it to rc.M which calls a file which calls a binary and the binary sets the time for the first line of the crontab so I assume they just erase the old and make a new. I have no source code for the binary. Just a little config file that I can edit to set the time and a few other variables. The machine's whole purpose in life is to run the binary so I can't tell it not to run.

I guess I will just put the command in root's crontab which I am sure the binary doesn't mess with. I don't think it matters who runs the script.

Ron
Ron

[Stuart Browne]

The /etc/init.d/ is used by the RH (8+) distributions of Linux.

The reference to 'rc.M' sounds like an old Slackware distribution though.. much fun ;)

In any case, if it's going to thrash your cron jobs every reboot, use one of the other methods.

Depending on the version of 'crond' you're using (vixie cron vxxx, I'm not sure which do and don't support the following, check the man page).

1) Use /etc/crontab . This lives outside of the /var/spool/cron/ structures, and has the ability to launch a given command as a different user (6th field).

2) use /etc/cron.d/ . Once again, outside of /var/spool/cron/, the same format as above (user as 6th column). Usually specifically for a given task.

3) (not dependant on crond version): Just export, add jobs, re-import dynamically.. i.e.:

( crontab -l ; echo "0/5 * * * * /usr/bin/yourjob" ) > /tmp/file; crontab -e < /tmp/file

.. Just some thoughts ..

[Ragu_1]

You were saying about a binary which is doing some change. Ron, can you name that binary ? Can we not manipulate permissions on such critical files and make it stick ? Binary only world is a cruel place anyway.....

[Ron Kinner]

Stuart,

You are correct that it is an old Slackware distribution. Thanks for the script and the explanation for why Stephan thought it should be init.d. If using root's crontab causes a problem or doesn't work then I will try it.

Raqu,

The binary is a proprietary special purpose program only used by my company. Its name is rscmngr and it was written I think by Hughes Software Systems in India. I suppose if we really made a stink they might be able to dig up the source code but the boxes are going to be replaced this year as soon as we get out of Chapter 11 so it's not worth the effort.

Ron