how to temporarily disable a user's cronjobs?
Clash Royale CLAN TAG#URR8PPP
up vote
12
down vote
favorite
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
cron
add a comment |Â
up vote
12
down vote
favorite
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
cron
Can't you just use the-u user
switch of thecrontab
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
add a comment |Â
up vote
12
down vote
favorite
up vote
12
down vote
favorite
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
cron
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
cron
cron
edited Mar 6 '15 at 3:14
asked Mar 6 '15 at 0:36
Dinesh
3662515
3662515
Can't you just use the-u user
switch of thecrontab
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
add a comment |Â
Can't you just use the-u user
switch of thecrontab
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
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
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
@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
Dinesh, I (mis-)understood you want a fine-granular control about what you disable.
â Janis
Mar 6 '15 at 1:00
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
8
down vote
accepted
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 thechmod
.
â 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 addedtouch $username
after thechmod
. But that didn't help. (btw got your point oncron.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
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
add a comment |Â
up vote
5
down vote
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).
add a comment |Â
up vote
0
down vote
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:
https://www.debian.org/doc/debian-policy/#cron-job-file-names
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.
add a comment |Â
up vote
-1
down vote
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
New contributor
This will stop the entirecron
service. The OP wanted to be able to choose which users' crontabs to disable.
â roaima
Oct 4 at 10:25
It's also identical to another answer.
â roaima
Oct 4 at 10:25
add a comment |Â
up vote
-1
down vote
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
systemctl stop crond.service
and, to resume
systemctl start crond.service
I presume you need root or wheel authority to execute those; if necessary, run them via sudo or (last resort) log in as root.
Overkill for the specific question posed, but provides "one-stop shopping" and doesn't require playing with the filesystem or temporary files.
2
Since this disables cron for all users, it doesnâÂÂt really answer the question.
â Scott
Nov 30 '17 at 6:34
add a comment |Â
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
accepted
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 thechmod
.
â 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 addedtouch $username
after thechmod
. But that didn't help. (btw got your point oncron.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
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
add a comment |Â
up vote
8
down vote
accepted
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 thechmod
.
â 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 addedtouch $username
after thechmod
. But that didn't help. (btw got your point oncron.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
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
add a comment |Â
up vote
8
down vote
accepted
up vote
8
down vote
accepted
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
.
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
.
edited Aug 25 '15 at 21:40
shrimpwagon
1922410
1922410
answered Mar 6 '15 at 0:55
Gilles
513k12010151547
513k12010151547
Thanks. On my system it is /var/spool/cron/tabs/$username. But it still executes, even after thechmod
.
â 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 addedtouch $username
after thechmod
. But that didn't help. (btw got your point oncron.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
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
add a comment |Â
Thanks. On my system it is /var/spool/cron/tabs/$username. But it still executes, even after thechmod
.
â 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 addedtouch $username
after thechmod
. But that didn't help. (btw got your point oncron.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
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
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
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
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
Mar 7 '15 at 0:17
@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
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
If you want to disable for all standard users just:
chgrp root /var/spool/cron/crontabs
â shrimpwagon
Aug 25 '15 at 22:11
add a comment |Â
up vote
5
down vote
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).
add a comment |Â
up vote
5
down vote
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).
add a comment |Â
up vote
5
down vote
up vote
5
down vote
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).
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).
answered Mar 30 '16 at 9:16
braindigitalis
15913
15913
add a comment |Â
add a comment |Â
up vote
0
down vote
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:
https://www.debian.org/doc/debian-policy/#cron-job-file-names
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.
add a comment |Â
up vote
0
down vote
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:
https://www.debian.org/doc/debian-policy/#cron-job-file-names
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.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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:
https://www.debian.org/doc/debian-policy/#cron-job-file-names
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.
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:
https://www.debian.org/doc/debian-policy/#cron-job-file-names
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.
answered Apr 9 at 17:16
Wadih M.
491212
491212
add a comment |Â
add a comment |Â
up vote
-1
down vote
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
New contributor
This will stop the entirecron
service. The OP wanted to be able to choose which users' crontabs to disable.
â roaima
Oct 4 at 10:25
It's also identical to another answer.
â roaima
Oct 4 at 10:25
add a comment |Â
up vote
-1
down vote
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
New contributor
This will stop the entirecron
service. The OP wanted to be able to choose which users' crontabs to disable.
â roaima
Oct 4 at 10:25
It's also identical to another answer.
â roaima
Oct 4 at 10:25
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
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
New contributor
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
New contributor
edited Oct 4 at 10:07
jimmij
29.5k867101
29.5k867101
New contributor
answered Oct 4 at 9:57
Juergen
1
1
New contributor
New contributor
This will stop the entirecron
service. The OP wanted to be able to choose which users' crontabs to disable.
â roaima
Oct 4 at 10:25
It's also identical to another answer.
â roaima
Oct 4 at 10:25
add a comment |Â
This will stop the entirecron
service. The OP wanted to be able to choose which users' crontabs to disable.
â roaima
Oct 4 at 10:25
It's also identical to another answer.
â roaima
Oct 4 at 10:25
This will stop the entire
cron
service. The OP wanted to be able to choose which users' crontabs to disable.â roaima
Oct 4 at 10:25
This will stop the entire
cron
service. The OP wanted to be able to choose which users' crontabs to disable.â roaima
Oct 4 at 10:25
It's also identical to another answer.
â roaima
Oct 4 at 10:25
It's also identical to another answer.
â roaima
Oct 4 at 10:25
add a comment |Â
up vote
-1
down vote
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
systemctl stop crond.service
and, to resume
systemctl start crond.service
I presume you need root or wheel authority to execute those; if necessary, run them via sudo or (last resort) log in as root.
Overkill for the specific question posed, but provides "one-stop shopping" and doesn't require playing with the filesystem or temporary files.
2
Since this disables cron for all users, it doesnâÂÂt really answer the question.
â Scott
Nov 30 '17 at 6:34
add a comment |Â
up vote
-1
down vote
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
systemctl stop crond.service
and, to resume
systemctl start crond.service
I presume you need root or wheel authority to execute those; if necessary, run them via sudo or (last resort) log in as root.
Overkill for the specific question posed, but provides "one-stop shopping" and doesn't require playing with the filesystem or temporary files.
2
Since this disables cron for all users, it doesnâÂÂt really answer the question.
â Scott
Nov 30 '17 at 6:34
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
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
systemctl stop crond.service
and, to resume
systemctl start crond.service
I presume you need root or wheel authority to execute those; if necessary, run them via sudo or (last resort) log in as root.
Overkill for the specific question posed, but provides "one-stop shopping" and doesn't require playing with the filesystem or temporary files.
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
systemctl stop crond.service
and, to resume
systemctl start crond.service
I presume you need root or wheel authority to execute those; if necessary, run them via sudo or (last resort) log in as root.
Overkill for the specific question posed, but provides "one-stop shopping" and doesn't require playing with the filesystem or temporary files.
edited Oct 4 at 10:26
roaima
40.9k547111
40.9k547111
answered Nov 30 '17 at 5:03
Felix Domestica
11
11
2
Since this disables cron for all users, it doesnâÂÂt really answer the question.
â Scott
Nov 30 '17 at 6:34
add a comment |Â
2
Since this disables cron for all users, it doesnâÂÂt really answer the question.
â Scott
Nov 30 '17 at 6:34
2
2
Since this disables cron for all users, it doesnâÂÂt really answer the question.
â Scott
Nov 30 '17 at 6:34
Since this disables cron for all users, it doesnâÂÂt really answer the question.
â Scott
Nov 30 '17 at 6:34
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f188501%2fhow-to-temporarily-disable-a-users-cronjobs%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Can't you just use the
-u user
switch of thecrontab
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