On Mon, May 26, 2008 at 07:20:13PM -0700, Jordan Brown wrote: > 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".
Different observers are likely to differ on this. (It helps that we've now an example :) > >>>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. I think that modifying svcs to filter out cronjobs is a bit much. Why do we want to store cron job info in SMF at all? Because it's got a programmatic repository interface? That's what I think. But maybe we need something new. Think, rather than svc FMRIs, how about cron FMRIs? Then the filtering in svcs comes free. Also, the repository for cron FMRIs need not be the same as the regular SMF repository, heck, it needn't even be an svc.configd instance -- it could be a local, embedded DB private to cron itself. > >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.) See above. > >>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. XML is useful as a transfer syntax here, nothing more. > IMHO, the right human readable representation is a GUI. Don't forget CLI/text-based UIs, and APIs. Nico --
