Jordan Brown writes: > James Carlson wrote: > > Yes, that'd be a good idea. The one issue I see there is that the > > crontab interfaces are standards-related issues, so you can't just do > > an inetconv-type one-way slurp. The compatibility story would have to > > be an important part of it. > > 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. In the case of /etc/inetd.conf, it's possible to wave your hands at the fact that (say) commenting a service out of /etc/inetd.conf does nothing. You can't just wave your hands at the SUS requirements -- you fail the test, you lose the branding. > (Is /etc/inetd.conf really ignored if you don't run inetconv? Doesn't > that break many third-party network listeners?) There's a boot time service that will check the freshness of the SMF repository and re-conv if necessary. > > (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. 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. 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")? Divorce seems more consistent. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
