Stephen Hahn wrote: > * Anurag S. Maskey <Anurag.Maskey at Sun.COM> [2009-05-04 22:33]: > >> NWAM Phase 1 introduces a couple of new SMF services and modifies a few >> others. These new SMF services have dependencies between each other and >> existing services. When system/manifest-import runs, it doesn't care >> about the dependencies. Thus, we have a problem because we want one >> service online before the second one starts.. >> >> Couple of things we have tried (let me illustrate with SMF services A >> and B where B depends on A (in other words, A must start before B)). >> manifest-import doesn't care if B was imported and started before A. >> >> 1. In B's start method, explicitly enable A. If A is already enabled, >> it does nothing. Otherwise, A is started. This doesn't work (all the >> time) because if manifest-import hasn't imported A yet, then the enable >> finds nothing. >> >> Two solutions we're looking at: >> >> 1. In B's start method, check if A been enabled (it will be if it has >> been imported). If not, sleep for a while and check again. If A still >> hasn't been enabled, exit with an error. We don't want to have a loop >> here for fear that A may have failed and don't want B to keep checking >> forever. >> >> 2. In B's start method, check if A has been enabled. If not, svccfg >> import A. The issue here it that it may create a race condition where B >> imports A and manifest-import is also importing A. I don't see any >> other scripts (in /lib/svc/method) doing such imports, so what would >> happen here? Are there any controls to make the import operation >> exclusive? >> >> Is there a different solution to the problem of manifest-import >> respecting service dependencies? >> Other comments? >> > > The problem statement mentions dependencies between A and B, but the > discussion only talks about start method implementations. What are > the expected dependencies between A and B, and what characteristics do > the dependencies have? >
> For instance, if B requires A, then B will remain offline until A is > online. No enabling, sleeping, etc. should be required in the start > method. (Are you seeing other behaviour with a require dependency?) > SMF service B required A, and the dependencies were indirect via an already existing SMF service C (that's also updated). I think this caused the failure. The problem is that when manifest-import runs the dependencies with existing services are not respected. In the above case, C was already online with the old manifest. Thus, when B started, it's dependency with C was satisfied and B went online. And, B assumed that A was already online since C is already online (albeit with an old manifest). This can be solved by have B directly depend on A. However, there's still different a problem that still exists with manifest-import. manifest-import doesn't import the updated manifests in any particular order. This means that when property/property-groups are added/removed from manifest, other services cannot assume that the change has taken place. Again, let me try with example services and properties: SMF service X already exists in the system and is online before manifest-import runs. SMF service Y is a new service that depends on X and is introduced by our project. Our project also added a property-group p to service X. Service Y uses property-group p in its start method. Now, manifest-import doesn't guarantee that the new manifest for X is imported before Y's. If the imports happened in that order, then there's no problem. But, if Y was imported before X, then Y's start method will look for the property-group p and fail. :(. There's error in /var/svc/log/Y.log saying "svccfg: property group p doesn't exist") For situations like this, can Y explicitly import X's new manifest? Or, is it better for Y to simply sleep and wait for X's new manifest to be imported? (Y can determine whether X's new manifest has been imported or not by checking for a property in property-group p that it know should/will exist after the new manifest is imported.) Thanks, Anurag
