LinuxQuestions.org - [SOLVED] Cron files in /etc/cron.d/ not running

- Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)

- - Cron files in /etc/cron.d/ not running - CentOS 6.5 (https://www.linuxquestions.org/questions/linux-server-73/cron-files-in-etc-cron-d-not-running-centos-6-5-a-4175510693/)

Cron files in /etc/cron.d/ not running - CentOS 6.5

TL/DR: In order for Cron to pick up that there is a new file in /etc/cron.d/* that needs to be loaded into cron, the timestamp on the file needs to be "recent". 'touch'ing a file in /etc/cron.d/ will force cron to reload the crontab.

Long story:

I've recently begun retrofitting my existing system management bash scripts into RPM packages. To allow for easy updating/pushing via Spacewalk. Some of the RPM packages I'm building involve a crontab, which I've placed in /etc/cron.d/.

The Problem:

The cron files placed in /etc/cron.d/$scriptname_cron were not being loaded into crond. You could watch the cron log file /var/log/cron and cron would never "reload" the crontab including the new file.

The Reason:

The reason why this occurred was because the timestamp on the file in /etc/cron.d matched when the RPM was built, which may have been months beforehand. Therefore crond ignored the file.

The Fix:

I added the following to the SPEC file:

Code:

%post

touch /etc/cron.d/$FILE_NAME

#where $FILE_NAME is the File Name in /etc/cron.d.

Alternatively, touching the file after installing would fix this as well.

I've seen multiple postings online (EXAMPLE) about this (or a very similar situation) so I wanted to put this out there to hopefully help the next guy running into this.

Relevant XKCD

Thanks,

nice heads up. thank you.

Sooooo... Initial testing showed that the %post section works.

Extended testing revealed that it is not working perfectly. Will update once I've got it figured out.

[edit]It has something to do with the inotify support built into Cron now. I'm still investigating, I'll edit the main post once I figure it out. [/edit]

[edit_again] Still working on this. Cron "should" be picking up and loading the new crontab file placed into /etc/cron.d "automagically" but it doesn't appear to be doing so. [/edit_again]

For whatever reason, I can't edit my original post.

Quote:

Originally Posted by mcresist (Post 5201741)

Code:

%post

touch /etc/cron.d/$FILE_NAME

#where $FILE_NAME is the File Name in /etc/cron.d.

Alternatively, touching the file after installing would fix this as well.

After much troubleshooting, here's what ACTUALLY SOLVED THE ISSUE:

The "Real" Reason:

1) Cron.d will ignore files in /etc/cron.d/ that have a "." in the name
2) Cron.d is not able to read files that do not have a Line Return at the end of the cron line

Example:

This one didn't work:

Code:

[root@server ~]# cat tester_cron_bad

* * * * * root /root/scripts/bin/tester.sh[root@server ~]#

Notice the shell prompt immediately following the cron line.

This one did work:

Code:

[root@server ~]# cat tester_cron_good

* * * * * root /root/scripts/bin/tester.sh

[root@server ~]#

Touching the file (as I described originally) doesn't solve the issue.

Hope this helps somebody.

In my case (CentOS 6), I have to restart the crond service, for it being aware of file changes.

service crond restart

Or use the crontab tool, as that is what it is for.

It sends a signal to crond to reread the files. I don't know which signal it is though - might be HUP (signal 1) as that is what other services use.

The reason you had to restart crond is that crond reads the files at boot, sorts all the entries into a list separated by a delta time. This minimizes the overhead (it used to wake up every minute and reprocess - but that adds up to a lot of time).

The other advantage of using crontab is that you can keep a copy of the crontab, update it however you like; THEN use the crontab to tell the system what you want (I use "crontab <file" to do that).

The advantage this has is that if the root system has to be replaced (such as disk failures, or major system updates/replacements...) the crontab entries can be lost. This preserves them for the user and is under the users control.

The carriage return is needed

I found, in the HARD way, that the carriage return or an # is required as stated in the docs:

Quote:

The ``sixth'' field (the rest of the line) specifies the command to be
run. The entire command portion of the line, up to a newline or % char-
acter, will be executed by /bin/sh or by the shell specified in the SHELL
variable of the cronfile.

https://www.freebsd.org/cgi/man.cgi?crontab(5)

One of the best ways to learn.

I bet you won't forget that one.