Bug 220376 - New /etc/cron.d files not being discovered
Summary: New /etc/cron.d files not being discovered
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: crontabs
Version: 4.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Marcela Mašláňová
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-12-20 19:42 UTC by Matt Shields
Modified: 2007-11-17 01:14 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-07-31 13:56:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.