Bug 235998 - crontab -l doesn't work
Summary: crontab -l doesn't work
Alias: None
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Marcela Mašláňová
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-11 12:48 UTC by Jonathan Kamens
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-12 16:49:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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 

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?

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