Bug 220376

Summary:	New /etc/cron.d files not being discovered
Product:	Red Hat Enterprise Linux 4	Reporter:	Matt Shields <mshields>
Component:	crontabs	Assignee:	Marcela Mašláňová <mmaslano>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.4
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-07-31 13:56:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Matt Shields 2006-12-20 19:42:07 UTC

Description of problem:
When I create a new cron (using vi) in /etc/cron.d the cron does not get picked
up.  If I wait for a couple edit the file again, then save it, it will finally
get picked up.

Version-Release number of selected component (if applicable):
Have tried this on RHEL 3.6, 4, 4.2, 4.3, 4.4

How reproducible:
see description above

Steps to Reproduce:
1. create new cron in /etc/cron.d/ with vi
2. watch the /var/log/cron file, it won't get "reloaded"
3. edit the file again and save it
4. the new file will finally get "reloaded"
  
Actual results:


Expected results:
new cron should get picked up when first created.

Additional info:

Comment 1 Matt Shields 2006-12-20 19:42:46 UTC

Another way I've been able to solve the problem is wait at least 1 minute then
run 'touch /etc/cron.d'

Comment 2 Marcela Mašláňová 2007-01-03 10:51:14 UTC

If you don't like crontab -e, then I recommend work around:
vi /var/spool/cron/root 
I try reproduce and jobs from cron.d didn't work for me at all. 
I'll look at it.

Comment 3 Matt Shields 2007-01-03 13:27:03 UTC

crontab -e is for when you want specific users to have crons.  We (as well as
most people) prefer to keep system crons in the /etc/cron* directories.

(In reply to comment #2)
> If you don't like crontab -e, then I recommend work around:
> vi /var/spool/cron/root 
> I try reproduce and jobs from cron.d didn't work for me at all. 
> I'll look at it.

Comment 4 Matt Shields 2007-01-03 13:28:36 UTC

I shouldn't have to wait, go back, touch it.  What happens if (like most of my
day) I'm extremely busy and forget to go back and touch the file.  A very
important task may not run.  I shouldn't have to worry whether crond picked up
the changes, it should just work.

(In reply to comment #1)
> Another way I've been able to solve the problem is wait at least 1 minute then
> run 'touch /etc/cron.d'

Comment 5 Marcela Mašláňová 2007-03-28 16:39:12 UTC

Can't reproduce bug. Jobs in /etc/cron.d/ are loaded imediatelly, but jobs
aren't run. Do you have some options? 
I have:
rpm -q vixie-cron anacron crontabs
vixie-cron-4.1-20_EL
anacron-2.3-32
crontabs-1.10-7

Which versions do you have?

Comment 6 Matt Shields 2007-03-28 16:45:36 UTC

Here's what I'm running

rpm -q vixie-cron anacron crontabs
vixie-cron-4.1-44.EL4
anacron-2.3-32
crontabs-1.10-7

Comment 7 Marcela Mašláňová 2007-04-05 07:58:32 UTC

I fix it for devel. If I'll fix it for RHEL-4, would you mind test it for me?

Comment 8 Marcela Mašláňová 2007-04-12 16:41:47 UTC

I was investigating about this problem. My jobs won't run, if I forget to type
in /etc/crontab or /etc/cron.d/* username. The cron isn't complainig, that's the
only problem, which I can avoid.

Comment 9 Marcela Mašláňová 2007-07-31 13:56:57 UTC

I'm closing this bug for long inactivity. If the problem still persist please
reopen this bug.