Nicolas Williams wrote: > cron does, BTW, put cronjobs into separate process contracts. There's > no need to restart any cronjobs, I don't think, so cron doesn't have to > be a restarter as such.
I was under the impression that the SMF components that manage services were called "restarters", whether or not they "restart" things. Inetd is called a restarter, even though it doesn't restart things. > Or do you think that there's value in providing > cronjob restarting? No. > But moving the crontab storage from /var/cron/crontabs to SMF sounds > interesting. Yes, moving its storage and management. > What would be the UI? svccfg and svcadm? Something else? Don't know yet. Something like that, yes. Part of the project is, of course, defining it. You would presumably add cron jobs using svccfg import, remove them using svccfg delete, enable them using svcadm enable, and disable them using svcadm disable. Beyond that I don't know. Work would clearly be needed to support those operations for unprivileged users, since random unprivileged users are normally allowed to create personal cron jobs. > Would each cronjob get its own service name, or its own instance name? Yes. (Which, I'm not sure.) > Or would each cronjob be a property value? No. One of the things I specifically want is to be able to enable and disable them using standard service enable/disable mechanisms. > Either way there will be interesting RBAC issues. Yes. > Potential benefits: > > - better and more flexible (more human readable) specification of times > that cronjobs must run at. Eh. Personally, I think I've only found one way in which cron's time specification isn't good enough: the "day of week" selection should really be and-ed with the "day of month" selection, rather than or-ed. That is, if you say "0 0 1 * 0" it should at midnight on the first day of the month, only when it is a Sunday, rather than the current behavior of running on the first day of the month and on all Sundays. I can't find any use for the current behavior, but the behavior I prefer would allow you to say "0 0 22-28 5 0" to run on Memorial Day. I can certainly come up with time expressions that cron can't do... I just have a hard time coming up with real-world use cases. I suppose that if one tried to implement calendaring functionality using cron - which would be good, but is a different project - then you'd want some additional specifications. Anyhow, the XML representation certainly allows for richer and more extensible specifications. As for human readability, that's just a matter of user interface. We could certainly wrap a better UI around crontab with the current file formats. Whether specifying time in XML would be superior to the current column-oriented layout is unclear to me. Neither is great. > - better UI (if svccfg then SMF Templates could help lots, but I think > you'll need to provide a cron-specific UI) Again, a better UI could run on top of either data structure. > - better control over cronjobs' environment, error/mail options, ... 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. I'd like to have a way for an administrator to disable a cron entry without having the next update bring it back. >> I'm tempted to try spending some of my copious free time on it, just for >> the entertainment value. Were I to do so, would people be interested? > > In reviewing and testing? Sure :) That's a start :-)
