Jordan Brown writes: > 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.
If it's the same mechanism, then it's a read-only display for the legacy bits with no controls. That's a bit different from the inetd model. (I don't think it's wrong; just different.) > > 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. OK; that's what I was trying to get at. > 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. OK. That sounds like the "divorce" plan I was leaning towards as well. -- 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
