Quoth Stacey Marshall on Thu, Aug 17, 2006 at 04:26:14PM +0100: > To recap, /etc/named.conf has always been the dependency for starting > DNS server 'named' at system boot. > > If /etc/named.conf does not exist then the service is not started. > If it does exist, then start the service.
I wouldn't say it was a dependency. named.conf is clearly DNS server configuration. I think dependencies are usually interactions between services. Now if named.conf was using something belonging to another service, then that might deserve the label of 'dependency', but that's not the case here. Instead, named was using the presence or absence of named.conf as means to allow the administrator to signal whether named should run (at boot). This, of course, was not the only way: the administrator could also modify or rename the init script. This was one of the problems which SMF was intended to solve: consolidate the various or service-specific ways to keep a service from running into centralized standard ways. > Of course traditionally the check for /etc/named.conf would only have > been made at startup. > But with smf the file dependency causes svc.startd to continuously > monitor for the existence of file, not just a single check at startup. Actually it doesn't, and it never has, primarily because we don't have the right kernel interfaces to do this efficiently. > Unlike CR 6240573 > <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6240573> > (*most file:// dependencies should really be scripted checks*) the lack > of the file does not necessarily mean there is a problem. Rather it > means the service is not required. Right. But now that that marker of intent has been formally established elsewhere (SCF, aka the repository), the question is whether we should continue to interpret presence or absence of the configuration file as intent. The answer for all of our other services is no; if the user has instructed that the service should run, but a piece of configuration is missing, then there is a problem, and the service should be flagged as such. You'll have to come up with a pretty good argument to excuse named. > As suggested in the afore mentioned thread, modifying the ''named' > start up method to exit with code SMF_EXIT_ERR_CONFIG when the config > file is not found is not appropriate as it causes failure messages to be > logged to the console. The missing file presence is not an error. I > don't think anyone will be happy if I put-back a service that on the > majority of systems is suddenly going to start spitting out > configuration warnings because it is not configured or wanted. Absence of the file is not an error, but enabling the service without supplying require configuration is. Of course, if the service is enabled by the system somehow despite the configuration file being missing would be a problem. So let's make a best-effort to make the system smart enough not to do that. > So in this case is a file dependency the right thing to do? > If not then should I raise an RFE to have svc.startd(1M) understand a > new exit code of SMF_EXIT_SVC_NOT_REQUIRED? We already have one: 6245225 RFE: SMF_EXIT_DISABLE and SMF_EXIT_DISABLE_TEMPORARY > Which for example would place the service less verbosely (log only to > the service log) in the maintenance state; Such that at reboot it would > be tried (started) again? Maintenance means there is a problem, so it will always be flagged. SMF_EXIT_DISABLE_TEMPORARY is what you're describing. > In the mean time my only other alternative would be to have patch and > install scripts that disable the dns/server instance if the > file-dependency file does not exist before installation.... That's what we've done for all the other services. David
