How do I temporarily disable one or more users' cron jobs? In particular, I do not want to suspend the user's cron rights - merely not fire any of their jobs.

I am on SLES 11 SP2 and SP3 systems

  • Can't you just use the -u user switch of the crontab command and put a # comment character in front of the jobs to disable for the given user? – Janis Mar 6 '15 at 0:41
  • @Janis then I need to keep track of what the user (there are many) had already commented out, plus the user can go ahead and add another thing in (I am not adding them to /etc/cron.deny). Too much manual work :( – Dinesh Mar 6 '15 at 0:49
  • Dinesh, I (mis-)understood you want a fine-granular control about what you disable. – Janis Mar 6 '15 at 1:00

touch /var/spool/cron/crontabs/$username; chmod 0 /var/spool/cron/crontabs/$username should do the trick. Restore with chmod 600 and touch (you need to change the file's mtime to make cron (attempt to) reload it).

On at least Debian and probably with Vixie cron in general, chmod 400 /var/spool/cron/crontabs/$username also does the trick, because that implementation insists on permissions being exactly 600. However this only lasts until the user runs the crontab command.

If you want a robust way, I don't think there's anything better than temporarily moving their crontab out of the way or changing the permissions, and temporarily adding them to /etc/cron.deny.

  • Thanks. On my system it is /var/spool/cron/tabs/$username. But it still executes, even after the chmod. – Dinesh Mar 6 '15 at 3:19
  • After changing the file perms, I also needed to stop/restart cron. I thought its probably because cron might be holding the stuff in memory. So I added touch $username after the chmod. But that didn't help. (btw got your point on cron.deny) – Dinesh Mar 6 '15 at 3:28
  • @Dinesh Indeed you need to update the file's mtime or else cron thinks it hasn't changed and keeps cached information. I noticed this while testing yesterday but forgot to mention it in my answer, sorry about that. – Gilles 'SO- stop being evil' Mar 7 '15 at 0:17
  • If you want to disable for all standard users just: chgrp root /var/spool/cron/crontabs – shrimpwagon Aug 25 '15 at 22:11

How about something like this to disable a user crontab:

crontab -l -u [username] >/tmp/[username].cron.tmp
crontab -r -u [username]

and to re-enable:

crontab -u [username] /tmp/[username].cron.tmp

This has the added advantage that you can run it as that user without needing root (just take the -u parameter away).


If you just want to stop all cron jobs entirely for a while -- for example, while doing system maintenance which they might interact badly with -- the commands are normally as follows:

sudo systemctl stop crond.service

and, to resume

sudo systemctl start crond.service

Note however that some systems use cron.service instead of crond.service; you can learn which it is as follows:

$ systemctl list-units --type=service | grep cron

Overkill for the specific question posed, but provides "one-stop shopping" and doesn't require playing with the filesystem or temporary files. Also for small embedded systems (Raspberry Pi, Beagle Bone, etc etc, etc) with a single user account.

  • 4
    Since this disables cron for all users, it doesn’t really answer the question. – Scott Nov 30 '17 at 6:34
  • @Scott: The OP's question states, "one or more users". This method can be quite useful on small-ish embedded systems. IMHO it doesn't deserve a downvote. – Seamus May 6 at 16:15

You can use the following like so:


crondisable some_other_user

The zsh code (put in your .zshrc):

ecerr () {
print -r -- "$@" >&2
crondisable() {
        local user="${1:-$(whoami)}"
        local cronpath="/tmp/$user.cron.tmp"
        test -e "$cronpath" && {
        ecerr "There is already a disabled crontab at $cronpath. Remove that manually if you want to proceed."
        return 1
        crontab -l -u $user > "$cronpath"
        crontab -r -u $user
cronenable() {
        local user="${1:-$(whoami)}"
        local cronpath="/tmp/$user.cron.tmp"
        test -e "$cronpath" || {
        ecerr "No disabled cron at $cronpath"
        return 1
        crontab -u $user "$cronpath"
        mv "$cronpath" "${cronpath}.bak"

If you're using Debian, this only applies to Debian AFAIK:

You can do so by adding a dot to the name of the cronjob.

Behavior is referred to on the Debian official docs:


A cron job file name must not include any period or plus characters (. or +) characters as this will cause cron to ignore the file. Underscores (_) should be used instead of . and + characters.

  • Perhaps I'm missing a fine point here, but on my Debian derivative (Raspberry Pi), cron will run jobs with a . in the filename; e.g. @reboot /home/pi/setalarm.sh. – Seamus May 6 at 16:07
  • @Seamus the answer refers to the files under the system directories /etc/cron*, not to the jobs themselves. (Not necessarily terribly obvious, mind.) – roaima May 6 at 17:28
  • @roaima: Do you mean, for example /etc/cron.hourly, /etc/cron.daily, etc? – Seamus May 6 at 19:15
  • @Seamus yes, files in those directories exactly – roaima May 6 at 19:21
  • @roaima: Why would user's cronjobs go in those directories instead of /var/spool/cron/crontabs... would this also apply to (for example) /var/spool/cron/crontabs/seamus such that I could disable my crontab by renaming it as /var/spool/cron/crontabs/seamus.donothing? Sorry - I know this isn't your answer & probably off-topic, but I'm still curious :) – Seamus May 6 at 19:45

I agree, the path via systemctl is the one to take. On raspberry, toe comands would be

sudo systemctl stop cron.service
sudo systemctl start cron.service
  • 3
    This will stop the entire cron service. The OP wanted to be able to choose which users' crontabs to disable. – roaima Oct 4 '18 at 10:25
  • @roaima: Your comment is correct of course, but I imagine that some people wind up here after using a search term such as linux suspend cron job temporarily, and some of those that do may find this answer (and the one above) quite useful. I wonder if the question how to temporarily disable all user's cronjobs? would be classified as a duplicate? – Seamus May 6 at 21:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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