Bug 235998

Summary: crontab -l doesn't work
Product: [Fedora] Fedora Reporter: Jonathan Kamens <jik>
Component: vixie-cronAssignee: Marcela Mašláňová <mmaslano>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
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-04-12 16:49:34 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 Jonathan Kamens 2007-04-11 12:48:37 UTC 
After installing vixie-cron-4.1-80.fc7, "crontab -l" or "sudo crontab -l" or
"sudo crontab -l -u $LOGNAME" claim that there no crontab (for me, root and me,
respectively).  There are, in fact, crontab files, and crond is merrily running
the commands in them.

I have selinux disabled; I don't know whether this is relevant.
Comment 1 Jonathan Kamens 2007-04-11 12:52:28 UTC 
Copying the crontab files out of /var/spool/cron and running "crontab <file>" on
them fixes the problem -- after doing that, crontab -l can see them.
Comment 2 Jonathan Kamens 2007-04-12 01:10:25 UTC 
After doing the step described above, I've got two crontab files, one 
in /etc/cron.d and one in /var/spool/cron, and both are active, which means 
that my jobs are being run twice.  Something definitely needs to be done about 
this.
Comment 3 Jonathan Kamens 2007-04-12 01:17:00 UTC 
The man page doesn't mention /etc/cron.d at all.  And, as noted in another bug 
report, there are files in /etc/cron.d installed by packages like spamassassin, 
so it doesn't make sense that crontab is putting files in this folder.

There's something here that definitely isn't quite ready for prime time.
Comment 4 Marcela Mašláňová 2007-04-12 16:49:34 UTC 
Fixed in vixie-cron-4.1-82.fc7
Comment 5 Jonathan Kamens 2007-04-12 16:51:13 UTC 
How was it fixed?  Putting the files back in /var/spool/cron where they should 
have stayed, or fixing the /etc/cron.d behavior?  If the latter, then what 
about other RPMs that put files in /etc/cron.d?  And has the man page been 
updated to mention /etc/cron.d?