30

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).

benizi
  • 452
  • 1
  • 5
  • 7

8 Answers8

51

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

Dennis Williamson
  • 62,149
  • 16
  • 116
  • 151
  • 6
    That might or might not get undone by the package management system. You could make this more robust by doing `chattr +i scriptname` after the `chmod`. – mc0e Mar 07 '16 at 12:04
  • @mc0e thanks for teaching me about immutable files, but [as someone once said](https://bbs.archlinux.org/viewtopic.php?pid=318898#p318898), they're *scary*. If I ever forgot what I did, it could lead to some very frustrating trouble. – Jonathan Y. May 20 '16 at 12:48
  • 2
    @JonathanY.: That's what `lsattr` is for - to remove the _scary_ (it lists the atteibutes of a file). – Dennis Williamson May 20 '16 at 15:58
  • 1
    DW sure, but knowing to look at file attributes when something goes inexplicably wrong (just like in that thread I linked to) is the real kick here. – Jonathan Y. May 20 '16 at 16:45
  • @JonathanY. So now you do know. :-) In any case, I think the 'scary' bit in that linked thread refers to a pacman bug, not chattr itself – mc0e May 23 '16 at 02:17
16

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.

chrisv
  • 287
  • 2
  • 5
  • 1
    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
  • 2
    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
  • In Debian, there’s a notion of a _file diversion_ — i. e. you’re able to effectively rename the file while it’s still managed by the package manager. Maybe a similar mechanism exists in Gentoo and/or SUSE? – Bass Dec 15 '17 at 00:51
  • this does not work, if the job.disabled is executable, it still runs – Wang Nov 25 '22 at 16:36
12

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

Simon East
  • 1,514
  • 1
  • 15
  • 18
Peter
  • 121
  • 1
  • 2
1

You can remove slocate package if you never use it.

Maxfer
  • 193
  • 10
  • 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
  • Remove slocate, and install mlocate instead. Much better. – mc0e Mar 07 '16 at 12:00
1

If you use cfengine (https://cfengine.com/) 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.

Bass
  • 103
  • 4
natxo asenjo
  • 5,739
  • 2
  • 26
  • 27
  • 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
1

The /etc/cron.daily et. al. scripts are run by a script called run-parts. That script varies. For example the --test switch mentioned above isn't on the machine I'm using at this instant.

Run-parts is a bash script. It a generally useful tool for running all the scripts in the directory it's given as an argument. It usually found at /usr/bin/run-parts.

It has a tangle of logic for deciding what to run. That code holds the answer to your question, but it varies too. So you need to read the code to be safe.

In the version I'm looking at it has logic that, when working on directory <foo>, checks for <foo>/jobs.deny. If that exists it declines to run any script that is mentioned in that file on a line, alone. Assuming you have this functionality it's awesome because it will keep working when the package that installs is installed or upgraded.

Ben Hyde
  • 111
  • 3
1

If dealing with RHEL and derivates (which provides the crontabs package), you can explicitly disable a job by putting its name into the jobs.deny file.

From crontabs / run-parts man page:

The execution of files can be allowed or denied by creating file jobs.allow or jobs.deny which worked similar as other allow/deny config files. The file must be created in the specified directory.

Example /etc/cron.daily/jobs.deny could contain for example 0logwatch which forbid execution of this script.

shodanshok
  • 47,711
  • 7
  • 111
  • 180
-1

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.

jishi
  • 868
  • 2
  • 11
  • 25
  • 4
    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 09:36