Solaris 10: BIND 9 service fails to start as service but works when run manually

Question

I've tried everything I know and spent my whole day yesterday trying to figure this one out, but I give up. I need your help...

I have a Solaris 10 server with a BIND 9 server on it. No matter what I do, the service will always fail to start (using svcadm restart) and stay in maintenance mode.

However, if I call /usr/sbin/named manually, the server starts without a hitch.

We have another server (slave DNS) that seems to be configured the same way and for which the service works perfectly. I have tried to compare the configuration of both servers together and can't find a difference.

Here's the output of svcs -vx svc:/network/dns/server:default

svc:/network/dns/server:default (?)
 State: maintenance since Fri May 20 10:20:39 2011
Reason: Start method failed repeatedly, last exited with status 1.
   See: http://sun.com/msg/SMF-8000-KS
   See: man -M /usr/man -s 1M named
   See: /var/svc/log/network-dns-server:default.log
Impact: This service is not running.

Here's the corresponding lines in /var/svc/log/network-dns-server:default.log

[ May 20 10:20:39 Enabled. ]
[ May 20 10:20:39 Executing start method ("/lib/svc/method/dns-server start default") ]
dns-server: Executing: /usr/sbin/named
dns-server : start failed! Check syslog for further information.
[ May 20 10:20:39 Method "start" exited with status 1 ]

Here's the output of svcs | grep dns

maintenance    10:20:39 svc:/network/dns/server:default

I'm not aware of other logs I could look in, and haven't increased the debug_level yet (this is a production server), but I'm thinking about it...

Would anyone have any clue or pointer on what else I could check?

Note: SunOS 5.10_x86: BIND patch (119784-17) has been applied on this server through a bigger patch set not long ago, but the issue was occurring before as well.

EDIT:

I have found the problem... It was in the service's configuration.

The start/user and start/group properties were set to the named user, but the service was installed as root.

To fix it, I did...

svccfg -s svc:/network/dns/server:default
> setprop start/user=root
> setprop start/group=root
> exit
svcadm refresh svc:/network/dns/server:default
svcadm clear svc:/network/dns/server:default
svcadm restart svc:/network/dns/server:default

svcs -p svc:/network/dns/server:default
ps -ef | grep LISTEN | grep "\.53 "

Answer 1

It appears this is a known issue. The SMF that is shipped has chroot issues. Check out http://blogs.oracle.com/anay/entry/bind_9_dns_server_meets for a solution...