LinuxQuestions.org
Visit Jeremy's Blog.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices


Reply
  Search this Thread
Old 07-10-2014, 09:43 AM   #1
mcresist
LQ Newbie
 
Registered: Jun 2014
Location: Michigian
Distribution: CentOS5/6/7
Posts: 19

Rep: Reputation: 3
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,
 
Old 07-10-2014, 04:44 PM   #2
lleb
Senior Member
 
Registered: Dec 2005
Location: Florida
Distribution: CentOS/Fedora/Pop!_OS
Posts: 2,983

Rep: Reputation: 551Reputation: 551Reputation: 551Reputation: 551Reputation: 551Reputation: 551
nice heads up. thank you.
 
Old 07-11-2014, 10:00 AM   #3
mcresist
LQ Newbie
 
Registered: Jun 2014
Location: Michigian
Distribution: CentOS5/6/7
Posts: 19

Original Poster
Rep: Reputation: 3
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]

Last edited by mcresist; 07-22-2014 at 09:06 PM.
 
Old 07-30-2014, 09:29 AM   #4
mcresist
LQ Newbie
 
Registered: Jun 2014
Location: Michigian
Distribution: CentOS5/6/7
Posts: 19

Original Poster
Rep: Reputation: 3
For whatever reason, I can't edit my original post.

Quote:
Originally Posted by mcresist View Post
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.
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.
 
Old 09-08-2016, 05:09 AM   #5
David Pérez
LQ Newbie
 
Registered: Sep 2016
Posts: 1

Rep: Reputation: Disabled
Restart service

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

service crond restart
 
Old 09-08-2016, 08:21 AM   #6
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,912

Rep: Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513
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.
 
Old 07-05-2017, 08:45 AM   #7
zioalex
LQ Newbie
 
Registered: Jul 2013
Posts: 2

Rep: Reputation: Disabled
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)
 
Old 07-05-2017, 08:50 AM   #8
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,912

Rep: Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513
One of the best ways to learn.

I bet you won't forget that one.
 
  


Reply

Tags
crond



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] [cron] Root cron ib centos 6.3 doesn't work/ killout Linux - Newbie 2 12-17-2012 01:26 PM
Strange Cron directories: /var/spool/cron/cron.GfqqGO Woodsman Slackware 4 05-11-2011 02:37 PM
cron - how to give priority to a task running in cron.daily? MeeLee Linux - Newbie 3 11-09-2010 08:41 AM
adding a perl script to cron.daily / cron.d to setup a cron job CrontabNewBIE Linux - Software 6 01-14-2008 08:16 AM
cron not working from crontab nor form /etc/cron/cron.d. What did SuSE change? JZL240I-U SUSE / openSUSE 11 01-04-2007 01:57 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Server

All times are GMT -5. The time now is 03:40 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration