James Carlson wrote: >> Yes, but not really any more than the issues for /etc/rc*.d and >> /etc/inetd.conf. Those aren't governed by standards, but they do have >> backwards-compatibility concerns that are arguably just as important. > > The backwards-compatibility problem is different in character from the > standards one.
Yeah... one breaks actual users, while the other breaks theoretical users :-) >>> (Perhaps it's simple. Just have two different mechanisms -- old cron, >>> not in SMF, and new cron via SMF instances.) >> Maybe. I'd think more in terms of the traditional crontab files being >> slurped in in addition to the SMF-based jobs. The actual runtime >> processing would be identical for the two. Still relatively simple. > > The nice thing about divorcing them is that you'd be free to define > wild new semantics for the time specification. Well, yes, but that's true no matter what. The XML specification could be a superset of the traditional mechanism. If it wasn't a pure superset, I'd want to be really careful about the differences. Perhaps, for instance, I might make that one change related to the relationship between day-of-week and date/month specifications, but otherwise I would expect that every traditional cron specification would have a straightforward XML representation. > And the lack of management of existing cron jobs would be consistent > with the lack of management of rc*.d scripts. Just like it'd be nice > to be able to do "svcadm disable" on one of those scripts, but you > can't, we'd have the same hole for legacy cron entries. Right. That's exactly what I was expecting. Perhaps you're reading too much into what I said, or perhaps I'm reading too much into what you said. I'm expecting to gain little if any functionality for cron jobs defined through the legacy mechanisms, just as there's little functionality added for /etc/rc*.d scripts. They might get listed in "svcs", but that's about it. They'd just be run using the same process with the same scheduling engine, same output-disposition mechanisms, and so on. > You're right that being able to do SMF management on regular crontab > entries would be nice, but I think it'd be highly complex. What > happens when someone edits the file and removes something? What > happens if someone adds "VAR=value" to the file (where the semantics > are "this entry and all that sequentially follow")? I have no expectation of being able to do SMF management on jobs defined through legacy crontab mechanisms. The parallel to rc*.d is quite close: the legacy services get only very limited SMF integration, but are executed through the SMF mechanisms rather than through separate legacy mechanisms.
