Tony Nguyen wrote: > Sebastien Roy wrote: >> The "svcadm enable -ts datalink-management" trick in net-physical didn't >> work. dladm exited with status 3, which is: >> >> 3 svcadm determined that a service instance that it was >> waiting for could not reach the desired state without >> administrator intervention due to a problem with the >> service instance itself. >> >> I have a distinct feeling that it's because of the following dependency >> information in dlmgmt.xml: >> >> <dependent name='network-physical' >> grouping='require_all' >> restart_on='none'> >> <service_fmri value='svc:/network/physical' /> >> </dependent> >> >> Can we express the dependency in the other direction to workaround this >> problem? >> > > Dependency implies certain starting order, dlmgnt -> network-physical, > thus reversing wouldn't get us the original desired starting order.
In any case, my idea didn't fix the problem. It appears that something else bothers svcadm enable -ts, and its a mystery at this point. Any help would be appreciated. > Two narrow down the problem, can you > > 1. Send "svcs -l datalink-management" output to get the current state of > the service(there may be a bug in the synchronous, -s option). Before svcadm enable: fmri svc:/network/datalink-management:default name data-link management daemon enabled true restarter svc:/system/svc/restarter:default After svcadm enable has failed: fmri svc:/network/datalink-management:default name data-link management daemon enabled true restarter svc:/system/svc/restarter:default > 2. Output of network/physical log(alt_logfle) for clues from svcadm > enable -ts command. I also noticed the following, and this is printed as a result of the svcadm enable -ts that fails: svcadm: svc:/network/datalink-management:default is misconfigured (lacks "restarter" property group). This seems very relevant. What does this mean? Thanks, -Seb
