Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 60962 - Cron file location
Cron file location
Product: Red Hat Linux
Classification: Retired
Component: crontabs (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Jens Petersen
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2002-03-10 13:58 EST by Karl schmidt
Modified: 2007-04-18 12:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-23 04:18:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Karl schmidt 2002-03-10 13:58:18 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020208

Description of problem:
The location of the Cron file should be under /etc so it gets backed up via a
normal tar backup of the directory. a symbolic link would not do as if cron is
set to follow such links large log files get backed up as well.  I would perhaps
be best to have the actual file in /etc with a symbolic link from
/var/spool/cron/root to prevent breaking any software.  

It sould be a goal that one can back up all system settings by backing up /etc 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual Results:  see above

Expected Results:  see above

Additional info:
Comment 1 Jesse Keating 2002-04-19 13:24:41 EDT
Do you propose the same for each other users crontabs?  What if they don't have
write access to /etc, this could cause problems.  Why not just backup the
/var/spool/cron directory as well as /etc.

I don't see this as an issue.
Comment 2 Karl schmidt 2002-04-19 19:28:49 EDT
The reason this is an issue is that taring (-xzf) up /root and /etc SHOULD
backup all the configuration settings other than those of users. 

If it is a personal crontab it should be kept under that persons home directory.
The other place that make sense to keep the root users crontab is under the
/root directory. Perhaps you might want symbolic links back to the /etc tree.

The point is that the design of the directory structure should help separate out
backup items - all user configs should be some where under /home and all system
wide configs should be under /etc. The other one that needs more thought is
weather the hardware specific items (/etc/sysconfig) should be in their own
directory tree along with the rpm database.  

Using this system one SHOULD be able to load a new system  load any unique
software then restore /etc, /root, and  /home and everything should run like it
did before. The uniformity of the use of directories is what makes RedHat my
distribution of choice; any thing that causes settings to be under a variety of
directory trees reduces maintainability. 

I would also like to point to one of RedHats own documents

And The FHS standard keepers that RedHat has endorsed.


seem to support this as an issue. 

You will see that Var is for /var contains variable data files. This includes
spool directories and files, administrative and logging data, and transient and
temporary files.

Further reading will point out that /var/spool contains data which is awaiting
some kind of later processing a definition that crontab fails to meet. Dont
you think that the crontab file is a configuration file? 

I dont see how crontab, as a user editable file that defines system operation
can belong in /var/spool with the definition given by FHS. 
Comment 3 Jesse Keating 2002-04-20 13:50:46 EDT
Actually, I feel that crontabs *are* files that are waiting for processing.  And
they are variable, and dynamic.  Plus, since each user's crontab will go to
/var/spool/cron/  this lends itself to easier backup procedures.

I still don't see this as an issue, but I guess we will wait for an official
answer from Red Hat.  Since it has been the same way since time out of mind, I
doubt it will change any time soon.
Comment 4 Mike A. Harris 2002-04-20 14:01:18 EDT
The crontab files in /var/spool, are NOT user editable crontab files.
They are files submitted to cron which are spooled.  The system
crontab file is /etc/crontab, and it runs the various jobs in the
/etc/cron.* directories as needed.  Per user crontab files are not
stored in any particular location, or with any particular filename.

The files in /var/spool are just spool files of the user's current
Comment 5 Mike A. Harris 2002-04-20 14:27:28 EDT
I missed this the first time through...

>Further reading will point out that /var/spool contains data which is awaiting
>some kind of later processing a definition that crontab fails to meet. Don't
>you think that the crontab file is a configuration file? 

The crontab files in /var/spool are spooled cron jobs, much like when
a user prints something, it gets spooled into /var/spool/lpd or wherever.

They are absolutely _not_ configuration files.

Comment 6 Karl schmidt 2002-04-23 04:18:36 EDT
This is getting into semantics here  the crontab file looks like a duck,
sounds like a duck, has webbed feet, quacks like a duck  Are you really saying
that crontab not a configuration file?  Of course not ; because it is. The fact
is, a user configures a crontab. And one CAN edit the crontab (remember
crontab e  )

There is no intention to edit print spool or mail data  that is what makes it
spool data  it is finished data,  not intended to be changed.  Its data cued up
on its way somewhere. You just cant say the same about a crontab. 

/var/spool is for DATA that is awaiting processing  -- now if you want to say
that the crontab is data waiting to be processed  then so is every script and
program. E-mail is data waiting to be delivered; print spool is data waiting for
a printer.  A crontab is semi-permanent (like all conf files) and never goes
away  even through reboot. 

As someone who has spent time in both the M$ and  Linux worlds, I see that
redhat has quite an advantage in the ease of recreating a system if there has
been respect to the FHS.  I just dont like seeing a sloppy foundation laid here. 

The argument that it would be problematic in a network/logon environment fails
to pass the waving arms test  I can see there is a problem  but to mess up the
FHS with a kluge workaround is not a good long term solution.  

I can imagine a system where users crontabs would be in something like a
/home/user/.etc  directory and then read by the cron daemon (at boot and also
after any user does a crontab e) when it would be COPIED into a combined cron
list under /var/cron  (or should it be in /proc or /tmp?). 

Comment 7 Mike A. Harris 2002-04-23 08:16:29 EDT
What I am really saying, is regardless how many times you choose to reopen
this bug report, it will be reclosed NOTABUG, because it is not a bug, and
will not be changed.

If you want this changed, then contact the Linux Standards Base, and other
relevant standards bodies and wail your story to them.  We do not change
things like this on the whim of a user who doesn't understand the system,
merely because the user is persistant and continously reopens bug reports.

Bugzilla isn't a technical support forum, nor is it a forum for debate,
or discussion.  It is a bug report and bug tracking database, and this
is not a bug report.  End of story.

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