Following-on from our discussion on 'Open Solaris smf discuss' under
thread labeled "service instance expansion for SMF manifest".
<http://www.opensolaris.org/jive/thread.jspa?messageID=34864蠰>
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.
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.
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.
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.
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?
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?
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....
Thanks again for any help / advice.
Stacey
http://blogs.sun.com/ace
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3261 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20060817/718740a1/attachment.bin>
