Hi, Sorry for the late reply, I've been up to my neck in recruiting activities.
David G. Bustos wrote: >> I updated the link management document at: >> >> http://www.opensolaris.org/os/project/clearview/uv/link_id_management.pdf > > I assume that by "The stop method will do nothing" in 2.3 you think a null > stop method will keep the service manager from stopping your daemon. That's > not the case. If processes are left in the main contract after the stop > method > exits, the service manager will kill them with SIGKILL until they're gone. > The > comparison with network/physical is not valid because network/physical is > a "transient" service with no daemon. The correct way to keep users from > stopping your daemon is to mark the general/enabled property as private, > which unfortunately is not possible with SMF right now. So you'll just have > to > make sure (a) it's well documented that disabling the daemon is a bad idea, > and (b) the tools which talk to the daemon inform the user appropriately when > the daemon is disabled. Yes, that is what I thought. I will update the document so that we state the stop method will kill linkmgmtd, and to also state the user should never do this. When we write man pages for linkmgmtd, I'll make sure something gets in there to state that networking will not work correctly unless linkmgmtd is running, and so the administrator should never try to stop the daemon. When do you expect the support for marking general/enabled property as private to exist? Or, maybe I should first ask do you expect to add support for that? > > Configuration data should be available before any services are started. > (Indeed, > that's how the service manager knows which services to start.) You should > know, > however, that configuration in the SMF repository is read-only until > filesystem/usr has successfully remounted the root filesystem read/write. > Before > then, attempts to modify configuration (persistently, nonpersistent > modifications > should work) will fail with an error like SCF_ERROR_BACKEND_READONLY. In > the future we would like to change this so that configuration is modifiable > right > away, but that project hasn't been designed. > > For most cases, I don't think this would be a problem. The administrator would be creating links after the system has booted and everything is up and running. I can't think of a case where the kernel would try to create a link before then, maybe Cathy can think of an instance where that would happen. thanks for the comments, I'll update the documents, Dan
