Sebastien Roy wrote: > Peter Memishian wrote: >> > > Until that fix is available though, the alternatives seem limited -- the >> > > only one that occurs to me is to have net-physical manually start >> dlmgmtd >> > > (through svcadm if possible, though previous attempts to do this >> failed). >> > >> > Why did they fail? >> >> Unclear; Seb is looking into this now and will report back soon. >> (Conjecture: even though the service has been imported, maybe it's not >> possible to enable the service until manifest-import has run?) > > 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. 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). 2. Output of network/physical log(alt_logfle) for clues from svcadm enable -ts command. -tony
