I got the answer from Greg Chaves and Darren Dunham. The answer is that there is a concept of an "Optional" dependency for Solaris 10 services. Inetd and Multi-user milestone services will succeed if rpcbind is disabled via svcadm because rpcbind is optional. The errors I experienced occurred because rpcbind was disabled via perms instead of svcadm. I've included responses fro Greg and Darren. From: Greg Chavez On 2/3/06, Engle, Victor <Victor.Engle@csd.disa.mil> wrote: > Has anyone on the list tried to work with rpcbind disabled on a > Solaris 10 system? When I look at dependencies of rpcbind it appears > multi-level milestone and inetd depend on rpcbind. Ah, but some of these are only optional dependencies. For example, note the particulars on inetd: # svcs -l inted ... dependency require_any/error svc:/network/loopback (online) dependency require_all/error svc:/system/filesystem/local (online) dependency optional_all/error svc:/milestone/network (online) *** dependency optional_all/error svc:/network/rpc/bind (disabled) dependency optional_all/none svc:/network/inetd-upgrade (disabled) dependency require_all/none svc:/milestone/sysconfig (online) svc:/milestone/name-services (online) Look at "man -s 5 smf" for more info. > I have a server where rpcbind had > been disabled by removing rwx perms for the binaries instead of using > svcadm disable ... Later when the box was rebooted, several services > failed and the system didn't appear to have fully reached multi-user > mode. What a weird and unnecessary kludge. Even before Solaris 10 and SMF, you could shut down rpcbind in the startup scripts. And if you wanted them unusable, then why not just remove the rpcbind package? > Among other things, all the meta devices were in the "Needs > Maintenance" state. >From some documentation I made when I was building my first "production" Solaris 10 server: The mdmonitor daemon is needed to sync metadevices at system startup. If it is not running, metadevices come up in the maintenance state, requiring a manual run of "metasync". The cause is an "optional_all" dependency of svc:/network/rpc/meta. This depedency type allows mdmonitord to start if svc:meta is disabled, but *not* if it is in the offline state. The rpc/meta service will come up offline if its "require_all" dependency, svc:/network/rpc/bind, is disabled or offline. Rather that turn on rpcbind, which we purposefully turned off with JASS, the workaround is this: # svcadm disable rpc/bind # svcadm disable rpc/meta # svcadm enable mdmonitord Good luck and read up on SMF! It's an incredible facility. --Greg Chavez ######################################################## >From Darren Dunham... Note that there are different types of dependencies. inetd has a "optional_all/error" dependency on rpc/bind. This means that it's optional for rpcbind to be enabled, but if it is enabled (as it was on your system) don't start inetd until after it launches. I think if you had explicitly disabled rpc/bind, you should not have a problem with inetd. optional_all Satisfied when all of the cited services are running (online or degraded), disabled, in the maintenance state, or when cited ser- vices are not present. For files, this type is the same as require_all. # svcs -l inetd | grep rpc dependency optional_all/error svc:/network/rpc/bind (online) I don't recall if vold has dependencies on rpc or not. Some of the monitoring/maintenance of LVM does also, but actual operation should not (but I haven't tried it). -- Darren Dunham ddunham@taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Mon Feb 6 09:30:30 2006
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:55 EST