On Fri, May 23, 2008 at 12:05 AM, Jordan Brown <Jordan.Brown at sun.com> wrote: > >> But moving the crontab storage from /var/cron/crontabs to SMF sounds >> interesting. > > Yes, moving its storage and management.
Sounds absolutely horrifying to me. SMF is fantastic as an rc replacement, wonderful as a service restarter, adequate as a service monitor, but it's terrible as a data store. And I regard crontabs as data, not cron configuration. >> Would each cronjob get its own service name, or its own instance name? > > Yes. (Which, I'm not sure.) Oh great. svcs lists 10,000 entries... This idea clearly doesn't scale. >> Potential benefits: >> >> - better and more flexible (more human readable) specification of times >> that cronjobs must run at. I don't see what that has to do with moving to SMF. Enhancing cron to support better more flexible scheduling capability is good, but I see that as completely independent of whether it's in SMF or not. > Whether specifying time in XML would be superior to the current > column-oriented layout is unclear to me. Neither is great. XML has no more capabilities, it's just harder to read. The internal representation may well be XML, but you need something human readable. (The current format isn't really - which field is which?) > Yes, and also standardizing add/remove and enable/disable. Reference > some of our discussions over in pkg-discuss; I'd like to get rid of > scripts that run "sed" to add or remove cron entries. Well, yes, that's one of the problems with the current scheme. I would love to 'crontab add' or 'crontab delete' a job without having to use or emulate an editor. Could easily be done by making each entry a separate file in a directory. Just deliver or remove the file (on an inactive image, anyway - on a live image you need to ping cron). > I'd like to have > a way for an administrator to disable a cron entry without having the > next update bring it back. If it's a file, then have some attribute that marks it as disabled. (Something that packaging or whatever won't touch.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
