Peter Tribble wrote: > 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.
Hmm. I view cron jobs as services. They're just like those things that run in the background; they just don't run all the time. I'd consider them to be much like a service that executes in a loop with a "sleep". >>> 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. 10K seems like a pretty large number; do you have any real systems with even multiple hundred cron jobs? (Solaris ships with 6; RHEL looks like, depending on definitions, it ships with about 16.) But yes, perhaps svcs would need to have some kind of filtering. The first would probably be that (by default) it'd show only *your* cron jobs. >>> 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. Concur. (But improving the time specification rules seems to be a big goal for some people. It isn't for me.) >> 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 syntax *is* pretty limiting. XML seems more extensible. IMHO, the right human readable representation is a GUI. > (The current format isn't really - which field is which?) Aren't we pushing a bit there? Positional representations seem to work fine for time, and mostly OK for dates (as long as you have context so you know whether it's an American talking). Cron specifications are from smallest unit (minutes) to largest unit (months), plus day-of-week. Can't say I love 'em, but they aren't awful. > 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 That's a reasonable add/delete strategy, but doesn't give you enable/disable. Also, if you (as I do) view them as equivalent to services, it seems like they should be managed the same way that services are managed. > (on an inactive image, > anyway - on a live image you need to ping cron). Cron could check the directory mod time every minute or two. >> 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.) Maybe, but it'd be nice to have something obvious, and nicer still if it's the same as other services. Any attribute on the file will upset pkgchk when changed. (Now, perhaps disabling a service *should* get pkgchk upset.) One could also have conventions for the insides of files. Again, though, it'd be nice to use an existing convention instead of adding one.
