Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

On various systems that I administer, there are cron scripts that get run via the commonly-used /etc/cron.{hourly,daily,weekly} layout. What I want to know is whether there's any common 'disable this script' functionality.

Obviously, simply deleting something out of a given directory will disable it, but I'm looking for a more permanent solution. Deleting /etc/cron.daily/slocate will work to disable the nightly updatedb on my home machine (where I never use slocate), but next time I upgrade the slocate package, I'm pretty sure it'll reappear.

The two distributions I'm most interested in are Gentoo and OpenSUSE, but I'm hoping there's a widely-implemented mechanism. Both distros as I have them use vixie-cron (not sure it matters).

share|improve this question

6 Answers 6

up vote 20 down vote accepted

You should be able to chmod -x scriptname to disable a script but leave the file in place.

share|improve this answer
Wow. So simple it hurts. Thanks. –  benizi Jun 11 '10 at 15:06

If you don't want the user-crontabs either, just disable crond in your service-list.

In Debian and versions based on Debian this is simply a matter of removing the symlink from the appropriate /etc/rcX.d (for runlevel X).

I don't know how you handle services in SUSE or Gentoo.

share|improve this answer
That's just a bad idea. Disabling cron altogether will disable useful maintenance tasks like logrotate, updatedb, possibly unattended upgrades and standard back-ups. –  Tobu Jun 11 '10 at 12:27
Updatedb is exactly the task I'm trying to disable (updates the db for slocate). Nonetheless, yes, bad advice in general. –  benizi Jun 11 '10 at 15:10
Oh, sorry. I misread your question and thought that you wanted to disable ALL system-specific cronjobs, not a single specific one. –  jishi Jun 14 '10 at 9:36

You can remove slocate package if you never use it.

share|improve this answer
That was just an example, but still good advice, thanks. (I thought something might depend on slocate, but nothing appears to.) –  benizi Jun 11 '10 at 15:09

If you use cfengine (http://www.cfengine.org) you could do this with disable. You just write a promise file for a group of hosts and it will apply itself in the next cfagent run. Doing this with puppet or chef or whatever should also be quite simple.

share|improve this answer
Interesting. I've only encountered configuration management tools very tangentially. I was looking for a general "I have some arbitrary Unix-like system" solution. –  benizi Jun 11 '10 at 15:15

Usually cron.daily is invoked via /etc/crontab through a line like e.g. run-parts --report /etc/cron.daily man run-parts gives you the options. run-parts --test /etc/cron.daily shows which jobs are executed without running them. I prefer to make a subdir 'Disabled' and move my jobs there.

In any case if you update a package it is likely that the job gets into place again or that removed 'x' bits get restored

share|improve this answer

run-parts does not execute jobs which have a dot in their name, so

mv /etc/cron.d/job /etc/cron.d/job.disabled

will do the trick.

share|improve this answer
Unfortunately that will have the same problem when upgrading the program - it will check to see whether the cron job exists, and since it doesn't exist by its original name, it will be recreated. –  Jenny D May 15 '13 at 13:43
Coming back when upgrading the program is a side effect of the package tool in use, can't be fixed via simple means, and isn't the fault of Cron. Some package systems nuke and pave previous files, others diff the new and old, and prompt you if there are changes to review. Regardless, updates that produce unintended behavior should be a frustrating, but routine part of unix systems administration at this point. There are simply too many packages moving too swiftly to regularly review all changes for their impact in each individual environment. –  peelman Mar 26 '14 at 14:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.