>Number:         17621
>Category:       misc
>Synopsis:       Better system for managing cron jobs (such at Debian /etc/cron.d)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 17 08:41:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Richard Tibbetts
>Release:        1.4.2
>Organization:
TERC
>Environment:
NetBSD cvs 1.4.2 NetBSD 1.4.2 (GENERIC+MAXUSERS256) #1: Wed Jun 28 03:32:21 EDT 2000 root@khwarizmi:/usr/src/sys/arch/i386/compile/GENERIC+MAXUSERS256 i386
>Description:
Currently the only way to add a cronjob to a machine is to extract, edit, and reinstall the crontab for a user. This system was designed and works well for users managing cronjobs that happen on their behalf. But it does not work well for system tasks that must be run out of cron.

These tasks are not really associated with users primarily, but with services. A given service may have tasks running as a number of different users. The administrator may need to change which user a task runs as, or remove the task all together. Crontab is not the best tool for this job, because it quires the administrator to remember which tasks go with which services, and which user they are running as.

The problem becomes even more clear cut when tasks are managed programatically, either by a package system or by some kind of remote management tool. While programmatic editing of crontabs is possible, it is error prone. Further, when crontabs are programatically editted, the administrator of the machine must be very careful about hand editting.

I suggest a better system, similar to the one used by Debian. I include part of the Debian documentation below. The basic idea is to have a directory full of files that are like crontabs, but where each line specifies not just when to run but which user to run as. This directory is similar to /etc/rc.d, but for cron. A given package or task would put a single file in the directory, describing the the cronjobs it needed run. Administrators could edit these files to change frequency or user, or to enable or disable jobs. And the package system or management tools could also more easily add and remove the files.

>How-To-Repeat:

>Fix:
If a NetBSD developer would like a privileged login on a Debian machine to help with understanding the Debian system, let me know.

Here is some snippets from the Debian cron documentation:

Excerpt from cron(8) http://www.fifi.org/cgi-bin/man2html/usr/share/man/man8/cron.8.gz
DEBIAN SPECIFIC
cron treats the files in /etc/cron.d as extensions to the /etc/crontab file (they follow the special format of that file, i.e. they include the user field). The intended purpose of this feature is to allow packages that require finer control of their scheduling than the /etc/cron.{daily,weekly,monthly} directories allow to add a crontab file to /etc/cron.d. Such files should be named after the package that supplies them. Files must conform to the same naming convention as used by run-parts(8): they must consist solely of upper- and lower-case letters, digits, underscores, and hyphens. Like /etc/crontab, the files in the /etc/cron.d directory are monitored for changes.

Exceprt from crontab(5)
http://www.fifi.org/cgi-bin/man2html/usr/share/man/man5/crontab.5.gz

The format of a cron command is very much the V7 standard, with a number of upward-compatible extensions. Each line has five time and date fields, followed by a command, followed by a newline character ('). The system crontab (/etc/crontab) uses the same format, except that the username for the command is specified after the time and date fields and before the command. Note that if the line does not have a trailing newline character, the entire line will be silently ignored by both crontab and cron; the command will never be executed.
>Release-Note:
>Audit-Trail:
>Unformatted: