/etc/cron.d confusion - avoiding manual restart of the crond

graysky · 2010-01-29 01:30:35

It seems that I must restart crond any time I make a change to a file under /etc/cron.d which is very inconvenient. Is there a way to modify the behavior of the daemon to automatically look under that dir for something without manually restarting the daemon?

perbh · 2010-01-29 02:56:40

bash $ man crond
...
crond  is  responsible for scanning the crontab files and running their
commands at the appropriate time.   The  crontab  program  communicates
with  crond  through  the  "cron.update" file which resides in crontabs
directory, usually /var/spool/cron/crontabs.  This is  accomplished  by
appending  the  filename  of  the  modified  or deleted crontab file to
"cron.update" which crond then picks up to resynchronize or remove  its
internal representation of the file.
...

As always - 'man' is your friend

Last edited by perbh (2010-01-29 02:58:28)

graysky · 2010-01-29 08:48:40

Thank you. So if I'm understanding this, I need to place a line in my root user's crontab that reads something like?

* * * * * ID=cron.d /usr/sbin/run-cron /etc/cron.d

Last edited by graysky (2010-01-29 20:16:35)

Profjim · 2010-01-29 10:34:01

No, crond will automatically detect crontabs in /etc/cron.d, and run them as root crontabs. It scans that directory once an hour, so it won't see updates immediately.

Note that /etc/cron.d holds crontabs, and /etc/cron.daily and so on hold scripts. run-cron is for running all the scripts in a directory. If you try it on a directory of crontabs, it won't be happy.

If what you're trying to accomplish is to install more scripts to get run every day or week or whatever, just put those scripts into /etc/cron.daily or /etc/cron.weekly. If they're executable (chmod +x) they'll be run the next time the other scripts in that directory are run.

Last edited by Profjim (2010-01-29 10:35:50)

graysky · 2010-01-29 20:18:13

Thanks for the explanation, Profjum. Guess my next question is how I can modify the behavior of crond so that it scans /etc/cron.d more frequently?

Profjim · 2010-01-29 21:06:02

There's no interface for that, you'd have to patch the source and recompile. I can tell you where if you really want to know. But I bet there's an easier way to do what you want. What are you putting into /etc/cron.d? Crontabs, not scripts, right? (Scripts don't belong there.) If crontabs, why are you putting them into /etc/cron.d rather than putting them into a user's crontab (perhaps root's crontab)? There are legitimate reasons for doing what you're describing, but I want to be sure you're clear about the alternatives. The most natural use-case for an /etc/cron.d/ crontab is for use by packaging system.

Actually, I mispoke. Perhaps there is a way to do what you want. Try this as root, instead of copying the crontab file into the /etc/cron.d directory by hand:

# crontab -c /etc/cron.d crontab_file_you_want_installed

That may write a cron.update file in /etc/cron.d, which crond will read within one minute. In fact I forget right now whether that will work, but no harm will come if it doesn't.

EDIT: more cautiously, back up the contents of /etc/cron.d and the crontab_file_you_want_installed before doing this.

EDIT2: Just rechecked the source. Here's what I think will happen. Part of my thought was right, you can make crond see files in /etc/cron.d more quickly by having a cron.update file there. The format of the cron.update file is a list of files you want crond to notice, separated by newlines. Now, it's tedious to create this file yourself, so you can piggyback on the fact that crontab creates these files automatically for you. However, crontab isn't really designed to work with non-user crontabs. It can be coaxed into doing it, in a clumsy way, with the -c switch, as I describe above. The limitation is that (I think), no matter what filename you supply to crontab, it will save it as a crontab named "root" and that's what it will write to the cron.update file.

Now you can work around that in two ways:
1. Forget about crontab, just copy the file to /etc/cron.d yourself, and append the name of the file you just wrote to /etc/cron.d/cron.update (which may not yet exist).
2. Or use crontab as I described above, and after crond reads and deletes the cron.update file, you can rename the file "root" to whatever you want. Then when crond rescans the directory each hour, it will see that the old "root" file is gone and it will read the newly-named file instead. Actually, this is so complicated I can't imagine why one would prefer to do it rather than #1.

I can't test any of this at the moment, but that's how I expect it to work.

Last edited by Profjim (2010-01-29 21:22:41)

Arch Linux

#1 2010-01-29 01:30:35

/etc/cron.d confusion - avoiding manual restart of the crond

#2 2010-01-29 02:56:40

Re: /etc/cron.d confusion - avoiding manual restart of the crond

#3 2010-01-29 08:48:40

Re: /etc/cron.d confusion - avoiding manual restart of the crond

#4 2010-01-29 10:34:01

Re: /etc/cron.d confusion - avoiding manual restart of the crond

#5 2010-01-29 20:18:13

Re: /etc/cron.d confusion - avoiding manual restart of the crond

#6 2010-01-29 21:06:02

Re: /etc/cron.d confusion - avoiding manual restart of the crond

Board footer