Nikhil writes: > On 1/19/06, Nicolas Williams <Nicolas.Williams at sun.com> wrote: > > > > On Wed, Jan 18, 2006 at 11:37:06PM +0530, Nikhil wrote: > > > On 1/18/06, Nicolas Williams <Nicolas.Williams at sun.com> wrote: > > > > > > > > On Wed, Jan 18, 2006 at 12:25:53PM +0530, Nikhil wrote: > > > > > Hi > > > > > > > > > > Is it possible that if my configuration file is changed and without > > > > > restarting my service with svcs, can svc.startd take care of huppin= > g > > the > > > > > application itself ? > > > > > > > > SMF file dependencies are not as fully functional as you would expect= > . > > > > > > > > > Is it already thought of ? If so, then when the changes are going to > > > propagate into Actual SMF stuff ? > > > > I don't know what the plan is for file dependencies, but you can imagine > > that fully functional file dependencies will require a filesystem event > > facility, and one, by the way, that will work across NFS (for diskless > > boot). In other words, I wouldn't expect this anytime soon. > > > > More importantly though, file dependencies are a poor interface for your > > needs. This is because an event message like "/etc/foo.conf changed" > > isn't necessarily atomic w.r.t. whatever is actually changing > > /etc/foo.conf. That is, just because /etc/foo.conf has changed doesn't > > mean it is done changing. > > > > So you should consider the possibility that file dependencies really > > aren't something you want. > > > Making point Nic. But IMHO, should not be an option made available in the > SMF thought there may be side lines to it in its usage.. ? Is there any CVS= > / > test code available .. I would like to volunteer for its testing if its > there .. >
No, there is no test code available. Creating this sort of functionality would require a bunch of work for a feature that we believe will actively lead to broken applications. Our list of requested features which don't lead to broken applications is too long already. :) As Nico mentioned, this is refresh-on-file-edit is rarely what you want. We aren't planning this sort of functionality anytime soon because it will lead to very poor and broken behaviour of applications: you accidentally type ":w" in your vi session, and suddenly your application is broken. The only thing file: dependencies were originally meant for was to test the existence of a file, and they don't even do that well. (That's the bug that Jim pointed you at, which on its own is going to take a bunch of work to fix, even without the additional functionality you've requested.) What we do have is the SMF repository, which was designed for this type of use. The application author does this: 1) store the application's configuration in the SMF repository 2) make the application look up its configuration in the SMF repository 3) write a 'refresh' method which loads configuration from the repository whenever the method is called Then, an admin does this: 3) make application configuration changes using svccfg(1M) or application-specific commands 4) atomically update the configuration by running "svcadm refresh <service>", which signals the service that the configuration is complete and consistent, and it's time to run the refresh method so the application can use the most recent copy. Even if you haven't stored the configuration in the repository, the idea is that "svcadm refresh <service>" signals SMF that the configuration change is complete and it's time to tell the service about the new configuration. Many services *do* implement refresh (e.g. sendmail and syslog). It's much less risky to do explicit configuration commit rather than implicit commits. Implicit commits lead to hard-to-debug problems on production systems. liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
