As the person who (most recently?) raised this idea, I think still think
it's a good idea, for much the same reasons that you list.
A few more reasons:
- Specifying cron jobs as services (and thus in manifests) would provide a
straightforward way to mechanically add them to the system on install and
remove them on uninstall, and for an administrator to enable and disable them.
- Cron job output could optionally be written to a service log rather than
e-mailed, and that might be more appropriate for most system-y cron jobs.
Here are a couple of the issues that were raised last time:
- How do per-user cron jobs interact with such a framework?
- How is the legacy (/var/spool/cron/*, /bin/crontab) integrated with the
new mechanism?
I'd say that the answers are, at least for now, "they don't" and "it
isn't". "System"[*] cron jobs could use the new framework, and legacy cron
jobs would continue to operate as they currently do.
[*] When I say "system" here I mean something like "tied to
installed software rather than to real humans". I don't mean
to imply that it would only apply to root (since SMF manifests
can specify that a service runs as any specific user) or that
it would apply only to Solaris-supplied jobs (since 3rd parties
can deliver SMF manifests).
The relationship between SMF-style cron jobs and legacy cron jobs would be
similar to the relationship between SMF-style services and /etc/rc*.d/* and
the relationship between SMF-style network listeners and /etc/inetd.conf.
It might be desirable to come up with semantics for per-user services, and
if we ever did then that would help to further move away from the cron
legacy, but I think it would be a mistake to consider such an expansion to
be a prerequisite for this initial transition.
