32

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

Improve this question

8 Answers 8

Reset to default
52

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

Improve this answer
5
  • 7
    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 7, 2016 at 12:04
  • @mc0e thanks for teaching me about immutable files, but as someone once said, they're scary. If I ever forgot what I did, it could lead to some very frustrating trouble.
    – Jonathan Y.
    May 20, 2016 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, 2016 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, 2016 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, 2016 at 2:17
18

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.

Improve this answer
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, 2013 at 13:43
  • 3
    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, 2014 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, 2017 at 0:51
  • this does not work, if the job.disabled is executable, it still runs
    – Wang
    Nov 25, 2022 at 16:36
  • This works perfect. Test with: run-parts --test .
    – Majal
    Feb 19 at 14:15
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

Improve this answer
1

You can remove slocate package if you never use it.

Improve this answer
2
  • That was just an example, but still good advice, thanks. (I thought something might depend on slocate, but nothing appears to.)
    – benizi
    Jun 11, 2010 at 15:09
  • Remove slocate, and install mlocate instead. Much better.
    – mc0e
    Mar 7, 2016 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.

Improve this answer
1
  • 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, 2010 at 15:15
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.

Improve this answer
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.

Improve this answer
-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.

Improve this answer
3
  • 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, 2010 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, 2010 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, 2010 at 9:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .