On Tue, Jan 09, 2007 at 11:29:22PM +1100, Darren Reed wrote: > Looking at the SMF properties for IPFilter, one of the > entries is presented like this: > > config/entities fmri file://localhost/etc/ipf/ipf.conf
File dependencies are problematic because SMF lacks a facility by which it can discover that a given file has been created or unlinked, nor would it be enough to know that it has been created (you want to know that it has the right content, but knowing that it has been close()d isn't necessarily sufficient either. SMF only checks file dependencies once (or whenever the FMRI is cleared/refreshed, IIRC). > If I wanted to use http:// here, is this an appropriate > property to use or should this one be deprecated > and another used? For non-local files the problem described above gets much worse. Depending on the protocol in question you might have to poll. > Which leads on to the real question and desire... > > If I want to store a file location in an SMF property, I'd You certainly can. But not as a file dependency, unless the file is accessible through a normal path, and then you still have the problem described above. > like to be able to use that file location from a manifest > without having to build knowledge of how to interpret > the string as a URI into the manifest. > > Hmmm, in case that sounds like double dutch, as an > example of what I'd like to be able to do in the startup > script for ipfilter is the following > > $configfile = smf_fetchfile(`svcprop -p config/entities > svc:/network/ipfilter`) > ipf -f $configfile But why should this 'fetchfile' utility be seen as SMF-specific? Also, if you'd have this in your service's start method then you don't need a file dependency. The nice thing about file dependencies is that your start methods could assume that such files are present and wouldn't have to check for them and then svcs -xv could quite clearly list any missing file deps -- but this is nullified by the problems described above. Nico --
